[要約] RFC 2917は、MPLS IP VPNの基本的なアーキテクチャを定義しており、要約すると以下のようになります。1. MPLS IP VPNは、セキュアで効率的な仮想プライベートネットワークを提供するための技術です。 2. このRFCは、MPLS IP VPNの基本的な概念、要素、およびプロトコルを説明しています。 3. 目的は、MPLS IP VPNの実装と運用に関するガイドラインを提供し、ネットワークエンジニアやプロバイダに役立つ情報を提供することです。
Network Working Group K. Muthukrishnan
Request for Comments: 2917 Lucent Technologies
Category: Informational A. Malis
Vivace Networks, Inc.
September 2000
A Core MPLS IP VPN Architecture
コアMPLS IP VPNアーキテクチャ
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services. The central vision is for the service provider to provide a virtual router service to their customers. The keystones of this architecture are ease of configuration, user security, network security, dynamic neighbor discovery, scaling and the use of existing routing protocols as they exist today without any modifications.
このメモは、サービスプロバイダーのMPLSバックボーンにコア仮想プライベートネットワーク（VPN）サービスを構築するためのアプローチを提示します。このアプローチでは、バックボーンで実行されているマルチプロトコルラベルスイッチング（MPLS）を使用して、Best Effect Servicesに加えてプレミアムサービスを提供します。中心的なビジョンは、サービスプロバイダーが顧客に仮想ルーターサービスを提供することです。このアーキテクチャのキーストーンは、構成、ユーザーセキュリティ、ネットワークセキュリティ、動的な隣接発見、スケーリング、および変更なしで今日存在する既存のルーティングプロトコルの使用です。
ARP Address Resolution Protocol CE Customer Edge router LSP Label Switched Path PNA Private Network Administrator SLA Service Level Agreement SP Service Provider SPED Service Provider Edge Device SPNA SP Network Administrator VMA VPN Multicast Address VPNID VPN Identifier VR Virtual Router VRC Virtual Router Console
ARPアドレス解像度プロトコルCEカスタマーエッジルーターLSPラベルスイッチ付きパスPNAプライベートネットワーク管理者SLAサービスレベル契約SPサービスプロバイダーSPEDサービスプロバイダーデバイスSPNA SPNA SPNA SPNA SPNAT SPNA SPNA SPNE SPNA SPNA SPNAT SPNA SPNA SPNA SPNAT SPN
This memo describes an approach for building IP VPN services out of the backbone of the SP's network. Broadly speaking, two possible approaches present themselves: the overlay model and the virtual router approach. The overlay model is based on overloading some semantic(s) of existing routing protocols to carry reachability information. In this document, we focus on the virtual router service.
このメモは、SPのネットワークのバックボーンからIP VPNサービスを構築するためのアプローチについて説明しています。大まかに言えば、2つの考えられるアプローチは、オーバーレイモデルと仮想ルーターアプローチの2つのアプローチです。オーバーレイモデルは、到達可能性情報を伝達するために既存のルーティングプロトコルのセマンティックをオーバーロードすることに基づいています。このドキュメントでは、仮想ルーターサービスに焦点を当てています。
The approach presented here does not depend on any modifications of any existing routing protocols. Neighbor discovery is aided by the use of an emulated LAN and is achieved by the use of ARP. This memo makes a concerted effort to draw the line between the SP and the PNA: the SP owns and manages layer 1 and layer 2 services while layer 3 services belong to and are manageable by the PNA. By the provisioning of fully logically independent routing domains, the PNA has been given the flexibility to use private and unregistered addresses. Due to the use of private LSPs and the use of VPNID encapsulation using label stacks over shared LSPs, data security is not an issue.
ここに示されているアプローチは、既存のルーティングプロトコルの変更に依存しません。隣人の発見は、エミュレートされたLANの使用によって支援され、ARPを使用することで達成されます。このメモは、SPとPNAの間に境界線を描くために協力して努力します。SPは、レイヤー1とレイヤー2サービスを所有および管理し、レイヤー3サービスはPNAに属し、PNAによって管理可能です。完全に論理的に独立したルーティングドメインのプロビジョニングにより、PNAにはプライベートおよび未登録の住所を使用する柔軟性が与えられています。プライベートLSPの使用と、共有LSPよりもラベルスタックを使用したVPNIDカプセル化の使用により、データセキュリティは問題ではありません。
The approach espoused in this memo differs from that described in RFC 2547 [Rosen1] in that no specific routing protocol has been overloaded to carry VPN routes. RFC 2547 specifies a way to modify BGP to carry VPN unicast routes across the SP's backbone. To carry multicast routes, further architectural work will be necessary.
このメモで支持されているアプローチは、RFC 2547 [Rosen1]で説明されているアプローチとは異なります。これは、VPNルートを運ぶために特定のルーティングプロトコルが過負荷になっていないからです。RFC 2547は、BGPを変更してVPNユニキャストルートをSPのバックボーンに携帯する方法を指定しています。マルチキャストルートを運ぶには、さらに建築作業が必要になります。
A virtual router is a collection of threads, either static or dynamic, in a routing device, that provides routing and forwarding services much like physical routers. A virtual router need not be a separate operating system process (although it could be); it simply has to provide the illusion that a dedicated router is available to satisfy the needs of the network(s) to which it is connected. A virtual router, like its physical counterpart, is an element in a routing domain. The other routers in this domain could be physical or virtual routers themselves. Given that the virtual router connects to a specific (logically discrete) routing domain and that a physical router can support multiple virtual routers, it follows that a physical router supports multiple (logically discreet) routing domains.
仮想ルーターは、ルーティングデバイス内の静的または動的なスレッドのコレクションであり、物理ルーターのようなルーティングサービスと転送サービスを提供します。仮想ルーターは、個別のオペレーティングシステムプロセスである必要はありません（ただしそうかもしれませんが）。それは単に、接続されているネットワークのニーズを満たすために専用のルーターが利用可能であるという幻想を提供する必要があります。物理的なカウンターパートと同様に、仮想ルーターはルーティングドメインの要素です。このドメインの他のルーターは、物理的または仮想ルーター自体です。仮想ルーターが特定の（論理的に離散）ルーティングドメインに接続し、物理ルーターが複数の仮想ルーターをサポートできることを考えると、物理ルーターが複数の（論理的に慎重な）ルーティングドメインをサポートすることになります。
From the user (VPN customer) standpoint, it is imperative that the virtual router be as equivalent to a physical router as possible. In other words, with very minor and very few exceptions, the virtual router should appear for all purposes (configuration, management, monitoring and troubleshooting) like a dedicated physical router. The main motivation behind this requirement is to avoid upgrading or re-configuring the large installed base of routers and to avoid retraining of network administrators.
ユーザー（VPNカスタマー）の観点からは、仮想ルーターを可能な限り物理ルーターと同等にすることが不可欠です。言い換えれば、非常にマイナーで非常に少ない例外を除き、仮想ルーターは、専用の物理ルーターのように、あらゆる目的（構成、管理、監視、トラブルシューティング）に表示される必要があります。この要件の背後にある主な動機は、ルーターの大きなインストールされたベースのアップグレードまたは再構成を避け、ネットワーク管理者の再訓練を避けることです。
The aspects of a router that a virtual router needs to emulate are:
仮想ルーターがエミュレートする必要があるルーターの側面は次のとおりです。
1. Configuration of any combination of routing protocols
1. ルーティングプロトコルの任意の組み合わせの構成
2. Monitoring of the network
2. ネットワークの監視
3. Troubleshooting.
3. トラブルシューティング。
Every VPN has a logically independent routing domain. This enhances the SP's ability to offer a fully flexible virtual router service that can fully serve the SP's customer without requiring physical per-VPN routers. This means that the SP's "hardware" investments, namely routers and links between them, can be re-used by multiple customers.
すべてのVPNには、論理的に独立したルーティングドメインがあります。これにより、物理的なVPNパバールーターを必要とせずにSPの顧客に完全にサービスを提供できる、完全に柔軟な仮想ルーターサービスを提供するSPの機能が向上します。これは、SPの「ハードウェア」投資、つまりルーターとそれらの間のリンクが複数の顧客によって再利用できることを意味します。
1. Easy, scalable configuration of VPN endpoints in the service provider network. At most, one piece of configuration should be necessary when a CE is added.
1. サービスプロバイダーネットワークのVPNエンドポイントの簡単でスケーラブルな構成。せいぜい、CEを追加すると、1つの構成が必要です。
2. No use of SP resources that are globally unique and hard to get such as IP addresses and subnets.
2. IPアドレスやサブネットなど、グローバルにユニークで困難なSPリソースを使用しません。
3. Dynamic discovery of VRs (Virtual Routers) in the SP's cloud. This is an optional, but extremely valuable "keep it simple" goal.
3. SPのクラウドでのVRS（仮想ルーター）の動的発見。これはオプションですが、非常に貴重な「シンプルに保つ」目標です。
4. Virtual Routers should be fully configurable and monitorable by the VPN network administrator. This provides the PNA with the flexibility to either configure the VPN themselves or outsource configuration tasks to the SP.
4. 仮想ルーターは、VPNネットワーク管理者が完全に構成し、監視可能である必要があります。これにより、PNAにVPN自体を構成するか、SPに構成タスクをアウトソーシングする柔軟性が提供されます。
5. Quality of data forwarding should be configurable on a VPN-by-VPN basis. This should translate to continuous (but perhaps discrete) grades of service. Some examples include best effort, dedicated bandwidth, QOS, and policy based forwarding services.
5. データ転送の品質は、VPNごとに構成できる必要があります。これは、継続的な（おそらく個別の）サービスグレードに変換されるはずです。いくつかの例には、最善の努力、専用の帯域幅、QoS、およびポリシーベースの転送サービスが含まれます。
6. Differentiated services should be configurable on a VPN-by-VPN basis, perhaps based on LSPs set up for exclusive use for forwarding data traffic in the VPN.
6. 差別化されたサービスは、おそらくVPNのデータトラフィックを排他的に使用するために設定されたLSPに基づいて、VPNごとに構成できる必要があります。
7. Security of internet routers extended to virtual routers. This means that the virtual router's data forwarding and routing functions should be as secure as a dedicated, private physical router. There should be no unintended leak of information (user data and reachability information) from one routing domain to another.
7. インターネットルーターのセキュリティは、仮想ルーターに拡張されました。これは、仮想ルーターのデータ転送およびルーティング機能が、専用のプライベート物理ルーターと同じくらい安全である必要があることを意味します。あるルーティングドメインから別のルーティングドメインへの意図しない情報（ユーザーデータと到達可能性情報）はないはずです。
8. Specific routing protocols should not be mandated between virtual routers. This is critical to ensuring the VPN customer can setup the network and policies as the customer sees fit. For example, some protocols are strong in filtering, while others are strong in traffic engineering. The VPN customer might want to exploit both to achieve "best of breed" network quality.
8. 特定のルーティングプロトコルは、仮想ルーター間で義務付けられてはなりません。これは、VPN顧客が顧客が適切と思われるときにネットワークとポリシーをセットアップできるようにするために重要です。たとえば、一部のプロトコルはフィルタリングに強力ですが、他のプロトコルはトラフィックエンジニアリングに強力です。VPNの顧客は、「最高の品種の」ネットワーク品質を達成するために両方を活用したいと思うかもしれません。
9. No special extensions to existing routing protocols such as BGP, RIP, OSPF, ISIS etc. This is critical to allowing the future addition of other services such as NHRP and multicast. In addition, as advances and addenda are made to existing protocols (such as traffic engineering extensions to ISIS and OSPF), they can be easily incorporated into the VPN implementation.
9. BGP、RIP、OSPF、ISISなどの既存のルーティングプロトコルへの特別な拡張はありません。これは、NHRPやマルチキャストなどの他のサービスの将来の追加を許可するために重要です。さらに、既存のプロトコル（ISISやOSPFへのトラフィックエンジニアリング拡張など）に進歩と補遺が作成されると、VPN実装に簡単に組み込むことができます。
The service provider network must run some form of multicast routing to all nodes that will have VPN connections and to nodes that must forward multicast datagrams for virtual router discovery. A specific multicast routing protocol is not mandated. An SP may run MOSPF or DVMRP or any other protocol.
サービスプロバイダーネットワークは、VPN接続を持つすべてのノードと、仮想ルーター発見のためにマルチキャストデータグラムを転送する必要があるノードに何らかの形のマルチキャストルーティングを実行する必要があります。特定のマルチキャストルーティングプロトコルは義務付けられていません。SPは、MOSPFまたはDVMRP、またはその他のプロトコルを実行する場合があります。
1. Every VPN is assigned a VPNID which is unique within the SP's network. This identifier unambiguously identifies the VPN with which a packet or connection is associated. The VPNID of zero is reserved; it is associated with and represents the public internet. It is recommended, but not required that these VPN identifiers will be compliant with RFC 2685 [Fox].
1. すべてのVPNには、SPのネットワーク内で一意のVPNIDが割り当てられます。この識別子は、パケットまたは接続が関連付けられているVPNを明確に識別します。ゼロのVPNIDは予約されています。これは、パブリックインターネットに関連付けられ、表現されています。推奨されますが、これらのVPN識別子がRFC 2685 [FOX]に準拠することは必須ではありません。
2. The VPN service is offered in the form of a Virtual Router service. These VRs reside in the SPED and are as such confined to the edge of the SP's cloud. The VRs will use the SP's network for data and control packet forwarding but are otherwise invisible outside the SPEDs.
2. VPNサービスは、仮想ルーターサービスの形で提供されます。これらのVRはSPEDに存在し、SPの雲の端に限定されています。VRSは、SPのネットワークをデータおよびコントロールパケット転送に使用しますが、SPEDSの外では見えません。
3. The "size" of the VR contracted to the VPN in a given SPED is expressed by the quantity of IP resources such as routing interfaces, route filters, routing entries etc. This is entirely under the control of the SP and provides the fine granularity that the SP requires to offer virtually infinite grades of VR service on a per-SPED level. [Example: one SPED may be the aggregating point (say headquarters of the corporation) for a given VPN and a number of other SPEDs may be access points (branch offices). In this case, the SPED connected to the headquarters may be contracted to provide a large VR while the SPEDs connected to the branch offices may house small, perhaps stub VRs]. This provision also allows the SP to design the network with an end goal of distributing the load among the routers in the network.
3. 特定のSPEDでVPNに契約されたVRの「サイズ」は、ルーティングインターフェイス、ルーティングフィルター、ルーティングエントリなどのIPリソースの量によって表されます。これは完全にSPの制御下にあり、その細かい粒度を提供します。SPは、SPEDレベルあたりのVRサービスの実質的に無限のグレードを提供する必要があります。[例：1つのSPEDは、特定のVPNの集約ポイント（会社の本部など）であり、他の多くのSPEDはアクセスポイント（支店）である場合があります。この場合、本部に接続されたSPEDは、大きなVRを提供するために契約される場合がありますが、支店に接続されたSPEDには小さな、おそらくスタブVRSを収容できます。また、この規定により、SPはネットワーク内のルーター間に負荷を分散するという最終目標でネットワークを設計することができます。
4. One indicator of the VPN size is the number of SPEDs in the SP's network that have connections to CPE routers in that VPN. In this respect, a VPN with many sites that need to be connected is a "large" VPN whereas one with a few sites is a "small" VPN. Also, it is conceivable that a VPN grows or shrinks in size over time. VPNs may even merge due to corporate mergers, acquisitions and partnering agreements. These changes are easy to accommodate in this architecture, as globally unique IP resources do not have to be dedicated or assigned to VPNs. The number of SPEDs is not limited by any artificial configuration limits.
4. VPNサイズの指標の1つは、そのVPNのCPEルーターに接続するSPのネットワーク内のSPEDの数です。この点で、接続する必要がある多くのサイトを持つVPNは「大きな」VPNですが、いくつかのサイトを持つものは「小さな」VPNです。また、VPNが時間の経過とともにサイズが大きくなったり縮小したりすることが考えられます。VPNは、企業の合併、買収、提携契約のために融合することさえあります。これらの変更は、このアーキテクチャに対応するのが簡単です。グローバルに一意のIPリソースは、VPNに専用または割り当てられる必要がないためです。SPEDの数は、人工的な構成制限によって制限されません。
5. The SP owns and manages Layer 1 and Layer 2 entities. To be specific, the SP controls physical switches or routers, physical links, logical layer 2 connections (such as DLCI in Frame Relay and VPI/VCI in ATM) and LSPs (and their assignment to specific VPNs). In the context of VPNs, it is the SP's responsibility to contract and assign layer 2 entities to specific VPNs.
5. SPは、レイヤー1およびレイヤー2エンティティを所有および管理します。特に、SPは物理スイッチまたはルーター、物理リンク、論理レイヤー2接続（Frame RelayのDLCI、ATMのVPI/VCIなど）およびLSP（および特定のVPNへの割り当て）を制御します。VPNのコンテキストでは、レイヤー2エンティティを特定のVPNに契約および割り当てることはSPの責任です。
6. Layer 3 entities belong to and are manageable by the PNA. Examples of these entities include IP interfaces, choice of dynamic routing protocols or static routes, and routing interfaces. Note that although Layer 3 configuration logically falls under the PNA's area of responsibility, it is not necessary for the PNA to execute it. It is quite viable for the PNA to outsource the IP administration of the virtual routers to the Service Provider. Regardless of who assumes responsibility for configuration and monitoring, this approach provides a full routing domain view to the PNA and empowers the PNA to design the network to achieve intranet, extranet and traffic engineering goals.
6. レイヤー3エンティティは、PNAに属し、管理可能です。これらのエンティティの例には、IPインターフェイス、動的ルーティングプロトコルまたは静的ルートの選択、およびルーティングインターフェイスが含まれます。レイヤー3の構成は論理的にPNAの責任領域に該当するが、PNAがそれを実行する必要はないことに注意してください。PNAが仮想ルーターのIP管理をサービスプロバイダーに外部委託することは非常に実行可能です。誰が構成と監視の責任を負っているかに関係なく、このアプローチはPNAの完全なルーティングドメインビューを提供し、PNAにイントラネット、エクストラネット、トラフィックエンジニアリングの目標を達成するためのネットワークを設計する権限を与えます。
7. The VPNs can be managed as if physical routers rather than VRs were deployed. Therefore, management may be performed using SNMP or other similar methods or directly at the VR console (VRC).
7. VPNは、VRSではなく物理ルーターが展開されたかのように管理できます。したがって、管理は、SNMPまたは他の同様の方法を使用して、またはVRコンソール（VRC）で直接実行することができます。
8. Industry-standard troubleshooting tools such as 'ping,' 'traceroute,' in a routing domain domain comprised exclusively of dedicated physical routers. Therefore, monitoring and .bp troubleshooting may be performed using SNMP or similar methods, but may also include the use of these standard tools. Again, the VRC may be used for these purposes just like any physical router.
8. 専用の物理ルーターのみで構成されるルーティングドメインドメインの「Ping」、「Traceroute」などの業界標準のトラブルシューティングツール。したがって、監視と.BPのトラブルシューティングは、SNMPまたは同様の方法を使用して実行される場合がありますが、これらの標準ツールの使用も含める場合があります。繰り返しますが、VRCは、物理的なルーターと同じようにこれらの目的に使用できます。
9. Since the VRC is visible to the user, router specific security checks need to be put in place to make sure the VPN user is allowed access to Layer 3 resources in that VPN only and is disallowed from accessing physical resources in the router. Most routers achieve this through the use of database views.
9. VRCはユーザーに表示されるため、ルーター固有のセキュリティチェックを導入する必要があります。VPNユーザーがそのVPNのレイヤー3リソースへのアクセスのみを許可し、ルーターの物理リソースへのアクセスを許可されていません。ほとんどのルーターは、データベースビューを使用してこれを実現します。
10. The VRC is available to the SP as well. If configuration and monitoring has been outsourced to the SP, the SP may use the VRC to accomplish these tasks as if it were the PNA.
10. VRCもSPで利用できます。構成と監視がSPに外部委託されている場合、SPはVRCを使用してPNAであるかのようにこれらのタスクを達成することができます。
11. The VRs in the SPEDs form the VPN in the SP's network. Together, they represent a virtual routing domain. They dynamically discover each other by utilizing an emulated LAN resident in the SP's network.
11. SPEDSのVRSは、SPのネットワーク内のVPNを形成します。一緒に、それらは仮想ルーティングドメインを表します。彼らは、SPのネットワークにエミュレートされたLAN居住者を利用することにより、お互いを動的に発見します。
Each VPN in the SP's network is assigned one and only one multicast address. This address is chosen from the administratively scoped range (239.192/14) [Meyer] and the only requirement is that the multicast address can be uniquely mapped to a specific VPN. This is easily automated by routers by the use of a simple function to unambiguously map a VPNid to the multicast address. Subscription to this multicast address allows a VR to discover and be discovered by other VRs. It is important to note that the multicast address does not have to be configured.
SPのネットワーク内の各VPNには、1つのマルチキャストアドレスのみが割り当てられます。このアドレスは、管理上スコープ範囲（239.192/14）[Meyer]から選択されており、唯一の要件は、マルチキャストアドレスを特定のVPNに一意にマッピングできることです。これは、VPNIDをマルチキャストアドレスに明確にマッピングするために、単純な関数を使用することにより、ルーターによって簡単に自動化されます。このマルチキャストアドレスのサブスクリプションにより、VRは他のVRによって発見および発見されます。マルチキャストアドレスを構成する必要がないことに注意することが重要です。
12. Data forwarding may be done in one of several ways:
12. データ転送は、いくつかの方法のいずれかで行われる場合があります。
1. An LSP with best-effort characteristics that all VPNS can use.
1. すべてのVPNが使用できるベストエフォルト特性を持つLSP。
2. An LSP dedicated to a VPN and traffic engineered by the VPN customer.
2. VPN専用のLSPとVPN顧客がエンジニアリングしたトラフィック。
3. A private LSP with differentiated characteristics.
3. 区別された特性を持つプライベートLSP。
4. Policy based forwarding on a dedicated L2 Virtual Circuit
4. 専用のL2仮想回路でのポリシーベースの転送
The choice of the preferred method is negotiable between the SP and the VPN customer, perhaps constituting part of the SLA between them. This allows the SP to offer different grades of service to different VPN customers.
優先法の選択は、SPとVPN顧客の間で交渉可能であり、おそらくそれらの間のSLAの一部を構成します。これにより、SPはさまざまなVPN顧客にさまざまなサービスグレードを提供できます。
Of course, hop-by-hop forwarding is also available to forward routing packets and to forward user data packets during periods of LSP establishment and failure.
もちろん、LSPの確立と障害の期間中に、ルーティングパケットを転送したり、ユーザーデータパケットを転送するために、ホップバイホップ転送も利用できます。
13. This approach does not mandate that separate operating system tasks for each of the routing protocols be run for each VR that the SPED houses. Specific implementations may be tailored to the particular SPED in use. Maintaining separate routing databases and forwarding tables, one per VR, is one way to get the highest performance for a given SPED.
13. このアプローチでは、各ルーティングプロトコルの個別のオペレーティングシステムタスクが、SPED HOSEがHOSEである各VRに対して実行されることを義務付けていません。特定の実装は、使用中の特定のSPEDに合わせて調整される場合があります。個別のルーティングデータベースを維持し、VRごとに1つの転送テーブルを維持することは、特定のSPEDで最高のパフォーマンスを取得する1つの方法です。
A typical VPN is expected to have 100s to 1000s of endpoints within the SP cloud. Therefore, configuration should scale (at most) linearly with the number of end points. To be specific, the administrator should have to add a couple of configuration items when a new customer site joins the set of VRs constituting a specific VPN. Anything worse will make this task too daunting for the service provider. In this architecture, all that the service provider needs to allocate and configure is the ingress/egress physical link (e.g. Frame Relay DLCI or ATM VPI/VCI) and the virtual connection between the VR and the emulated LAN.
典型的なVPNには、SPクラウド内に100〜1000のエンドポイントがあると予想されます。したがって、構成は（せいぜい）エンドポイントの数で直線的に拡張する必要があります。具体的には、新しい顧客サイトが特定のVPNを構成するVRSのセットに参加したときに、管理者はいくつかの構成アイテムを追加する必要があります。さらに悪いことに、このタスクはサービスプロバイダーにとってあまりにも困難になります。このアーキテクチャでは、サービスプロバイダーが割り当てて構成する必要があるのは、Ingress/Eutressの物理リンク（Frame Relay DLCIまたはATM VPI/VCIなど）と、VRとエミュレートLANの間の仮想接続だけです。
The VRs in a given VPN reside in a number of SPEDs in the network. These VRs need to learn about each other and be connected.
特定のVPNのVRSは、ネットワーク内の多くのSPEDに存在します。これらのVRは、お互いについて学び、接続する必要があります。
One way to do this is to require the manual configuration of neighbors. As an example, when a new site is added to a VPN, this would require the configuration of all the other VRs as neighbors. This is obviously not scalable from a configuration and network resource standpoint.
これを行う1つの方法は、近隣の手動構成を要求することです。例として、新しいサイトがVPNに追加されると、他のすべてのVRを隣人として構成する必要があります。これは、構成およびネットワークリソースの観点から明らかにスケーラブルではありません。
The need then arises to allow these VRs to dynamically discover each other. Neighbor discovery is facilitated by providing each VPN with a limited emulated LAN. This emulated LAN is used in several ways:
その後、これらのVRがお互いを動的に発見できるようにする必要があります。近隣発見は、各VPNに限られたエミュレートされたLANを提供することにより促進されます。このエミュレートされたLANは、いくつかの方法で使用されます。
1. Address resolution uses this LAN to resolve next-hop (private) IP addresses associated with the other VRs.
1. アドレス解像度は、このLANを使用して、他のVRに関連付けられた次の（プライベート）IPアドレスを解決します。
2. Routing protocols such as RIP and OSPF use this limited emulated LAN for neighbor discovery and to send routing updates.
2. RIPやOSPFなどのルーティングプロトコルは、近隣発見およびルーティングの更新を送信するために、この限定されたエミュレートされたLANを使用します。
The per-VPN LAN is emulated using an IP multicast address. In the interest of conserving public address space and because this multicast address needs to be visible only in the SP network space, we would use an address from the Organizationally scoped multicast addresses (239.192/14) as described in [Meyer]. Each VPN is allocated an address from this range. To completely eliminate configuration in this regard, this address is computed from the VPNID.
VPNごとのLANは、IPマルチキャストアドレスを使用してエミュレートされます。パブリックアドレススペースを保護するために、およびこのマルチキャストアドレスはSPネットワークスペースでのみ表示する必要があるため、[Meyer]に記載されているように、組織的にスコープされたマルチキャストアドレス（239.192/14）のアドレスを使用します。各VPNには、この範囲からアドレスが割り当てられます。この点で構成を完全に排除するために、このアドレスはVPNIDから計算されます。
151.0.0.1
################
# #
# ROUTER 'A' #
# #
################
# #
# #
# #
# #
############# ###############
# # # #
# ROUTER 'B'# # ROUTER 'C' #
# # # #
# # # #
############# ###############
152.0.0.2 153.0.0.3
Figure 1 'Physical Routing Domain'
図1「物理的なルーティングドメイン」
The physical domain in the SP's network is shown in the above figure. In this network, physical routers A, B and C are connected together. Each of the routers has a 'public' IP address assigned to it. These addresses uniquely identify each of the routers in the SP's network.
SPのネットワークの物理ドメインは、上記の図に示されています。このネットワークでは、物理ルーターA、B、およびCが接続されています。各ルーターには、「パブリック」IPアドレスが割り当てられています。これらのアドレスは、SPのネットワーク内の各ルーターを一意に識別します。
172.150.0/18 172.150.128/18
----------------------- ---------------------------|
| | |
| | 172.150.128.1
| ROUTER 'A' (151.0.0.1) | |---------|
| ############# | |Parts DB |
| ---#-----------# | /---------/
| OSPF | # # ISIS | /----------/
------------|# VR - A #|--------------
#-------|---#-|
#############10.0.1/24
|----|------------#-#---------------|-----|
|10.0.0.2/24# # |10.0.0.3/24
|------|-------| # # ---------|-------|
| ############### # |############### |
| # VR - B |# # # VR - C # |
|#-------------# ROUTER 'B'##|------------#----
(152.0.0.2)############### ############### (153.0.0.3)
------------------------- ROUTER 'C' | Extranet
172.150.64/18 V
Vendors
Figure 2 'Virtual Routing Domain'
図2「仮想ルーティングドメイン」
Each Virtual Router is configurable by the PNA as though it were a private physical router. Of course, the SP limits the resources that this Virtual Router may consume on a SPED-by-SPED basis. Each VPN has a number of physical connections (to CPE routers) and a number of logical connections (to the emulated LAN). Each connection is IP-capable and can be configured to utilize any combination of the standard routing protocols and routing policies to achieve specific corporate network goals.
各仮想ルーターは、PNAによってプライベートの物理ルーターであるかのように構成可能です。もちろん、SPは、この仮想ルーターがSPEDごとに消費する可能性のあるリソースを制限します。各VPNには、多数の物理接続（CPEルーターへ）と多数の論理接続（エミュレートされたLAN）があります。各接続はIP対応であり、標準のルーティングプロトコルとルーティングポリシーの任意の組み合わせを利用して、特定の企業ネットワーク目標を達成するように構成できます。
To illustrate, in Figure 1, 3 VRs reside on 3 SPEDs in VPN 1. Router 'A' houses VR-A, router 'B' houses VR-B and router 'C' houses VR-C. VR-C and VR-B have a physical connection to CPE equipment, while VR-A has 2 physical connections. Each of the VRs has a fully IP-capable logical connection to the emulated LAN. VR-A has the (physical) connections to the headquarters of the company and runs OSPF over those connections. Therefore, it can route packets to 172.150.0/18 and 172.150.128/18. VR-B runs RIP in the branch office (over the physical connection) and uses RIP (over the logical connection) to export 172.150.64/18 to VR-A. VR-A advertises a default route to VR-B over the logical connection. Vendors use VR-C as the extranet connection to connect to the parts database at 172.150.128.1. Hence, VR-C advertises a default route to VR-A over the logical connection. VR-A exports only 175.150.128.1 to VR-C. This keeps the rest of the corporate network from a security problem.
説明するために、図1では、VPN 1の3つのSPEDに3つのVRが存在します。ルーター「A」はVR-A、ルーター「B」ハウスVR-B、およびルーター「C 'HOSE VR-C」があります。VR-CとVR-BにはCPE機器に物理的な接続があり、VR-Aには2つの物理的な接続があります。各VRSには、エミュレートされたLANへの完全なIP対応の論理接続があります。VR-Aは、会社の本部への（物理的な）接続を持ち、それらの接続を介してOSPFを実行しています。したがって、パケットを172.150.0/18および172.150.128/18にルーティングできます。VR-Bは支店でRIPを実行し（物理的な接続を越えて）、RIP（論理接続を越えて）を使用して172.150.64/18をVR-Aにエクスポートします。VR-Aは、論理接続を介してVR-Bへのデフォルトルートを宣伝します。ベンダーはVR-Cを使用してエクストラネット接続として使用して、172.150.128.1のパーツデータベースに接続します。したがって、VR-Cは、論理接続を介してVR-Aへのデフォルトルートを宣伝します。VR-Aは、175.150.128.1のみをVR-Cに輸出します。これにより、企業ネットワークの残りの部分がセキュリティの問題から維持されます。
The network administrator will configure the following:
ネットワーク管理者は次のように設定します。
1. OSPF connections to the 172.150.0/18 and 172.150.128/18 network in VR-A.
1. VR-Aの172.150.0/18および172.150.128/18ネットワークへのOSPF接続。
2. RIP connections to VR-B and VR-C on VR-A.
2. VR-AでVR-BとVR-CへのRIP接続。
3. Route policies on VR-A to advertise only the default route to VR-B.
3. VR-Bへのデフォルトルートのみを宣伝するためのVR-Aのルートポリシー。
4. Route policies on VR-A to advertise only 172.159.128.1 to VR-C.
4. VR-Aのルートポリシーは、VR-Cに172.159.128.1のみを宣伝します。
5. RIP on VR-B to VR-A.
5. VR-BでVR-Aにリップします。
6. RIP on VR-C to advertise a default route to VR-A.
6. VR-CをRIPして、デフォルトルートをVR-Aに宣伝します。
In Figure #1, the SPED that houses VR-A (SPED-A) uses a public address of 150.0.0.1/24, SPED-B uses 150.0.0.2/24 and SPED-C uses 150.0.0.3/24. As noted, the connection between the VRs is via an emulated LAN. For interface addresses on the emulated LAN connection, VR-A uses 10.0.0.1/24, VR-B uses 10.0.0.2/24 and VR-C uses 10.0.0.3/24.
図＃1では、VR-A（SPED-A）が150.0.0.1/24のパブリックアドレスを使用し、SPED-Bは150.0.0.2/24を使用し、SPED-Cは150.0.0.0.3/24を使用します。前述のように、VRS間の接続はエミュレートされたLANを介して行われます。エミュレートされたLAN接続のインターフェイスアドレスの場合、VR-Aは10.0.0.1/24を使用し、VR-Bは10.0.0.2/24を使用し、VR-Cは10.0.0.3/24を使用します。
Let's take the case of VR-A sending a packet to VR-B. To get VR-B's address (SPED-B's address), VR-A sends an ARP request packet with the address of VR-B (10.0.0.2) as the logical address. The source logical address is 10.0.0.1 and the hardware address is 151.0.0.1. This ARP request is encapsulated in this VPN's multicast address and sent out. SPED B and SPED-C receive a copy of the packet. SPED-B recognizes 10.0.0.2 in the context of VPN 1 and responds with 152.0.0.2 as the "hardware" address. This response is sent to the VPN multicast address to promote the use of promiscuous ARP and the resulting decrease in network traffic.
VR-AをVR-Bに送信するケースを見てみましょう。VR-Bのアドレス（SPED-Bのアドレス）を取得するために、VR-Aは、VR-B（10.0.0.2）のアドレスを記載したARPリクエストパケットを論理アドレスとして送信します。ソースの論理アドレスは10.0.0.1で、ハードウェアアドレスは151.0.0.1です。このARPリクエストは、このVPNのマルチキャストアドレスにカプセル化され、送信されます。Sped BとSped-Cは、パケットのコピーを受け取ります。SPED-Bは、VPN 1のコンテキストで10.0.0.2を認識し、152.0.0.2で「ハードウェア」アドレスとして応答します。この応答はVPNマルチキャストアドレスに送信され、無差別ARPの使用と結果として生じるネットワークトラフィックの減少を促進します。
Manual configuration would be necessary if neighbor discovery were not used. In this example, VR-A would be configured with a static ARP entry for VR-B's logical address (10.0.0.1) with the "hardware" address set to 152.0.0.2.
近隣の発見が使用されない場合は、手動構成が必要です。この例では、VR-Aは、VR-Bの論理アドレス（10.0.0.1）の静的ARPエントリで構成され、「ハードウェア」アドレスが152.0.0.2に設定されています。
As mentioned in the architectural outline, data forwarding may be done in one of several ways. In all techniques except the Hop-by-Hop technique for forwarding routing/control packets, the actual method is configurable. At the high end, policy based forwarding for quick service and at the other end best effort forwarding using public LSP is used. The order of forwarding preference is as follows:
アーキテクチャのアウトラインで述べたように、データ転送はいくつかの方法のいずれかで行われる場合があります。ルーティング/制御パケットを転送するためのホップバイホップ手法を除くすべての手法では、実際の方法が構成可能です。ハイエンドでは、迅速なサービスのためのポリシーに基づいた転送と、パブリックLSPを使用した最善の努力を他方の端で使用しています。転送の好みの順序は次のとおりです。
1. Policy based forwarding.
1. ポリシーベースの転送。
2. Optionally configured private LSP.
2. オプションで構成されたプライベートLSP。
3. Best-effort public LSP.
3. Best-Effort Public LSP。
This LSP is optionally configured on a per-VPN basis. This LSP is usually associated with non-zero bandwidth reservation and/or a specific differentiated service or QOS class. If this LSP is available, it is used for user data and for VPN private control data forwarding.
このLSPは、オプションでVPNごとに構成されています。このLSPは通常、ゼロ以外の帯域幅予約および/または特定の差別化されたサービスまたはQoSクラスに関連付けられています。このLSPが利用可能な場合、ユーザーデータとVPNプライベート制御データ転送に使用されます。
VPN data packets are forwarded using this LSP if a private LSP with specified bandwidth and/or QOS characteristics is either not configured or not presently available. The LSP used is the one destined for the egress router in VPN 0. The VPNID in the shim header is used to de-multiplex data packets from various VPNs at the egress router.
VPNデータパケットは、指定された帯域幅および/またはQoS特性を持つプライベートLSPが構成されていないか、現在利用できない場合、このLSPを使用して転送されます。使用されるLSPは、VPN 0の出力ルーターに向けられているものです。ShimヘッダーのVPNIDは、EgressルーターのさまざまなVPNからデータパケットを脱分類するために使用されます。
Configuring private LSPs for VPNs allows the SP to offer differentiated services to paying customers. These private LSPs could be associated with any available L2 QOS class or Diff-Serv codepoints. In a VPN, multiple private LSPs with different service classes could be configured with flow profiles for sorting the packets among the LSPs. This feature, together with the ability to size the virtual routers, allows the SP to offer truly differentiated services to the VPN customer.
VPN用のプライベートLSPを構成することで、SPは顧客に差別化されたサービスを提供できます。これらのプライベートLSPは、利用可能なL2 QoSクラスまたはDiff-Serv CodePointsに関連付けられている可能性があります。VPNでは、異なるサービスクラスを持つ複数のプライベートLSPを、LSP間でパケットをソートするためのフロープロファイルで構成できます。この機能は、仮想ルーターをサイズする機能とともに、SPがVPN顧客に真に差別化されたサービスを提供できるようにします。
The use of standard routing protocols such as OSPF and BGP in their unmodified form means that all the encryption and security methods (such as MD5 authentication of neighbors) are fully available in VRs. Making sure that routes are not accidentally leaked from one VPN to another is an implementation issue. One way to achieve this is to maintain separate routing and forwarding databases.
OSPFやBGPなどの標準的なルーティングプロトコルの使用は、変更されていない形式で使用することは、すべての暗号化とセキュリティ方法（近隣のMD5認証など）がVRSで完全に利用可能であることを意味します。あるVPNから別のVPNに誤って漏れていないことを確認することは、実装の問題です。これを達成する1つの方法は、個別のルーティングと転送データベースを維持することです。
This allows the SP to assure the VPN customer that data packets in one VPN never have the opportunity to wander into another. From a routing standpoint, this could be achieved by maintaining separate routing databases for each virtual router. From a data forwarding standpoint, the use of label stacks in the case of shared LSPs [Rosen2] [Callon] or the use of private LSPs guarantees data privacy. Packet filters may also be configured to help ease the problem.
これにより、SPはVPN顧客に、あるVPNのデータパケットが別のVPNにさまよう機会がないことを保証できます。ルーティングの観点からは、各仮想ルーターの個別のルーティングデータベースを維持することでこれを実現できます。データ転送の観点から、共有LSP [Rosen2] [Callon]の場合のラベルスタックの使用またはプライベートLSPの使用は、データプライバシーを保証します。パケットフィルターは、問題を容易にするために構成することもできます。
Virtual routers appear as physical routers to the PNA. This means that they may be configured by the PNA to achieve connectivity between offices of a corporation. Obviously, the SP has to guarantee that the PNA and the PNA's designees are the only ones who have access to the VRs on the SPEDs the private network has connections to. Since the virtual router console is functionally equivalent to a physical router, all of the authentication methods available on a physical console such as password, RADIUS, etc. are available to the PNA.
仮想ルーターは、PNAの物理ルーターとして表示されます。これは、企業のオフィス間の接続性を実現するためにPNAによって構成される可能性があることを意味します。明らかに、SPは、PNAとPNAの指名者が、プライベートネットワークが接続しているSPEDSのVRSにアクセスできる唯一のものであることを保証する必要があります。仮想ルーターコンソールは物理ルーターと機能的に同等であるため、パスワード、半径などの物理コンソールで利用可能な認証方法はすべてPNAが利用できます。
When a PNA logs in to a SPED to configure or monitor the VPN, the PNA is logged into the VR for the VPN. The PNA has only layer 3 configuration and monitoring privileges for the VR. Specifically, the PNA has no configuration privileges for the physical network. This provides the guarantee to the SP that a VPN administrator will not be able to inadvertently or otherwise adversely affect the SP's network.
PNAがSPEDにログインしてVPNを構成または監視すると、PNAはVPNのVRにログインします。PNAには、VRのレイヤー3構成と監視特権のみがあります。具体的には、PNAには物理ネットワークの構成特権がありません。これにより、VPN管理者がSPのネットワークに不注意にまたは悪影響を与えることができないことがSPに保証されます。
All of the router monitoring features available on a physical router are available on the virtual router. This includes utilities such as "ping" and "traceroute". In addition, the ability to display private routing tables, link state databases, etc. are available.
物理ルーターで利用可能なルーター監視機能はすべて、仮想ルーターで利用できます。これには、「ping」や「traceroute」などのユーティリティが含まれます。さらに、プライベートルーティングテーブル、リンク状態データベースなどを表示する機能が利用可能です。
For the purposes of discussing performance and scaling issues, today's routers can be split into two planes: the routing (control) plane and the forwarding plane.
パフォーマンスとスケーリングの問題について議論する目的で、今日のルーターはルーティング（コントロール）プレーンと転送面の2つの平面に分割できます。
In looking at the routing plane, most modern-day routing protocols use some form of optimized calculation methodologies to calculate the shortest path(s) to end stations. For instance, OSPF and ISIS use the Djikstra algorithm while BGP uses the "Decision Process". These algorithms are based on parsing the routing database and computing the best paths to end stations. The performance characteristics of any of these algorithms is based on either topological characteristics (ISIS and OSPF) or the number of ASs in the path to the destinations (BGP). But it is important to note that the overhead in setting up and beginning these calculations is very little for most any modern day router. This is because, although we refer to routing calculation input as "databases", these are memory resident data structures.
ルーティングプレーンを見ると、現代のほとんどのルーティングプロトコルは、何らかの形の最適化された計算方法論を使用して、ステーションからエンドステーションへの最短パスを計算します。たとえば、OSPFとISISはDJIKSTRAアルゴリズムを使用し、BGPは「決定プロセス」を使用します。これらのアルゴリズムは、ルーティングデータベースを解析し、エンドステーションへの最適なパスを計算することに基づいています。これらのアルゴリズムのいずれかのパフォーマンス特性は、トポロジー特性（ISISおよびOSPF）または目的地への経路（BGP）のASSの数に基づいています。しかし、これらの計算のセットアップと開始におけるオーバーヘッドは、ほとんどの現代のルーターではほとんどないことに注意することが重要です。これは、ルーティング計算入力を「データベース」と呼んでいるが、これらはメモリ居住データ構造であるためです。
Therefore, the following conclusions can be drawn:
したがって、次の結論を導き出すことができます。
1. Beginning a routing calculation for a routing domain is nothing more than setting up some registers to point to the right database objects.
1. ルーティングドメインのルーティング計算を開始することは、適切なデータベースオブジェクトを指すためにいくつかのレジスタを設定することにすぎません。
2. Based on 1, the performance of a given algorithm is not significantly worsened by the overhead required to set it up.
2. 1に基づいて、特定のアルゴリズムのパフォーマンスは、セットアップに必要なオーバーヘッドによって有意に悪化していません。
3. Based on 2, it follows that, when a number of routing calculations for a number of virtual routers has to be performed by a physical router, the complexity of the resulting routing calculation is nothing more than the sum of the complexities of the routing calculations of the individual virtual routers.
3. 2に基づいて、物理ルーターによって多数の仮想ルーターのルーティング計算を実行する必要がある場合、結果のルーティング計算の複雑さは、ルーティング計算の複雑さの合計にすぎないことになります。個々の仮想ルーター。
4. Based on 3, it follows that whether an overlay model is used or a virtual routing model is employed, the performance characteristics of a router are dependent purely on its hardware capabilities and the choice of data structures and algorithms.
4. 3に基づいて、オーバーレイモデルが使用されるか仮想ルーティングモデルが使用されているかにかかわらず、ルーターのパフォーマンス特性は、そのハードウェア機能とデータ構造とアルゴリズムの選択に純粋に依存します。
To illustrate, let's say a physical router houses N VPNs, all running some routing protocol say RP. Let's also suppose that the average performance of RP's routing calculation algorithm is f(X,Y) where x and y are parameters that determine performance of the algorithm for that routing protocol. As an example, for Djikstra algorithm users such as OSPF, X could be the number of nodes in the area while Y could be the number of links. The performance of an arbitrary VPN n is f (Xn, Yn). The performance of the (physical) router is the sum of f(Xi, Yi) for all values of i in 0 <= i <= N. This conclusion is independent of the chosen VPN approach (virtual router or overlay model).
説明するために、物理的なルーターがn VPNをハウスにして、すべてのルーティングプロトコルを実行していると言ってみましょう。また、RPのルーティング計算アルゴリズムの平均パフォーマンスはf（x、y）であると仮定します。ここで、xとyはそのルーティングプロトコルのアルゴリズムのパフォーマンスを決定するパラメーターです。例として、OSPFなどのDJIKSTRAアルゴリズムユーザーの場合、Xはエリア内のノードの数であり、yはリンクの数になる可能性があります。任意のVPN nのパフォーマンスはf（xn、yn）です。（物理）ルーターのパフォーマンスは、0 <= i <= NのIのすべての値のF（xi、yi）の合計です。この結論は、選択したVPNアプローチ（仮想ルーターまたはオーバーレイモデル）とは無関係です。
In the usual case, the forwarding plane has two inputs: the forwarding table and the packet header. The main performance parameter is the lookup algorithm. The very best performance one can get for a IP routing table lookup is by organizing the table as some form of a tree and use binary search methods to do the actual lookup. The performance of this algorithm is O(log n).
通常の場合、転送面には、転送テーブルとパケットヘッダーの2つの入力があります。主なパフォーマンスパラメーターは、ルックアップアルゴリズムです。IPルーティングテーブルの検索で得られる最高のパフォーマンスは、テーブルを何らかの形のツリーとして整理し、バイナリ検索方法を使用して実際の検索を行うことです。このアルゴリズムのパフォーマンスはO（log n）です。
Hence, as long as the virtual routers' routing tables are distinct from each other, the lookup cost is constant for finding the routing table and O(log n) to find the entry. This is no worse or different from any router and no different from a router that employs overlay techniques to deliver VPN services. However, when the overlay router utilizes integration of multiple VPNs' routing tables, the performance is O(log m*n) where 'm' is the number of VPNs that the routing table holds routes for.
したがって、仮想ルーターのルーティングテーブルが互いに異なる限り、ルーティングテーブルとo（log n）を見つけるためにエントリを見つけるためのルックアップコストは一定です。これは、あらゆるルーターと悪化または違いはなく、オーバーレイテクニックを使用してVPNサービスを提供するルーターと違いはありません。ただし、オーバーレイルーターが複数のVPNのルーティングテーブルの統合を使用する場合、パフォーマンスはo（log m*n）で、「m」はルーティングテーブルがルートを保持するVPNの数です。
The authors wish to thank Dave Ryan, Lucent Technologies for his invaluable in-depth review of this version of this memo.
著者は、このメモのこのバージョンの非常に詳細なレビューについて、Lucent TechnologiesのDave Ryanに感謝します。
[Callon] Callon R., et al., "A Framework for Multiprotocol Label Switching", Work in Progress.
[Callon] Callon R.、et al。、「マルチプロトコルラベルスイッチングのフレームワーク」、進行中の作業。
[Fox] Fox, B. and B. Gleeson,"Virtual Private Networks Identifier", RFC 2685, September 1999.
[Fox] Fox、B。およびB. Gleeson、「仮想プライベートネットワーク識別子」、RFC 2685、1999年9月。
[Meyer] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[Meyer] Meyer、D。、「管理上スコープIPマルチキャスト」、RFC 2365、1998年7月。
[Rosen1] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[Rosen1] Rosen、E。およびY. Rekhter、「BGP/MPLS VPNS」、RFC 2547、1999年3月。
[Rosen2] Rosen E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", Work in Progress.
[Rosen2] Rosen E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、Work in Progress。
Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford, MA 01886
Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford、MA 01886
Phone: (978) 952-1368 EMail: mkarthik@lucent.com
電話：（978）952-1368メール：mkarthik@lucent.com
Andrew Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134
Andrew Malis Vivace Networks、Inc。2730 Orchard Parkway San Jose、CA 95134
Phone: (408) 383-7223 EMail: Andy.Malis@vivacenetworks.com
電話：（408）383-7223メール：andy.malis@vivacenetworks.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。