Network Working Group H. Ould-Brahim
Request for Comments: 5195 D. Fedyk
Category: Standards Track Nortel
Y. Rekhter
Juniper Networks
June 2008
BGP-Based Auto-Discovery for Layer-1 VPNs
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached to Customer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port.
このドキュメントの目的は、レイヤ1のVPN（L1VPNs）のためのBGPベースの自動検出メカニズムを定義することです。 L1VPNsの自動検出メカニズムは、プロバイダネットワークデバイスは、動的に顧客エッジ（CE）は、同じVPNのメンバーに取り付けられたポートを有するプロバイダエッジの集合（PES）を発見することを可能にします。この情報は、L1VPN接続のシグナリング・フェーズを完了するために必要です。 L1VPN自動検出メカニズムの一つの主な目的は、与えられたL1VPNに新しいポートを追加するだけで、このポートを持っているPEにしているCE上で設定変更を伴うだろう「シングルエンド・プロビジョニング」モデルを、サポートすることですこのポートを介してPEに接続されています。
The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs) [L1VPN-FRMK]. The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of PEs having ports attached to CE members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port.
この文書の目的は、レイヤ1のVPN（L1VPNs）L1VPN-FRMK]のためのBGPベースの自動検出機構を定義することです。 L1VPNsの自動検出メカニズムは、プロバイダネットワークデバイスが動的に同じVPNのCE部材に取り付けられたポートを有するPEのセットを発見することを可能にします。この情報は、L1VPN接続のシグナリング・フェーズを完了するために必要です。 L1VPN自動検出メカニズムの一つの主な目的は、与えられたL1VPNに新しいポートを追加するだけで、このポートを持っているPEにしているCE上で設定変更を伴うだろう「シングルエンド・プロビジョニング」モデルを、サポートすることですこのポートを介してPEに接続されています。
The auto-discovery mechanism proceeds by having a PE advertise to other PEs the following information, at a minimum: its own IP address and the list of <private address, provider address> tuples local to that PE. Once that information is received, the remote PEs will identify the list of VPN members they have in common with the advertising PE, and use the information carried within the discovery mechanism to perform address resolution during the signaling phase of Layer-1 VPN connections.
独自のIPアドレス、<プライベートアドレスは、プロバイダーのアドレス>はそのPEへのローカルタプルのリスト：PEを有することにより、自動検出メカニズム進み、他のPEに最低でも次の情報を、宣伝します。その情報が受信されると、リモートPEは、彼らが広告PEと共通しているVPNメンバーのリストを識別し、レイヤ1 VPN接続のシグナリング・フェーズの間にアドレス解決を実行するために発見機構内に搬送される情報を使用します。
Figure 1 highlights the network reference for using a BGP-based auto-discovery mechanism for Layer-1 VPNs. For the purpose of the auto-discovery mechanism, BGP is running only on the provider network. The PEs maintain per-VPN information tables called Port Information Tables (PITs) related to <private address, provider address> information. More information on the PITs is in Section 2.
図1強調レイヤ1 VPNのBGPベースの自動検出機構を使用するためのネットワーク参照。自動検出メカニズムの目的のために、BGPは、プロバイダのネットワーク上で実行されています。 PEは<プライベートアドレス、プロバイダアドレス>情報に関連するポート情報テーブル（ピット）と呼ばれるあたり-VPN情報テーブルを維持します。ピットの詳細については、第2節です。
PE1 PE2
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || BGP route | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+| Distribution| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B |
| CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 |
+--------+ | | || (Backbone ) | | | | +--------+
| +------+| --------- | +----------+ |
| | | |
+--------+ | +-----+ | | +----------+ | +--------+
| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
| CE1 |--| |PIT | | | | PIT | |-| CE2 |
+--------+ | | | | | | | | +--------+
| +-----+ | | +----------+ |
+---------+ +--------------+
Figure 1: BGP Auto-Discovery for L1VPN
図1：L1VPNのためのBGP自動検出
[L1VPN-FRMK] describes two modes of operation for a L1VPN: the basic mode and the enhanced mode. This document describes an auto-discovery mechanism for the basic mode only.
基本モードと拡張モード：[L1VPN-FRMK]はL1VPNのための2つの動作モードを記述する。この文書では、唯一の基本モードの自動検出メカニズムを説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
In the context of L1VPNs, a CE is connected to a PE via one or more ports, where each port may consist of one or more channels or sub-channels. Each port on a CE that connects the CE to a PE has an identifier that is unique within that L1VPN (but need not be unique across several L1VPNs). We refer to this identifier as the customer port identifier (CPI). Each port on a PE also has an identifier that is unique within the provider network. We refer to this identifier as the provider port identifier (PPI). Note that IP addresses used for CPIs or PPIs could be either IPv4 or IPv6 addresses.
L1VPNsの文脈では、CEは、各ポートは1つまたは複数のチャネルまたはサブチャネルで構成され得る1つの以上のポートを介してPEに接続されています。 PEとCEを接続CE上の各ポートは、そのL1VPN内で一意である識別子を有している（ただし、いくつかのL1VPNs全体で一意である必要はありません）。我々は、顧客のポート識別子（CPI）などの識別子を参照してください。 PE上の各ポートはまた、プロバイダネットワーク内で一意の識別子を有します。我々は、プロバイダのポート識別子（PPI）として、この識別子を参照してください。 IPv4またはIPv6アドレスのいずれかであるのCPIやPPIのために使用されるIPアドレスに注意してください。
For each L1VPN that has at least one port configured on a PE, the PE maintains a Port Information Table (PIT). A PIT contains a list of <CPI, PPI> tuples for all the ports within its L1VPN. Note that a PIT may also hold routing information (for example, when CPIs are learnt using a routing protocol).
PEで構成された少なくとも1つのポートを有し、各L1VPNのために、PEは、ポート情報テーブル（PIT）を維持します。 PITは、そのL1VPN内のすべてのポートの<CPI、PPI>タプルのリストが含まれています。 PITはまた、ルーティング情報を保持してもよいことに留意されたい（例えば、のCPIは、ルーティングプロトコルを使用して学習している場合）。
A PIT on a given PE is populated with two types of information.
所与のPE上のピットは、情報の二種類が移入されています。
- Information related to the CEs' ports attached to the ports on the PE. This information could be locally configured at the PE or could be received from the CEs.
- PE上のポートに接続されたCEのポートに関連する情報。この情報は、ローカルPEで構成され得るか、のCEから受信することができます。
- Information received from other PEs through the auto-discovery mechanism.
- 自動検出機構を介して他のPEから受信した情報。
We refer to the former as local information, and to the latter as remote information. Propagation of local information to other PEs is accomplished by using BGP multiprotocol extensions [RFC4760]. To restrict the flow of this information to only the PITs within a given L1VPN, we use BGP route filtering based on the Route Target Extended Community [BGP-COMM], as follows.
我々は、リモート情報としてローカル情報として、後者に前者を指します。他のPEにローカルな情報の伝播は、BGPマルチプロトコル拡張[RFC4760]を使用することによって達成されます。次のように与えられたL1VPN内のみピットに、この情報の流れを制限するために、我々は、ルートターゲット拡張コミュニティ[BGP-COMM]に基づいて、BGPルートフィルタリングを使用します。
Each PIT on a PE is configured with one or more Route Target Communities, called "export Route Targets", that are used for tagging the local information when it is exported into the provider's BGP. The granularity of such tagging could be as fine as a single <CPI, PPI> pair. In addition, each PIT on a PE is configured (at provisioning time) with one or more Route Target Communities, called "import Route Targets", that restrict the set of routes that could be imported from provider's BGP into the PIT to only the routes that have at least one of these Communities.
PE上の各PITは、それがプロバイダーのBGPにエクスポートされたときにローカルな情報をタグ付けするために使用されている「輸出ルートターゲット」と呼ばれる1つ以上のルートターゲットコミュニティ、で構成されています。そのようなタグの粒度は、単一の<CPI、PPI>対ほど微細であってもよいです。また、PEの各PITは、一つ以上のルートターゲットコミュニティと（時刻プロビジョニングに）設定され、「インポートルートターゲット」と呼ばれ、ルートだけにPITにプロバイダのBGPからインポートすることができたルートのセットを制限することこれらのコミュニティの少なくとも一つを持っています。
Each of the following occurs at provisioning time: if a service provider adds a new L1VPN port to a particular PE, this port is associated with a PIT on that PE, and this PIT is associated with that L1VPN.
以下の各時間をプロビジョニングで発生：サービスプロバイダは、特定のPEに新しいL1VPNポートを追加した場合、このポートは、そのPE上のピットに関連付けられ、このピットがそのL1VPNと関連しています。
Note that since the protocol used to populate a PIT with remote information is BGP, and since BGP works across multiple autonomous systems (ASs), it follows that the mechanism described in this document could support L1VPNs that span multiple autonomous systems.
以降は、リモート情報でPITを移入するために使用されるプロトコルは、BGPであり、BGPは、複数の自律システム（ASの）を横切って動作するので、本書で説明されたメカニズムは、複数の自律システムにまたがるL1VPNsをサポートできることになることに留意されたいです。
Although multi-AS L1VPNs are currently out of scope for the Basic Mode, the mechanisms defined in this document appear to be easily applicable to a multi-AS scenario, should such a need arise in the future. At that time, additional work may be required to examine various aspects including security.
マルチAS L1VPNsは、基本モードの範囲外現在ですが、この文書で定義されたメカニズムは、マルチASシナリオにも容易に適用可能であると思われる、そのような必要は将来発生すべきです。その時、追加の作業は、セキュリティを含むさまざまな側面を検討する必要があります。
The <CPI, PPI> mapping is carried using the Multiprotocol Extensions to BGP [RFC4760]. [RFC4760] defines the format of two BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI, that can be used to announce and withdraw the announcement of reachability information. We introduce a new subsequent address family identifier, called Layer-1 VPN auto-discovery information (value 69), and also a new Network Layer Reachability Information (NLRI) format for carrying the CPI and PPI information.
<CPI、PPI>マッピングはBGP [RFC4760]にマルチプロトコル拡張を使用して実施されます。 [RFC4760]は2つのBGP、到達可能性情報のアナウンスを発表し、引き出すために使用することができるMP_REACH_NLRIとMP_UNREACH_NLRIを、属性のフォーマットを定義します。私たちは、レイヤ1 VPN自動検出情報（値69）と呼ばれる新しい次のアドレスファミリ識別子を、紹介し、また、CPIとPPIの情報を運ぶための新しいネットワーク層到達可能性情報（NLRI）形式。
One or more <PPI, CPI> tuples could be carried in the above mentioned BGP attributes.
1つ以上の<PPI、CPI>タプルは、上記のBGP属性言及して実行することができました。
The format of the NLRI is described in Figure 2.
NLRIのフォーマットは、図2に記載されています。
+---------------------------------------+
| Length (1 octet) |
|長さ（1つのオクテット）|
+---------------------------------------+
| Auto-discovery info (variable) |
|自動検出情報（変数）|
+---------------------------------------+
Figure 2: Encoding of the NLRI
図2：NLRIのエンコーディング
Note that the encoding of the auto-discovery information is described in [L1VPN-BM], and note also that if the value of the Length of the Next Hop field (of the MP_REACH_NLRI attribute) is 4, then the Next Hop contains an IPv4 address. If this value is 16, then the Next Hop contains an IPv6 address.
自動発見情報の符号化は[L1VPN-BM]に記載されていることに注意してください、そして（MP_REACH_NLRI属性の）次ホップフィールドの長さの値が4である場合、ネクストホップは、IPv4が含まれていることにも注意してください住所。この値が16の場合、次ホップIPv6アドレスが含まれています。
In addition to reachability information, the auto-discovery mechanism MAY carry Traffic Engineering information used for the purpose of egress path selection. For example, a PE may learn the switching capability and the maximum LSP bandwidth of remote L1VPN interfaces from the remote PEs. This document uses the BGP Traffic Engineering Attribute [BGP-TE-ATTRIBUTE] to carry such information.
到達可能性情報に加えて、自動検出メカニズムは、出力パス選択の目的のために使用されるトラフィックエンジニアリング情報を運ぶことができます。例えば、PEは、スイッチング機能およびリモートのPEから遠隔L1VPNインターフェースの最大LSP帯域幅を学習することができます。この文書では、そのような情報を運ぶためにBGPトラフィックエンジニアリング属性[BGP-TE-ATTRIBUTE]を使用しています。
Recall that the Service Provider network consists of (a) PEs, (b) BGP Route Reflectors, (c) P nodes (which are neither PEs nor Route Reflectors), and, in the case of multi-provider VPNs, (d) Autonomous System Border Routers (ASBRs).
サービスプロバイダネットワークは（A）のPEから構成されていることを思い出して、（b）は、BGPルートリフレクタ、（C）のP（いずれのPEもルートリフレクタである）ノード、及び、マルチプロバイダVPNの場合には、（D）自律システム境界ルータ（ASBRは）。
A PE router, unless it is a Route Reflector, does not retain L1VPN-related information unless it has at least one VPN with an import Route Target identical to one of the VPN-related information Route Target attributes. If a PE does not have a VPN with a matching import Route Target, it MUST then discard received l1VPN information. Inbound filtering MUST be used to cause such information to be discarded. If a new import Route Target is later added to one of the PE's VPNs (a "VPN Join" operation), it MUST then acquire the VPN-related information it previously has discarded.
PEルータ、それがルートリフレクタでない限り、それがルートターゲット属性VPN関連情報のものと同一のインポートルートターゲットと少なくとも一つのVPNを持っていない限り、L1VPN関連情報を保持していません。 PEが一致するインポートルートターゲットとのVPNを持っていない場合、それは、受信したL1VPN情報を破棄しなければなりません。インバウンドフィルタリングは、このような情報は破棄させるために使用されなければなりません。新しいインポートルートターゲットが後PEのVPNの一方（「VPN参加」操作）に追加された場合、それはそれが以前に捨てたVPN関連情報を取得しなければなりません。
In this case, the refresh mechanism described in [BGP-RFSH] MUST be used. The outbound route filtering mechanisms of [BGP-ORF] and [BGP-CONS] can also be used to advantage to make the filtering more dynamic.
この場合には、[BGP-RFSH]に記載のリフレッシュ・メカニズムを使用しなければなりません。 [BGP-ORF]および[BGP-CONS]のアウトバウンドルートフィルタリングメカニズムはまた、フィルタリングをより動的にするために有利に使用することができます。
Similarly, if a particular import Route Target is no longer present in any of a PE's VPN (as a result of one or more "VPN Prune" operations), the PE MAY discard all the L1VPN BGP routes that, as a result, no longer have any of the PE's PIT's import Route Targets as one of their Route Target attributes.
特定のインポートルートターゲットは、もはやPEのVPN（1つまたは複数の「VPNプルーン」オペレーションの結果として）のいずれかに存在する場合に同様に、PEは、結果として、もはや全てL1VPN BGPルートを捨てなくてもよいですそのルートターゲット属性の一つとして、PEのPITのインポートルートターゲットのいずれかを持っています。
Note that "VPN Join" and "VPN Prune" operations are non-disruptive, and do not require any BGP connections to be brought down, as long as the refresh mechanism of [BGP-RFSH] is used.
「VPN参加」と「VPNプルーン」の操作は、無停止であり、任意のBGP接続がダウンするために必要としない限り、[BGP-RFSH]のリフレッシュメカニズムとして使用されることに注意してください。
As a result of these distribution rules, no one PE ever needs to maintain all routes for all L1VPNs; this is an important scalability consideration.
これらの分布規則の結果として、1つのPEは、これまでのすべてのL1VPNsためのすべてのルートを維持する必要がありません。これは重要なスケーラビリティの考慮事項です。
Route reflectors can be partitioned among VPNs so that each partition carries routes for only a subset of the L1VPNs supported by the Service Provider. Thus, no single route reflector is required to maintain VPN-related information for all VPNs.
各パーティションは、サービスプロバイダによってサポートL1VPNsのサブセットのみのルートを運ぶようにルートリフレクタは、VPN間で分割することができます。したがって、単一のルートリフレクタは、すべてのVPN用のVPN関連情報を維持するために必要とされません。
For inter-provider VPNs, if multi-hop External BGP (EBGP) is used, then the ASBRs need not maintain and distribute VPN-related information at all. P routers do not maintain any VPN-related information.
マルチホップ外部BGP（EBGP）が使用される場合、インタープロバイダのVPNについては、その後のASBRは、すべてのVPNに関連する情報を維持し、配布する必要はありません。 Pルータは、任意のVPN関連の情報を維持しません。
As a result, no single component within the Service Provider network has to maintain all the VPN-related information for all the VPNs. So the total capacity of the network to support increasing numbers of VPNs is not limited by the capacity of any individual component.
結果として、サービスプロバイダネットワーク内の単一コンポーネントがすべてのVPNのすべてのVPNに関連する情報を維持しなければなりません。だから、VPNの数の増加をサポートするためのネットワークの総容量は、任意の個々のコンポーネントの容量によって限定されるものではありません。
An important consideration to remember is that one may have any number of INDEPENDENT BGP systems carrying VPN-related information. This is unlike the case of the Internet, where the Internet BGP system MUST carry all the Internet routes. Thus, one significant (but perhaps subtle) distinction between the use of BGP for the Internet routing and the use of BGP for distributing VPN-related information, as described in this document, is that the former is not amenable to partition, while the latter is.
覚えておくべき重要な考慮事項は、1つのVPN関連情報を運ぶ独立BGPシステムの任意の番号を持つことです。これはインターネットのBGPシステムは、すべてのインターネットルートを運ばなければなりません、インターネットの場合とは異なります。後者つつ、インターネットのルーティングのためのBGPの使用とVPN関連情報を配信するためのBGPの使用の間に1つの有意な（おそらく微妙な）区別は、この文書に記載されているように、前者のパーティションに適していないということですです。
This document describes a BGP-based auto-discovery mechanism that enables a PE that attaches to a particular L1VPN to discover the set of other PE routers that attach to the same VPN. Each PE router that is attached to a given VPN uses BGP to advertise that fact. Other PE routers that attach to the same VPN receive these BGP advertisements. This allows that set of PEs to discover each other. Note that a PE will not always receive these advertisements directly from the remote PEs; the advertisements can be received from "intermediate" BGP speakers.
この文書は、同じVPNに接続他のPEルータのセットを発見するために特定のL1VPNに付着PEを可能BGPベースの自動検出メカニズムを説明しています。指定したVPNに接続されている各PEルータは、その事実を宣伝するためにBGPを使用しています。同じVPNに接続し、他のPEルータは、これらのBGPアドバタイズメントを受信します。これはPEのセットが互いを発見することができます。 PEは常にリモートのPEから直接これらの広告を受信しないことに注意してください。広告は「中間」のBGPスピーカから受信することができます。
It is of critical importance that a particular PE MUST NOT be "discovered" to be attached to a particular VPN unless that PE really is attached to that VPN, and indeed is properly authorized to be attached to that VPN. If any arbitrary node on the Internet could start sending these BGP advertisements, and if those advertisements were able to reach the PE nodes, and if the PE nodes accepted those advertisements, then anyone could add any site to any L1VPN. Thus, the auto-discovery procedures described here presuppose that a particular PE trusts its BGP peers to be who they appear to be, and further, that it can trust those peers to be properly securing their local attachments. (That is, a PE MUST trust that its peers are attached to, and are authorized to be attached to, the L1VPNs to which they claim to be attached.)
これは、特定のPEがそのPEは本当にそのVPNに接続され、かつ実際に適切にそのVPNに接続することを許可されていない限り、特定のVPNに接続されるように「発見」されてはならないことを非常に重要です。インターネット上の任意のノードは、これらのBGPアドバタイズメントの送信を開始することができ、それらの広告はPEノードに到達することができました場合、およびPEノードは、それらの広告を受け入れた場合、誰がどのL1VPNに任意のサイトを追加することができます。したがって、ここで説明する自動検出手順は、特定のPEが、彼らはそれが適切に彼らの地元の添付ファイルを確保するためにこれらのピアを信頼できること、さらにように見える、と誰であることをそのBGPピアを信頼していることを前提とします。 （すなわち、PEは、そのピアが接続され、それらが取り付けられる請求するL1VPNs、に取り付けられるように許可されていることを信頼しなければなりません。）
If a particular remote PE is a BGP peer of the local PE, then the BGP authentication procedures of [RFC2385] SHOULD be used to ensure that the remote PE is who it claims to be, i.e., that it is a PE that is trusted.
特定のリモートPEがローカルPEのBGPピアである場合は、[RFC2385]のBGP認証手順は、リモートPEは、それが信頼されているPEであること、すなわち、であることを主張する人であることを保証するために使用されるべきです。
If a particular remote PE is not a BGP peer of the local PE, then the information it is advertising is being distributed to the local PE through a chain of BGP speakers. The local PE MUST trust that its peers only accept information from peers that they trust in turn, and this trust relation MUST be transitive. BGP does not provide a way to determine that any particular piece of received information originated from a BGP speaker that was authorized to advertise that particular piece of information. Hence, the procedures of this document MUST be used only in environments where adequate trust relationships exist among the BGP speakers (such as the case of using the auto-discovery mechanism within a single provider network).
特定のリモートPEがローカルPEのBGPピアでない場合、それは広告される情報は、BGPスピーカのチェーンを介してローカルPEに分配されています。ローカルPEは、そのピアが唯一の彼らは順番に信頼する仲間からの情報を受け入れることを信頼する必要があり、この信頼関係は推移でなければなりません。 BGPは、受信した情報のいずれかの特定の部分は、情報の特定の部分を広告することを許可されたBGPスピーカから発生していることを決定する方法を提供していません。従って、この文書の手順は、十分な信頼関係は、（例えば、単一のプロバイダ・ネットワーク内で自動検出機構を用いた場合のような）BGPスピーカ間に存在する環境で使用されなければなりません。
This document assigns a new SAFI, called Layer-1 VPN auto-discovery information (see Section 3). This assignment has been made in the Subsequent Address Family Identifier (SAFI) registry using the Standards Action allocation procedures. The value is 69.
この文書では、レイヤ1 VPN自動検出情報（セクション3を参照）と呼ばれる新しいSAFIを、割り当てられます。この割り当ては、標準アクションの割り当て手順を使用して次のアドレスファミリ識別子（SAFI）レジストリに行われています。値は69です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T.、チャンドラ、R.、カッツ、D.、およびY. Rekhter、 "BGP-4のためのマルチプロトコル拡張機能"、RFC 4760、2007年1月。
[BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[BGP-RFSH]チェン、E.、 "BGP-4のためのルートリフレッシュ機能"、RFC 2918、2000年9月。
[BGP-TE-ATTRIBUTE] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., "Traffic Engineering Attribute", Work in Progress, January 2008.
[BGP-TE-ATTRIBUTE]ウルド - Brahimの、H.、ルブラン、D.、およびRekhter、Y.、 "トラフィックエンジニアリング属性"、進歩、2008年3月での作業。
[BGP-ORF] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", Work in Progress, September 2006.
[BGP-ORF]チェン、E.およびY. Rekhter、 "BGP-4のためのアウトバウンドルートフィルタリング機能"、進歩、2006年9月での作業。
[BGP-CONS] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
[BGP-CONS]マルケス、P.、Bonica、R.、牙、L.、マティーニ、L.、Raszuk、R.、パテル、K.、およびJ.ギシャール、ボーダーゲートウェイプロトコル/マルチプロトコルは、「制約ルート配布ラベル・スイッチング（BGP / MPLS）インターネット・プロトコル（IP）、仮想プライベートネットワーク（VPN）」、RFC 4684、2006年11月。
[BGP-COMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
サングリ、S.、タッパン、D.、およびY. Rekhterは、 "BGP拡張コミュニティ属性" [BGP-COMM]、RFC 4360、2006年2月。
[L1VPN-FRMK] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[L1VPN-FRMK]武田、T.、エド。、 "フレームワークおよびレイヤ1つの仮想プライベートネットワークの要件"、RFC 4847、2007年4月。
[L1VPN-BM] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", Work in Progress, February 2008.
[L1VPN-BM] Fedyk、D.、エド。、Rekhter、Y.、エド。、Papadimitriou、D.、Rabbat、R.、およびL.バーガー、 "レイヤ1 VPN基本モード" が進行中で働いて、2008年2月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
We would like to thank Adrian Farrel for the useful comments.
私たちは、有益なコメントのためのエードリアンファレルに感謝したいと思います。
Authors' Addresses
著者のアドレス
Hamid Ould-Brahim Nortel PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada
ハミド・ウルド・Brahimのノーテルの私書箱3511駅のCオタワON K1Y 4H7カナダ
Phone: +1 (613) 763 4730 EMail: hbrahim@nortel.com
電話：+1（613）763 4730 Eメール：hbrahim@nortel.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA
ヤコフ・レックタージュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089 USA
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Don Fedyk Nortel 600 Technology Park Billerica, MA 01821 USA
ドン・ルブランノーテル600テクノロジーパークビレリカ、MA 01821 USA
Phone: +1 (978) 288 3041 Email: dwfedyk@nortel.com
電話：+1（978）288 3041 Eメール：dwfedyk@nortel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。