RFC2917 日本語訳
2917 A Core MPLS IP VPN Architecture. K. Muthukrishnan, A. Malis. September 2000. (Format: TXT=35352 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Muthukrishnan
Request for Comments: 2917 Lucent Technologies
Category: Informational A. Malis
Vivace Networks, Inc.
September 2000
Muthukrishnanがコメントのために要求するワーキンググループK.をネットワークでつないでください: 2917年のルーセントテクノロジーズカテゴリ: 情報のA.Malis活発なネットワークInc.2000年9月
A Core MPLS IP VPN Architecture
コアMPLS IP VPNアーキテクチャ
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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バックボーンにおけるビルコアVirtual兵士のNetwork(VPN)サービスのためのアプローチを提示します。 このアプローチは、ベストエフォート型サービスに加えたプレミアムサービスを提供するためにバックボーンへ駆け込みながら、Multiprotocol Label Switching(MPLS)を使用します。 中央のビジョンはサービスプロバイダーが彼らの顧客に対する仮想のルータサービスを提供することです。 今日少しも変更なしで存在するとき、このアーキテクチャのかなめ石は、既存のルーティング・プロトコルの構成の容易さと、ユーザ保証と、ネットワーク保証と、ダイナミックな隣人発見と、スケーリングと使用です。
1. Acronyms
1. 頭文字語
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 Address ResolutionプロトコルCE Customer EdgeルータLSP Label Switched Path PNA兵士のNetwork Administrator SLAサービス・レベル・アグリーメント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
Muthukrishnan & Malis Informational [Page 1] RFC 2917 Core VPNs September 2000
[1ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
2. Introduction
2. 序論
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つの可能なアプローチが浮かびます: オーバレイモデルと仮想のルータに近づきます。 オーバレイモデルは可到達性情報を運ぶために既存のルーティング・プロトコルのいくつかの意味(s)を積みすぎるのに基づいています。 本書では、私たちは仮想のルータサービスに焦点を合わせます。
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に与えました。 共有されたLSPsの上でラベルスタックを使用する個人的なLSPsの使用と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ルートを運ぶために積みすぎられていないのでRFC2547[Rosen1]で説明されたそれと異なっています。 RFC2547はSPのバックボーンの向こう側にVPNユニキャストルートを運ぶようにBGPを変更する方法を指定します。 マルチキャストルートを運ぶために、さらなる建築仕事は必要になるでしょう。
3. Virtual Routers
3. 仮想のルータ
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
ユーザ(VPN顧客)見地から、仮想のルータができるだけ物理的なルータに同等であることは、必須です。 言い換えれば、非常に小さい方の、そして、ほんのわずかな例外で、仮想のルータはすべての目的(構成、管理、モニター、およびトラブルシューティング)のためにひたむきな物理的なルータのように見えるべきです。 The
Muthukrishnan & Malis Informational [Page 2] RFC 2917 Core VPNs September 2000
[2ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
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.
この要件の後ろの主な動機は、ルータの大きいインストールされたベースをアップグレードするか、または再構成するのを避けて、ネットワーク管理者に再教育するのを避けることです。
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には、論理的に独立している経路ドメインがあります。 これは1VPNあたりの物理的なルータを必要としないでSPの顧客に完全に役立つことができる完全にフレキシブルな仮想のルータサービスを提供するSPの性能を高めます。 これは、複数の顧客がSPの「ハードウェア」投資(それらの間のすなわち、ルータとリンク)を再使用できることを意味します。
4. Objectives
4. 目的
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(仮想のRouters)のダイナミックな発見。 これは「それを簡単に保ってください」という任意の、しかし、非常に貴重な目標です。
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. 仮想のRoutersは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ごとのベースで構成可能であるべきです。 これは連続して(恐らく離散的)のサービスのグレードに翻訳されるべきです。 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の推進データ通信量に、差別化されたサービスは恐らく専用に用意ができているLSPsに基づいてVPNごとのベースで構成可能であるべきです。
Muthukrishnan & Malis Informational [Page 3] RFC 2917 Core VPNs September 2000
[3ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
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、リップ、イシスOSPFなどの既存のルーティング・プロトコルへの特別な拡大がありません。 これはNHRPやマルチキャストなどの他のサービスの将来の追加を許容するのに重要です。 さらに、進歩と付加物を既存のプロトコル(イシスとOSPFへの交通工学拡大などの)にするとき、容易にVPN実装にそれらを組み入れることができます。
5. Architectural Requirements
5. 建築要件
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またはいかなる他のプロトコルも実行するかもしれません。
6. Architectural Outline
6. 建築アウトライン
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. SPのネットワークの中でユニークなVPNIDはあらゆるVPNに割り当てられます。 この識別子は明白に、パケットか接続が関連しているVPNを特定します。 ゼロのVPNIDは予約されています。 それは、公共のインターネットを関連づけられて、表します。 推薦されますが、これらのVPN識別子がRFC2685[フォックス]と共に対応であることが必要ではありません。
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. Virtual Routerサービスの形でVPNサービスを提供します。 これらのVRsは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
3. 与えられたSPEDのVPNに契約されたVRの「サイズ」はルーティングインタフェース、ルートルーティングエントリーフィルタなどのIPリソースの量によって言い表されます。 これは、完全にSPのコントロールの下にあって、すばらしい粒状を提供します。
Muthukrishnan & Malis Informational [Page 4] RFC 2917 Core VPNs September 2000
[4ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
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.
SPは1SPEDあたり1つのレベルで実際には無限のVRサービスのグレードを申し出に必要とします。 [例: 1SPEDが与えられたVPNのための集合ポイントであるかもしれません(会社の本部を示す)、そして、SPEDsが(支店) アクセスポイントがこの場合本部に接続されたSPEDであったならそうするかもしれない他の数は支店に接続されたSPEDsがそうするかもしれませんが、大きいVRを提供するために契約されて、小ささ恐らく家が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つのインディケータがSPのネットワークで、CPEルータには接続がそのVPNにあるSPEDsの数です。 この点で、接続される必要がある多くのサイトがあるVPNは「大きい」VPNですが、いくつかのサイトがある1つは「小さい」VPNです。 また、VPNが成長するか、または時間がたつにつれて小さくなるのが想像できます。 VPNsは企業の合併、獲得、および組み協定のため合併さえするかもしれません。 これらの変化はこのアーキテクチャで収容しやすいです、グローバルにユニークなIPリソースがVPNsに捧げられる必要はありませんし、また割り当てられる必要はないとき。 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はLayer1とLayer2実体を所有して、管理します。 具体的に言うと、SPは物理的なスイッチかルータと、物理的なリンクと、論理的な層2の接続(Frame RelayのDLCIやATMのVPI/VCIなどの)とLSPs(そして、特定のVPNsへの彼らの課題)を監督します。 VPNsの文脈では、契約して、特定のVPNsへの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インタフェースかダイナミックルーティングプロトコルの選択かスタティックルートと、ルーティングインタフェースを含んでいます。 Layer3構成がPNAの担当地域の下で論理的に下がりますが、PNAがそれを実行するのは必要でないことに注意してください。 PNAが仮想のルータのIP運営をService Providerに社外調達するのは、かなり実行可能です。 だれが構成とモニターへの責任を負うかにかかわらず、このアプローチは、完全な経路ドメイン眺望を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. まるでVRsよりむしろ物理的なルータが配布されるかのようにVPNsに対処できます。 したがって、管理がSNMPか他の同様のメソッドを使用することで実行されるか、直接VRコンソール(VRC)にあるかもしれません。
Muthukrishnan & Malis Informational [Page 5] RFC 2917 Core VPNs September 2000
[5ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
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.
9. ユーザにとって、VRCが目に見えるので、ルータの特定のセキュリティチェックは、物理資源にアクセスするので、VPNユーザがLayer3リソースへのアクセスがそのVPNだけで許されていて、ルータで禁じられるのを確実にするために適所に置かれる必要があります。 ほとんどのルータがデータベース視点の使用でこれを実現します。
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は、まるでそれがPNAであるかのようにこれらのタスクを達成するのに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.
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.
1つの唯一無二のマルチキャストアドレスがSPのネットワークにおける各VPNに割り当てられます。 このアドレスは行政上見られた範囲(239.192/14)[マイヤー]から選ばれています、そして、唯一の要件は唯一マルチキャストアドレスを特定のVPNに写像できるということです。 これはルータによって簡単な機能の使用で容易に自動化されて、明白にマルチキャストアドレスにVPNidを写像します。 このマルチキャストアドレスの購読が、VRが発見して、別に発見されるのを許容する、VRs。 マルチキャストアドレスが構成される必要はないことに注意するのは重要です。
12. Data forwarding may be done in one of several ways:
12. データ推進はいくつかの方法の1つで完了しているかもしれません:
1. An LSP with best-effort characteristics that all VPNS can use.
1. すべてのVPNSが使用できるベストエフォート型特性がある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 Virtual Circuitに基礎づけました。
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顧客に対するサービスのグレードを提供できます。
Muthukrishnan & Malis Informational [Page 6] RFC 2917 Core VPNs September 2000
[6ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
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に合わせるかもしれません。 別々のルーティングデータベースを維持して、テーブルを進める1VRあたり1つは与えられたSPEDに、最も高い性能を得ることにおいて一方通行です。
7. Scalable Configuration
7. スケーラブルな構成
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のセットに加わるとき、具体的に言うと、管理者は2、3のコンフィギュレーション品目を加えなければならないはずです。 より悪いものは何でも、サービスプロバイダーのために威圧しながら、このタスクも作るでしょう。 このアーキテクチャでは、サービスプロバイダーが割り当てて、構成する必要があるすべてが、イングレス/出口の物理的なリンク(例えば、Frame Relay DLCIかATM VPI/VCI)とVRと見習われたLANとの仮想接続です。
8. Dynamic Neighbor Discovery
8. ダイナミックな隣人発見
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はネットワークにおける多くのSPEDsに住んでいます。 これらのVRsは互いに関して学んで、接続される必要があります。
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に加えられるとき、例として、これは隣人として他のすべてのVRsの構成を必要とするでしょう。 これは構成とネットワーク資源見地から明らかにスケーラブルではありません。
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:
そして、必要性は、これらのVRsがダイナミックに互いを発見するのを許容するために起こります。 隣人発見は、限られた見習われたLANを各VPNに提供することによって、容易にされます。 この見習われたLANはいくつかの方法で使用されます:
1. Address resolution uses this LAN to resolve next-hop (private) IP
addresses associated with the other VRs.
1. 解決用途にこのLANを扱って、他のVRsに関連している次のホップ(個人的)の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,
VPN LANは、IPマルチキャストアドレスを使用することで見習われます。 公衆を保存することのために、スペースを扱ってください、そして、このマルチキャストアドレスが、SPだけで目に見える必要があるので、スペースをネットワークでつないでください。
Muthukrishnan & Malis Informational [Page 7] RFC 2917 Core VPNs September 2000
[7ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
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.
私たちは(239.192/14) [マイヤー]で説明されるように見られたマルチキャストが扱うOrganizationallyからのアドレスを使用するでしょう。 アドレスをこの範囲から各VPNに割り当てます。 この点で構成を完全に排除するために、このアドレスはVPNIDから計算されます。
9. VPN IP Domain Configuration
9. VPN IPドメイン構成
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のネットワークで唯一それぞれのルータを特定します。
Muthukrishnan & Malis Informational [Page 8] RFC 2917 Core VPNs September 2000
[8ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
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
172.150.0/18 172.150.128/18 ----------------------- ---------------------------| | | | | | 172.150.128.1 | ルータ'A'、(151.0、.0、.1)| |---------| | ############# | |パートDB| | ---#-----------# | /---------/ | OSPF| # # イシス| /----------/ ------------|# VR--#|-------------- #-------|---#-| #############10.0.1/24 |----|------------#-#---------------|-----| |10.0.0.2/24# # |10.0.0.3/24 |------|-------| # # ---------|-------| | ############### # |############### | | # VR--B|# # # VR--C#| |#-------------# ルータ'B'##|------------#---- (152.0.0.2)############### ############### (153.0.0.3) ------------------------- ルータ'C'| エクストラネット172.150.64/18のVベンダー
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.
それぞれのVirtual RouterはPNAがまるでそれが個人的な物理的なルータであるかのように構成可能です。 もちろん、SPはこのVirtual Routerが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で例証するために、VRsはVPN1の3SPEDsに住んでいます。 ルータ'B'が収容する'家のVR-A、ルータ'VR-Bとルータ'C'はVR-Cを収容します。 CPE設備にはVR-CとVR-Bが物理接続がいますが、VR-Aでは、2人の物理接続がいます。 見習われたLANにはそれぞれのVRsがIP完全に有能な論理的な接続がいます。 VR-Aは会社の本部には(物理的)の接続があって、それらの接続の上にOSPFを実行します。 したがって、それは172.150 18と.0/172.150.128/18にパケットを発送できます。 VR-Bは支店(物理接続の上の)でRIPを実行して、RIP(論理的な接続の上の)をVR-Aに輸出172.150.64/18まで使用します。 VR-Aは論理的な接続の上にデフォルトルートのVR-Bに広告を出します。 ベンダーは.1に172.150で部品データベースに接続するエクストラネット接続としてのVR-C.128を使用します。 したがって、VR-Cは論理的な接続の上にデフォルトルートのVR-Aに広告を出します。 VR-Aは175.150だけをエクスポートします。.128 .1 VR-Cに。 これは警備上の問題から企業ネットワークの残りを妨げます。
Muthukrishnan & Malis Informational [Page 9] RFC 2917 Core VPNs September 2000
[9ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
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. 18と.0/172.150.128/18がVR-Aでネットワークでつなぐ172.150とのOSPF接続。
2. RIP connections to VR-B and VR-C on VR-A.
2. VR-BとのRIP接続とVR-Aの上のVR-C。
3. Route policies on VR-A to advertise only the default route to
VR-B.
3. VR-Aに関する方針を発送して、デフォルトルートだけのVR-Bに広告を出してください。
4. Route policies on VR-A to advertise only 172.159.128.1 to VR-C.
4. 172.159だけに広告を出すためにVR-Aに関する方針を発送してください。.128 .1 VR-Cに。
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-Aに広告を出すVR-CのRIP。
10. Neighbor Discovery Example
10. 隣人発見の例
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、(SPED-a)が使用する、.0は公衆が.3/24に.0のSPED-B用途150.0.0.1/24、.2/24、およびSPED-Cが150.0に使用する150.0を扱います。 注意されるように、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-Bに送りながら、VR-Aに関するケースを取りましょう。 VR-ビーズアドレス(SPED-ビーズアドレス)を得るために、VR-AがVR-BのアドレスがあるARPリクエスト・パケットを送る、(10.0 .0 .2) 論理アドレスとして。 ソース論理アドレスによる10.0に、.1とハードウェアが扱う.0があるということです。151.0 .0 .1。 このARP要求をこのVPNのマルチキャストアドレスでカプセル化して、出します。 SPED BとSPED-Cはパケットのコピーを受けます。 そして、SPED-Bが10.0に.0を認識する、VPN1の文脈の.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がVR-ビーズ論理アドレスのための静的なARPエントリーによって構成されるだろう、(10.0に、「ハードウェア」がある.1が)扱う.0は.2に152.0に.0を設定します。
11. Forwarding
11. 推進
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
建築アウトラインで言及されるように、いくつかの方法の1つでデータ推進をするかもしれません。 推進ルーティング/コントロールパケットのためのホップHopのテクニック、実際のメソッド以外のすべてのテクニックで
Muthukrishnan & Malis Informational [Page 10] RFC 2917 Core VPNs September 2000
[10ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
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. ベストエフォート型公共のLSP。
11.1 Private LSP
11.1 個人的な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は1VPNあたり1個のベースで任意に構成されます。 通常、このLSPは非ゼロ帯域幅の予約、そして/または、特定の差別化されたサービスかQOSのクラスに関連しています。 このLSPが利用可能であるなら、それは利用者データとVPNの個人的な制御データ推進に使用されます。
11.2 Best Effort Public LSP
11.2 ベストエフォート型公共のLSP
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.
指定された帯域幅、そして/または、QOSの特性がある個人的なLSPが構成されていないか、または現在利用可能でないならこのLSPを使用することでVPNデータ・パケットを進めます。 使用されるLSPはVPN0の出口ルータのために運命づけられたものです。 詰め物のヘッダーのVPNIDは、反-様々なVPNsから出口ルータでデータ・パケットを多重送信するのに使用されます。
12. Differentiated Services
12. 差別化されたサービス
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.
VPNsのための個人的なLSPsがSPを許容するのを構成するのが提供する有料入場者に対するサービスを差別化しました。 どんな利用可能なL2 QOSのクラスやDiff-Serv codepointsにもこれらの個人的なLSPsを関連づけることができました。 VPNでは、LSPsの中でパケットを分類するための流れプロフィールは異なったサービスのクラスがある複数の個人的なLSPsを構成できました。 この特徴(能力に伴うサイズへの仮想のルータ)で、SPはVPN顧客に対する本当に、差別化されたサービスを提供できます。
13. Security Considerations
13. セキュリティ問題
13.1 Routing Security
13.1 ルート設定セキュリティ
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で完全に利用可能であることを意味します。 ルートが1VPNから別のVPNまで偶然漏らされないのを確実にするのは、導入問題です。 これを達成する1つの方法は別々のルーティングと推進データベースを維持することです。
Muthukrishnan & Malis Informational [Page 11] RFC 2917 Core VPNs September 2000
[11ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
13.2 Data Security
13.2データ機密保護
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は、1VPNのデータ・パケットには別のものまでさまよう機会が決してないことをVPN顧客に知らせることができます。 ルーティング見地から、それぞれの仮想のルータのための別々のルーティングデータベースを維持することによって、これを達成できるでしょう。 データ推進見地から、共有されたLSPs[Rosen2][Callon]の場合におけるラベルスタックの使用か個人的なLSPsの使用がデータプライバシーを保証します。 また、パケットフィルタは、問題を緩和するのを助けるために構成されるかもしれません。
13.3 Configuration Security
13.3 構成セキュリティ
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に近づく手段を持っている唯一の人であることを保証しなければなりません。 仮想のルータコンソールが物理的なルータに機能上同等であるので、パスワードなどの物理的なコンソール、RADIUSなどで利用可能な認証方法のすべてがPNAに利用可能です。
13.4 Physical Network Security
13.4 物理ネットワークセキュリティ
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への保証を提供します。
14. Virtual Router Monitoring
14. 仮想のルータモニター
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.
物理的なルータで利用可能なルータモニターの特性のすべてが仮想のルータで利用可能です。 これは「ピング」や「トレースルート」などのユーティリティを含んでいます。 さらに、個人的な経路指定テーブルを表示する能力、リンク州のデータベースなどは利用可能です。
15. Performance Considerations
15. パフォーマンス問題
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
ルーティング飛行機を見る際に、ほとんどの現代のルーティング・プロトコルが、ステーションを終わらせるために最短パスについて計算するのに何らかのフォームの最適化計算方法論を使用します。 例えば、BGPが「決定プロセス」を使用している間、OSPFとイシスはDjikstraアルゴリズムを使用します。 これら
Muthukrishnan & Malis Informational [Page 12] RFC 2917 Core VPNs September 2000
[12ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
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)か目的地への経路のASsの数(BGP)のどちらかに基づいています。 しかし、設定におけるオーバーヘッドが上昇することに注意するのが重要であり、これらの計算を始めて、大部分のためのわずか、が現代のルータですか?どんな これは私たちが「データベース」として入力されたルーティング計算について言及しますが、これらがメモリ常駐のデータ構造であるからです。
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 VPNsを収容すると言おう、何らかのルーティング・プロトコルをすべて実行すると、RPは言われます。 また、RPのルーティング計算アルゴリズムの平均した性能がxとyがそのルーティング・プロトコルのためにアルゴリズムの性能を決定するパラメタであるところのf(X、Y)であると思いましょう。 例として、OSPFなどのDjikstraアルゴリズムユーザにとって、Yはリンクの数であるかもしれませんが、Xはその領域のノードの数であるかもしれません。 任意のVPN nの性能はf(Xn、Yn)です。 (物理的)のルータの性能はN.This i0<=<=結論における、iのすべての値のためのf(ξ、イー)の合計が選ばれた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つの入力を持っています: 推進テーブルとパケットのヘッダー。 主な性能パラメタはルックアップアルゴリズムです。 最も良い性能1は、索表があるルーティングにIPのために何らかの樹形としてテーブルを組織化させて、実際のルックアップをする二分探索メソッドを使用できます。 このアルゴリズムの性能はO(ログn)です。
Muthukrishnan & Malis Informational [Page 13] RFC 2917 Core VPNs September 2000
[13ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
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に提供するためにテクニックをかぶせました。 'しかしながら、オーバレイルータが複数のVPNsの経路指定テーブルの統合を利用するとき、性能がO(ログm*n)である、どこ、'経路指定テーブルがルートを支えるVPNsの数はそうであるか。
16. Acknowledgements
16. 承認
The authors wish to thank Dave Ryan, Lucent Technologies for his invaluable in-depth review of this version of this memo.
作者は彼のこのメモのこのバージョンの非常に貴重な徹底的なレビューについてデーヴ・ライアン、ルーセントテクノロジーズに感謝したがっています。
17. References
17. 参照
[Callon] Callon R., et al., "A Framework for Multiprotocol Label
Switching", Work in Progress.
[Callon] Callon R.、他、「Multiprotocolラベルの切り換えのためのフレームワーク」、ProgressのWork。
[Fox] Fox, B. and B. Gleeson,"Virtual Private Networks
Identifier", RFC 2685, September 1999.
[フォックス] フォックスとB.とB.グリーソン、「仮想私設網識別子」、RFC2685、1999年9月。
[Meyer] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
July 1998.
[マイヤー]マイヤー、D.、「行政上見られたIPマルチキャスト」、RFC2365、1998年7月。
[Rosen1] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
1999.
1999年の[Rosen1]ローゼンとE.とY.Rekhter、「BGP/MPLS VPNs」、RFC2547行進。
[Rosen2] Rosen E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", Work in Progress.
[Rosen2] 「Multiprotocolラベル切り換えアーキテクチャ」というローゼンE.、Viswanathan、A.、およびR.Callonは進行中で働いています。
Muthukrishnan & Malis Informational [Page 14] RFC 2917 Core VPNs September 2000
[14ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
18. Authors' Addresses
18. 作者のアドレス
Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford, MA 01886
Karthik Muthukrishnanルーセントテクノロジーズ1ロビンス・Roadウェストフォード、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
アンドリューMalisの活発なネットワークInc.2730果樹園Parkwayサンノゼ(カリフォルニア)95134
Phone: (408) 383-7223 EMail: Andy.Malis@vivacenetworks.com
以下に電話をしてください。 (408) 383-7223 メールしてください: Andy.Malis@vivacenetworks.com
Muthukrishnan & Malis Informational [Page 15] RFC 2917 Core VPNs September 2000
[15ページ]RFC2917コアVPNs2000年9月の情報のMuthukrishnan&Malis
19. Full Copyright Statement
19. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Muthukrishnan & Malis Informational [Page 16]
Muthukrishnan&Malis情報です。[16ページ]
一覧
スポンサーリンク
