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
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.
著作権（C）インターネット協会（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）を実行しているを使用しています。中央のビジョンは、顧客に仮想ルータサービスを提供するサービスプロバイダのです。彼らはいずれかの変更を加えることなく、今日存在するとして、このアーキテクチャの要石は、設定の容易さ、ユーザーのセキュリティ、ネットワークセキュリティ、ダイナミック近隣探索、スケーリング、既存のルーティングプロトコルを使用しています。
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
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の可能なアプローチは、自分自身を提示：オーバーレイモデルと仮想ルータのアプローチを。オーバーレイモデルは、到達可能性情報を運ぶために、既存のルーティングプロトコルの（複数の）いくつかのセマンティックを過負荷に基づいています。この文書では、我々は、仮想ルータサービスに焦点を当てます。
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が所有し、レイヤ3つのサービスはに属し、PNAで管理している間レイヤ1とレイヤ2つのサービスを管理します。完全に論理的に独立したルーティングドメインのプロビジョニングすることにより、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.
このメモで信奉アプローチは、VPNルートを運ぶためにオーバーロードされていることは、特定のルーティングプロトコルにRFC 2547 [Rosen1]に記載されたものとは異なります。 RFC 2547には、SPのバックボーン間でVPNユニキャストルートを運ぶためにBGPを変更する方法を指定します。マルチキャストルートを運ぶために、さらに建築作業が必要になります。
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:
仮想ルータをエミュレートする必要があるルータの側面は、次のとおりです。
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が追加されたときに最大で、構成の一枚が必要になるはずです。
2. No use of SP resources that are globally unique and hard to get such as IP addresses and subnets.
2.グローバルにユニークかつ困難なSPリソースの使用なしには、IPアドレスやサブネットなどを取得することがありません。
3. Dynamic discovery of VRs (Virtual Routers) in the SP's cloud. This is an optional, but extremely valuable "keep it simple" goal.
SPのクラウドでのVRの3動的検出（仮想ルーター）。これはオプションですが、「それをシンプルに保つ」非常に貴重なゴールです。
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、ネットワーク管理者によって完全に構成および監視可能でなければなりません。これは、自分自身をVPN設定やSPに設定作業を外注のいずれかに柔軟性を持つPNAを提供します。
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-によって-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-によって-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.セキュリティは、仮想ルーターに拡張しました。これは、仮想ルータのデータ転送およびルーティングの機能は、専用の、プライベートの物理的なルータと同様に安全でなければならないことを意味します。もう1つのルーティングドメインからの意図しない情報の漏洩（ユーザデータおよび到達可能性情報）があってはなりません。
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 [フォックス]に準拠されることが必要とされていません。
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のクラウドのエッジに限定されます。 VRが、データや制御パケット転送のための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. VRの「サイズ」は、ルーティングインターフェース、ルートフィルタ、ルーティングエントリ等これはSPの制御下に完全であるようにIP資源の量によって表される所与SPEDでVPNに収縮し、罰金を提供しますSPごとのSPEDレベルにVRサービスの事実上無限のグレードを提供するために必要な細かさ。 [例：1 SPEDが凝集点であってもよい所与のVPN用の（会社の本社は言う）と他のSPEDsの数は、アクセスポイント（支社）であってもよいです。ブランチオフィスに接続SPEDsが小さく、おそらくスタブのVRを収容できるが、この場合、本社に接続SPEDは】大型VRを提供するように収縮することができます。この規定はまた、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.
VPNサイズの4つの指標は、VPN内のCPEルータへの接続を持っているSPのネットワーク内SPEDsの数です。いくつかのサイトとの1が「小さい」VPNであるのに対し、この点では、接続する必要があり、多くのサイトでのVPNは、「大規模な」VPNです。また、VPNが成長したり時間をかけてサイズに縮小していると考えられます。 VPNはさえにより、企業の合併、買収、提携協定に合併します。これらの変更は、グローバルに一意のIPリソースが専用またはVPNに割り当てられている必要はありませんように、このアーキテクチャに対応するのは簡単です。 SPEDsの数は、任意の人工的なコンフィギュレーションの制限によって限定されるものではありません。
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は、物理的なスイッチやルータ、物理リンク、論理層（ATM、フレームリレーとVPI / VCIにおけるこのようなDLCIのような）2つの接続とのLSP（および特定のVPNへの割り当て）を制御します。 VPNのコンテキストでは、特定のVPNにレイヤ2つのエンティティを契約して割り当てるための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).
物理的なルータではなく、のVRが展開されているかのよう7. VPNは、管理することができます。したがって、管理は、VRコンソール（VRC）で直接SNMPまたは他の類似の方法を使用して行ってもよいです。
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業界標準のトラブルシューティングツール。したがって、監視およびトラブルシューティング.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.
VRCがユーザーに表示されるので9.、ルータ、特定のセキュリティチェックは必ず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に委託されている場合、それはPNAであるかのように、SPは、これらのタスクを達成するためにVRCを使用することができます。
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.
SPEDs 11. VRが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は、唯一のマルチキャストアドレスが割り当てられます。このアドレスは管理用スコープ範囲（239.192 / 14）[マイヤー]から選択され、唯一の要件は、マルチキャストアドレスが一意に特定VPNにマッピングすることができることです。これは、簡単に明確マルチキャストアドレスにVPNIDをマッピングするために簡単な関数を使用することにより、ルータによって自動化されています。このマルチキャストアドレスへの加入は、VRを発見することができますし、他のVRによって発見すること。マルチキャスト・アドレスを設定する必要はないことに注意することが重要です。
2. An LSP dedicated to a VPN and traffic engineered by the VPN customer.
【請求項2】LSPは、VPNの顧客によって設計VPNおよびトラフィック専用します。
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.
好適な方法の選択は、おそらくそれらの間のSLAの一部を構成し、SPとVPNの顧客との間で交渉可能です。これは、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家というルーティングプロトコルごとに、別々のオペレーティングシステムのタスクは、各VRのために実行することを強制しません。特定の実装は、使用中の特定のSPEDに合わせて調整することができます。別のルーティングデータベースおよび転送テーブルを維持し、VRごとに1つ、与えられたSPEDのための最高のパフォーマンスを得るための一つの方法です。
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クラウド内のエンドポイントの1000年代に数百を持つことが期待されています。したがって、コンフィギュレーションは、エンドポイントの数と共に直線的に（最大で）スケーリングすべきです。具体的には、管理者が新しい顧客サイトは、特定のVPNを構成するのVRのセットを結合したときに、構成アイテムのカップルを追加する必要があります。より悪いものは、サービスプロバイダのために、このタスクはあまりにも困難なようになります。このアーキテクチャでは、サービスプロバイダが割り当てて設定する必要があり、その全ては、入口/出口物理リンク（例えばリレー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内のVRは、ネットワーク内SPEDsの数に存在します。これらの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が動的に互いを発見できるようにするために生じます。近隣探索は限らエミュレートLANで各VPNを提供することによって容易になります。これは、LANは、いくつかの方法で使用されているエミュレート：
1. Address resolution uses this LAN to resolve next-hop (private) IP addresses associated with the other VRs.
1.アドレス解決は、他のVRに関連付けられている次のホップ（プライベート）IPアドレスを解決するために、このLANを使用しています。
2. Routing protocols such as RIP and OSPF use this limited emulated LAN for neighbor discovery and to send routing updates.
RIPやOSPFなど2.ルーティングプロトコルは、これを使用する近隣探索のための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ネットワーク空間に表示する必要があるため、我々は組織的からのアドレスを使用するマルチキャストアドレス（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バイ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に、例示するために、3つのVRは、VPNルータ1 'A' 家VR-A、ルータ 'B' 家VR-Bとルータ3 SPEDs 'C' 家VR-Cに存在します。 VR-Aは、2つの物理接続を有しているVR-CおよびVR-Bは、CPE装置への物理接続を有しています。 VRのそれぞれは、エミュレートLANへの完全IP対応の論理接続を持っています。 VR-Aは、企業の本社への（物理的）な接続を持っており、それらの接続を介してOSPFを実行します。したがって、ルートパケット172.150.0 / 18および172.150.128 / 18にすることができます。 VR-Bは、（物理的接続を介して）支店でRIPを実行し、VR-Aに172.150.64 / 18をエクスポートする（論理的接続を介して）、RIPを使用します。 VR-Aは、論理的な接続を介してVR-Bへのデフォルトルートをアドバタイズします。ベンダーが172.150.128.1で部品データベースに接続するエクストラネット接続としてVR-Cを使用します。したがって、VR-Cは、論理的接続を介してVR-Aにデフォルトルートをアドバタイズ。 VR-Aの輸出VR-Cにのみ175.150.128.1。これは、セキュリティ上の問題から企業ネットワークの残りの部分を保持します。
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.
VR-Aで172.150.0 / 18および172.150.128 / 18ネットワーク1. OSPF接続。
3. Route policies on VR-A to advertise only the default route to VR-B.
VR-BにのみデフォルトルートをアドバタイズするVR-Aの3ルートポリシー。
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は、SPED-Bは150.0.0.2/24を使用し、SPED-Cは150.0.0.3/24を使用します。述べたように、仮想ルーターとの間の接続は、エミュレートされた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-Bにパケットを送信するVR-Aの場合を見てみましょう。 VR-Bのアドレス（SPED-Bのアドレス）を取得するには、VR-Aは、論理アドレスとしてVR-B（10.0.0.2）のアドレスでARP要求パケットを送信します。ソース論理アドレスは10.0.0.1であり、ハードウェアアドレスは151.0.0.1です。このARP要求は、このVPNのマルチキャストアドレスでカプセル化して送信されます。 BとSPED-Cは、パケットのコピーを受信SPED。 SPED-BはVPN 1の文脈で10.0.0.2を認識し、「ハードウェア」アドレスとして152.0.0.2で応答します。この応答は、無差別ARPを使用してネットワークトラフィックの結果の減少を促進するためにVPNマルチキャストアドレスに送信されます。
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は、152.0.0.2に設定された「ハードウェア」アドレスとVR-Bの論理アドレス（10.0.0.1）の静的ARPエントリを使用して構成されることになります。
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を使用して、もう一方の端のベストエフォート転送でポリシーベースの転送が使用されています。次のように転送の優先順位は次のとおりです。
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はVPNIDがシムヘッダに出口ルータで各種のVPNからのデータパケット多重を解除するために使用されるVPN 0で出口ルータ宛のものです。
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のコードポイントに関連付けることができます。 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認証など）は、すべての暗号化およびセキュリティ方法は、仮想ルーターで完全に利用可能であることを意味します。必ずルートが誤って別の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が1 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上のVRへのアクセス権を持っている唯一のものであることを保証しなければなりません。仮想ルータコンソールは物理的ルータと機能的に同等であるので、等パスワード、RADIUSなどの物理的なコンソール上で利用可能な認証方法の全ては、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は、VPNを設定したり、監視するためにSPEDにログインすると、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.
物理ルータ上で利用できるルータ監視機能のすべては、仮想ルータで利用できます。これは、「ピング」と「トレースルート」などのユーティリティが含まれています。また、などのプライベートルーティングテーブル、リンク状態データベースを表示する機能が用意されています。
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.
ルーティング（コントロール）プレーンとフォワーディングプレーン：パフォーマンスを議論し、課題をスケーリングする目的のために、今日のルータは、二つの面に分割することができます。
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.
ルーティング面を見ると、ほとんどの現代のルーティングプロトコルは、エンドステーションに最短経路（単数または複数）を計算するために最適化された計算方法のいくつかのフォームを使用します。 BGPは、「意思決定プロセス」を使用しながら、例えば、OSPFおよびISISはDjikstraアルゴリズムを使用します。これらのアルゴリズムは、ルーティングデータベースを解析し、エンドステーションに最良経路を計算に基づいています。これらのアルゴリズムのいずれかの性能特性は、いずれかのトポロジー特性（ISISおよびOSPF）または宛先（BGP）へのパスでのASの数に基づいています。しかし、設定とこれらの計算を始めにおけるオーバーヘッドはほとんどすべての現代のルータのための非常に少ないことに注意することが重要です。私たちは、「データベース」として計算入力のルーティングを参照してくださいが、これらはメモリ常駐のデータ構造であり、これはあります。
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を言います。のもRPのルーティング計算アルゴリズムの平均パフォーマンスは、xおよびyは、そのルーティングプロトコルのためのアルゴリズムの性能を決定するパラメータであり、F（X、Y）であると仮定する。 Yは、リンクの数とすることができるが、一例として、OSPFなどDjikstraアルゴリズムユーザーのために、Xは、領域内のノードの数であってもよいです。任意VPN nの性能がf（Xnを、アルキニル）です。 （物理的な）ルータの性能は0で、iの全ての値について、F（XI、李）の和である<=私はこの結論は、選択されたVPNのアプローチ（仮想ルータまたはオーバーレイモデル）から独立している= Nを<
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（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（ログn）を求めるための定数です。これは悪くない、または異なる任意のルータからとVPNサービスを提供するために、オーバーレイ技術を用いるルータと違いはありません。オーバレイルータが複数のVPNの統合利用する場合しかし、M 『は、ルーティングテーブルは、のルートを保持しているVPNの数であるルーティングテーブルを、性能はO（M×n個のログ）です』。
The authors wish to thank Dave Ryan, Lucent Technologies for his invaluable in-depth review of this version of this memo.
著者は、このメモのこのバージョンの彼の貴重で詳細なレビューのためにデイブ・ライアン、ルーセント・テクノロジーに感謝したいです。
[Callon] Callon R., et al., "A Framework for Multiprotocol Label Switching", Work in Progress.
【Callon] Callon R.、ら。、 "マルチプロトコルラベルスイッチングのためのフレームワーク"、ProgressのWork。
[Fox] Fox, B. and B. Gleeson,"Virtual Private Networks Identifier", RFC 2685, September 1999.
[フォックス]フォックス、B.及びB.グリーソン、 "仮想プライベートネットワーク識別子"、RFC 2685、1999年9月。
[Meyer] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[マイヤー]マイヤー、D.、 "管理スコープのIPマルチキャスト"、RFC 2365、1998年7月には。
[Rosen1] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
【Rosen1]ローゼン、E.およびY. Rekhter、 "BGP / MPLS VPNの"、RFC 2547、1999年3月。
[Rosen2] Rosen E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", Work in Progress.
[Rosen2]ローゼンE.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、進行中の作業。
Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford, MA 01886
カルティクMuthukrishnanルーセント・テクノロジーズ1ロビンス・ロードウェストフォード、MA 01886
Phone: (978) 952-1368 EMail: mkarthik@lucent.com
電話：（978）952-1368 Eメール：mkarthik@lucent.com
Andrew Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134
アンドリューMalisヴィヴァーチェネットワークス株式会社2730オーチャードパークウェイサンノゼ、CA 95134
Phone: (408) 383-7223 EMail: Andy.Malis@vivacenetworks.com
電話：（408）383-7223 Eメール：Andy.Malis@vivacenetworks.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。