Network Working Group I. Bryskin
Request for Comments: 5252 ADVA Optical Networking
Category: Standards Track L. Berger
LabN Consulting, LLC
July 2008
OSPF-Based Layer 1 VPN Auto-Discovery
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
抽象
This document defines an Open Shortest Path First (OSPF) based Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This mechanism enables provider edge (PE) devices using OSPF to dynamically learn about the existence of each other, and attributes of configured customer edge (CE) links and their associations with L1VPNs. This document builds on the L1VPN framework and requirements and provides a L1VPN basic mode auto-discovery mechanism.
この文書では、OSPF（Open Shortest Path First）のベースレイヤー1仮想プライベートネットワーク（L1VPN）自動検出メカニズムを定義します。この機構は、プロバイダエッジ（PE）動的にお互いの存在を知るためにOSPFを使用して、デバイス、および設定カスタマエッジ（CE）リンクとL1VPNsとのアソシエーションの属性を可能にします。この文書では、L1VPNフレームワークと要件に基づいて構築されL1VPN基本モード自動検出メカニズムを提供します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Overview ...................................................2
1.2. Terminology ................................................3
1.3. Conventions Used in This Document ..........................4
2. L1VPN LSA and Its TLVs ..........................................4
2.1. L1VPN LSA ..................................................4
2.2. L1VPN INFO TLV .............................................6
3. L1VPN LSA Advertising and Processing ............................7
3.1. Discussion and Example .....................................7
4. Backward Compatibility ..........................................8
5. Security Considerations .........................................9
6. IANA Considerations .............................................9
7. Acknowledgments .................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
The framework for Layer 1 VPNs is described in [RFC4847]. Basic mode operation is further defined in [RFC5251]. The L1VPN Basic Mode (L1VPN-BM) document [RFC5251] identifies the information that is necessary to map customer information (ports identifiers) to provider information (identifiers). It also states that this mapping information may be provided via provisioning or via an auto-discovery mechanism. This document provides such an auto-discovery mechanism using Open Shortest Path First (OSPF) version 2. Use of OSPF version 3 and support for IPv6 are out of scope of this document and will be defined separately.
レイヤ1つのVPNのフレームワークは[RFC4847]に記載されています。基本モード動作は、さらに[RFC5251]で定義されています。 L1VPN基本モード（L1VPN-BM）ドキュメント[RFC5251]は、プロバイダ情報（識別子）の顧客情報（ポート識別子）をマップする必要がある情報を識別する。また、このマッピング情報は、プロビジョニングを介して、または自動検出メカニズムを介して提供することができると述べています。この文書は、IPv6のOSPFバージョン3とサポートのOSPF（Open Shortest Path First）のバージョン2.を使用して、このような自動検出メカニズムを提供し、この文書の範囲外であり、個別に定義されます。
Figure 1 shows the L1VPN basic service being supported using OSPF-based L1VPN auto-discovery. This figure shows two PE routers interconnected over a GMPLS backbone. Each PE is attached to three CE devices belonging to three different L1VPN connections. In this network, OSPF is used to provide the VPN membership, port mapping, and related information required to support basic mode operation.
図1は、OSPFベースL1VPNの自動検出を使用してサポートされるL1VPN基本的なサービスを示します。この図は、GMPLSバックボーンを介して相互接続された2台のPEルータを示しています。各PEは、3つの異なるL1VPN接続に属する3つのCEデバイスに取り付けられています。このネットワークでは、OSPFは、VPNメンバーシップ、ポートマッピング、および基本モード動作をサポートするために必要な関連情報を提供するために使用されます。
PE PE
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || OSPF LSAs | | 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: OSPF Auto-Discovery for L1VPNs
図1：L1VPNsのOSPF自動検出
See [RFC5195] for a parallel L1VPN auto-discovery that uses BGP. The OSPF approach described in this document is particularly useful in networks where BGP is not typically used.
BGPを使用して並列L1VPN自動検出のための[RFC5195]を参照してください。本書では説明OSPFアプローチは、BGPは、典型的には使用されないネットワークにおいて特に有用です。
The approach used in this document to provide OSPF-based L1VPN auto-discovery uses a new type of Opaque Link State Advertisement (LSA) that is referred to as an L1VPN LSA. The L1VPN LSA carries information in TLV (type, length, value) structures. An L1VPN-specific TLV is defined below to propagate VPN membership and port information. This TLV is referred to as the L1VPN Info TLV. The L1VPN LSA may also carry Traffic Engineering (TE) TLVs; see [RFC3630] and [RFC4203].
OSPFベースL1VPNの自動検出を提供するために、このドキュメントで使用されるアプローチは、L1VPN LSAと呼ばれる不透明なリンクステートアドバタイズメント（LSA）の新しいタイプを使用しています。 L1VPN LSAは、TLV（タイプ、長さ、値）構造の情報を運びます。 L1VPN固有のTLVは、VPNメンバーシップおよびポート情報を伝播するために、以下に定義されます。このTLVはL1VPN情報TLVと呼ばれています。 L1VPN LSAはまた、トラフィックエンジニアリング（TE）TLVを運ぶことができます。 [RFC3630]と[RFC4203]を参照してください。
The reader of this document should be familiar with the terms used in [RFC4847] and [RFC5251]. The reader of this document should also be familiar with [RFC2328], [RFC5250], and [RFC3630]. In particular, the following terms:
この文書の読者は、[RFC4847]及び[RFC5251]で使用される用語に精通しなければなりません。この文書の読者はまた、[RFC5250]及び[RFC3630]、[RFC2328]に精通しなければなりません。具体的には、次の用語：
L1VPN - Layer 1 Virtual Private Network
L1VPN - レイヤ1つの仮想プライベートネットワーク
CE - Customer (edge) network element directly connected to the provider network (terminates one or more links to one or more PEs); it is also connected to one or more Cs and/or other CEs
CE - 直接プロバイダーネットワークに接続された顧客（エッジ）ネットワーク要素（一つ又は複数のPEに1つ以上のリンクを終了します）。それはまた、1つ以上のCsおよび/または他のCEに接続されています。
C - Customer network element that is not connected to the provider network but is connected to one or more other Cs and/or CEs
C - プロバイダーネットワークに接続されていないが、1つ以上の他CSおよび/またはCEに接続されている顧客ネットワーク要素
PE - Provider (edge) network element directly connected to one or more customer networks (terminates one or more links to one or more CEs associated with the same or different L1VPNs); it is also connected to one or more Ps and/or other PEs
PE - 直接一つ以上の顧客ネットワークに接続されたプロバイダ（エッジ）のネットワーク要素（同一または異なるL1VPNsに関連する1つまたは複数のCEに1つ以上のリンクを終了します）。それはまた、1つ以上のPsと/または他のPEに接続されています。
P - Provider (core) network element that is not directly connected to any customer networks; P is connected to one or more other Ps and/or PEs
P - 直接任意顧客のネットワークに接続されていないプロバイダ（コア）ネットワーク要素。 Pは、一つ以上の他のPsと/またはPEに接続されています。
LSA - OSPF link State Advertisement
LSA - OSPFリンクステートアドバタイズメント
LSDB - Link State Database: a data structure supported by an IGP speaker
LSDB - リンクステートデータベース：IGPスピーカーによってサポートされるデータ構造
PIT - Port Information Table
PIT - ポート情報テーブル
CPI - Customer Port Identifier
CPI - お客様のポート識別子
PPI - Provider Port Identifier
PPI - プロバイダポート識別子
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]に記載されているように解釈されます。
This section defines the L1VPN LSA and its TLVs.
このセクションでは、L1VPN LSAとそのTLVを定義します。
The format of a L1VPN LSA is as follows:
次のようにL1VPN LSAの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN Info TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Link TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LS age As defined in [RFC2328].
[RFC2328]で定義されているようにLS時代。
Options As defined in [RFC2328].
[RFC2328]で定義されるようにオプション。
LS Type This field MUST be set to 11, i.e., an Autonomous System (AS) scoped Opaque LSA [RFC5250].
LSタイプは、このフィールドは11に設定されなければならない、すなわち、自律システム（AS）は、オペークLSA [RFC5250]をスコープ。
Opaque Type The value of this field MUST be set to 5.
OPAQUE型は、このフィールドの値は5に設定しなければなりません。
Opaque ID As defined in [RFC5250].
[RFC5250]で定義されるように、不透明なID。
Advertising Router As defined in [RFC2328].
[RFC2328]で定義されているように広告ルータ。
LS Sequence Number As defined in [RFC2328].
[RFC2328]で定義されるようにLSシーケンス番号。
LS checksum As defined in [RFC2328].
[RFC2328]で定義されるようにLSチェックサム。
Length As defined in [RFC2328].
[RFC2328]で定義されるように長さ。
L1VPN Info TLV A single TLV, as defined in Section 3.2, MUST be present. If more than one L1VPN Info TLV is present, only the first TLV is processed and the others MUST be ignored on receipt.
L1VPN情報TLV A単TLVは、セクション3.2で定義されるように、存在していなければなりません。複数のL1VPN情報TLVが存在する場合は、最初のTLVが処理され、他の人は、領収書で無視しなければなりません。
TE Link TLV A single TE Link TLV (as defined in [RFC3630] and [RFC4203]) MAY be included in a L1VPN LSA.
TEリンクTLV単一TEリンクTLVは（[RFC3630]及び[RFC4203]で定義されるように）L1VPN LSAに含まれるかもしれ。
The following TLV is introduced:
以下のTLVが導入されています。
Name: L1VPN IPv4 Info Type: 1 Length: Variable
名前：L1VPN IPv4の情報タイプ：1本の長さ：可変
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN TLV Type | L1VPN TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN Globally Unique Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE TE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| L1VPN Auto-Discovery Information |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L1VPN TLV Type The type of the TLV.
L1VPN TLVは、TLVの種類を入力します。
TLV Length The length of the TLV in bytes, excluding the 4 bytes of the TLV header and, if present, the length of the Padding field.
TLVヘッダと、存在する場合、パディングフィールドの長さの4つのバイトを除いTLVバイトでTLVの長さを長さ。
L1VPN Globally Unique Identifier As defined in [RFC5251].
[RFC5251]で定義されるようL1VPNグローバル一意識別子。
PE TE Address This field MUST carry an address that has been advertised by the LSA originator per [RFC3630] and is either the Router Address TLV or Local interface IP address link sub-TLV. It will typically carry the TE Router Address.
PE TEアドレスは、このフィールドは、[RFC3630]あたりLSAオリジネータによってアドバタイズされたアドレスを携帯し、ルータアドレスTLVまたはローカルインタフェースのIPアドレスリンクサブTLVのいずれかでなければなりません。それは、典型的には、TEルータアドレスを運ぶでしょう。
Link Local Identifier This field is used to support unnumbered links. When an unnumbered PE TE link is represented, this field MUST contain a value advertised by the LSA originator per [RFC4203] in a Link Local/Remote Identifiers link sub-TLV. When a numbered link is represented, this field MUST be set to 0.
リンクローカル識別子は、このフィールドは無番号リンクをサポートするために使用されます。無数PE TEリンクが表されている場合、このフィールドは、リンクローカル/リモート識別子サブTLVをリンクに[RFC4203]あたりLSAオリジネータによってアドバタイズ値を含まなければなりません。番リンクが表現されている場合、このフィールドは0に設定しなければなりません。
L1VPN Auto-discovery information As defined in [RFC5251].
[RFC5251]で定義されるようL1VPN自動検出情報。
Padding A field of variable length and of sufficient size to ensure that the TLV is aligned on a 4-byte boundary. This field is only required when the L1VPN Auto-discovery information field is not 4-byte aligned. This field MUST be less than 4 bytes long, and MUST NOT be present when the size of the L1VPN Auto-discovery information field is 4-byte aligned.
TLVは、4バイト境界で整列されることを確実にするために可変長の十分な大きさのフィールドをパディング。 L1VPN自動検出情報フィールドは4バイトが整列していない場合、このフィールドにのみ必要です。このフィールドは、4バイト未満でなければならず、また、L1VPN自動検出情報フィールドのサイズは4バイトアラインされたときに存在してはなりません。
PEs advertise local <CPI, PPI> tuples in L1VPN LSAs containing L1VPN Info TLVs. Each PE MUST originate a separate L1VPN LSA with AS flooding scope for each local CE-to-PE link. The LSA MUST be originated each time a PE restarts and every time there is a change in the PIT entry associated with a local CE-to-PE link. The LSA MUST include a single L1VPN Info TLV and MAY include a single TE Link TLV as per [RFC3630] and [RFC4203]. The TE Link TLV carries TE attributes of the associated CE-to-PE link. Note that because CEs are outside of the provider TE domain, the attributes of CE-to-PE links are not advertised via normal OSPF-TE procedures as described in [RFC3630] and [RFC4203]. If more than one L1VPN Info TLVs and/or TE Link TLVs are found in the LSA, the subsequent TLVs SHOULD be ignored by the receiving PEs.
PEはL1VPN情報TLVを含むL1VPNのLSAの中にローカル<CPI、PPI>タプルを宣伝します。各PEは、それぞれのローカルCEツーPEリンク用AS氾濫範囲で別L1VPN LSAを発信しなければなりません。 LSAはローカルCEツーPEリンクに関連付けられたPITエントリに変更があるたびにPEが再起動し、毎回を発信しなければなりません。 LSAは、単一L1VPN情報TLVを含まなければならないし、[RFC3630]と[RFC4203]あたりのように、単一のTEリンクTLVを含むかもしれません。 TEリンクTLVは、関連するCEツーPEリンクのTE属性を運びます。 CEが、プロバイダTEドメインの外にあるので、CEツーPEリンクの属性は[RFC3630]及び[RFC4203]に記載されているように、通常のOSPF-TEの手順によってアドバタイズされないことに留意されたいです。複数のL1VPN情報のTLVおよび/またはTEリンクのTLVがLSAに発見された場合、それ以降のTLVは受信のPEによって無視されるべきです。
L1VPN LSAs are of AS-scope (LS type is set to 11) and therefore are flooded to all PEs within the AS according to [RFC5250]. Every time a PE receives a new, removed, or modified L1VPN LSA, the PE MUST check whether it maintains a PIT associated with the L1VPN specified in the L1VPN globally unique identifier field. If this is the case (the appropriate PIT will be found if one or more local CE-to-PE links that belong to the L1VPN are configured), the PE SHOULD add, remove, or modify the PIT entry associated with each of the advertised CE-to-PE links accordingly. (An implementation MAY choose to not remove or modify the PIT according to local policy or management directives.) Thus, in the normal steady-state case, all PEs associated with a particular L1VPN will have identical local PITs for an L1VPN.
L1VPN LSAは、AS-範囲である（LSタイプが11に設定されている）、したがって、[RFC5250]に記載のAS内のすべてのPEにフラッディングされます。 PEは、新しい、除去、または修飾L1VPN LSAを受信するたびに、PEは、グローバル一意識別子フィールドL1VPNで指定L1VPNに関連付けられたPITを維持するかどうかをチェックしなければなりません。この場合（L1VPNに属する1つ以上のローカルCEツーPEリンクが設定されている場合、適切なPITが発見される）、PEは、追加、削除、または広告さのそれぞれに関連するPITエントリを変更する必要がありますしたがってCEツーPEリンク。 （実装がローカルポリシーまたは管理指示に従ってPITを削除または変更しないことを選ぶかもしれません。）このように、通常の定常状態の場合には、特定のL1VPNに関連付けられたすべてのPEはL1VPNに対して同じローカルピットを有することになります。
The L1VPN auto-discovery mechanism described in this document does not prevent a PE from applying any local policy with respect to PIT management. An example of such a local policy would be the ability to configure permanent (static) PIT entries. Another example would be the ability to ignore information carried in L1VPN LSAs advertised by a specific TE.
この文書に記載さL1VPN自動検出機構は、PIT管理に対して任意のローカルポリシーを適用することからPEを妨げません。そのようなローカルポリシーの一例は、永久的な（静的）PITエントリを設定する能力であろう。別の例は、特定のTEによってアドバタイズL1VPNのLSAの中で運ばれる情報を無視する能力であろう。
The reason why it is required that the value specified in the PE TE Address field of the L1VPN Info TLV matches a valid PE TE Router ID or numbered TE Link ID is to ensure that CEs attached to this PE can be resolved to the PE as it is known to the Traffic Engineering Database (TED) and hence TE paths toward the CEs across the provider domain can be computed.
L1VPN情報TLVのPE TEアドレスフィールドで指定された値が有効なPE TEルータIDまたは番号TEリンクIDは、このPEに添付のCEはそれとしてPEに解決できることを確実にするためであると一致することを必要とされる理由トラフィックエンジニアリングデータベース（TED）に知られており、プロバイダードメイン全体のCEに向かって、したがってTEパスを計算することができます。
Let us consider the example presented in Figure 2.
私たちは、図2に示す例を考えてみましょう。
CE11 CE13
| |
CE22---PE1--------P------PE2
| |
CE15 PE3
|
CE24
Figure 2: Single Area Configuration
図2：シングルエリアの設定
Let us assume that PE1 is connected to CE11 and CE15 in L1VPN1 and to CE22 in L1VPN2; PE2 is connected to CE13 in L1VPN1; PE3 is connected to CE24 in L1VPN2. In this configuration PE1 manages two PITs: PIT1 for L1VPN1 and PIT2 for L1VPN2; PE2 manages only PIT1; and PE3 manages only PIT2. PE1 originates three L1VPN LSAs, each containing a L1VPN Info TLV advertising links PE1-CE11, PE1-CE22, and PE1-CE15, respectively. PE2 originates a single L1VPN LSA for link PE2-CE13, and PE3 originates a single L1VPN LSA for link PE3-CE24. In steady state, the PIT1 on PE1 and PE3 will contain information on links PE1-CE11, PE1-CE15, and PE2-CE13; PIT2 on PE1 and PE2 will contain entries for links PE1-CE22 and PE3-CE24. Thus, all PEs will learn about all remote PE-to-CE links for all L1VPNs supported by PEs.
私たちはPE1がL1VPN1におけるCE11およびCE15へとL1VPN2でCE22に接続されていると仮定しましょう。 PE2はL1VPN1でCE13に接続されています。 PE3はL1VPN2にCE24に接続されています。この構成ではPE1は2つのピット管理：L1VPN1とL1VPN2ためPIT2ためPIT1を。 PE2はPIT1を管理します。そして、PE3はPIT2を管理します。 PE1は3つのL1VPN LSAを発信し、L1VPN情報TLVの広告を含む各はPE1-CE11、PE1-CE22、それぞれPE1-CE15は、リンクします。 PE2は、リンクPE2-CE13のための単一のL1VPN LSAを発信し、PE3は、リンクPE3-CE24のための単一のL1VPN LSAを発信します。定常状態では、PE1とPE3上PIT1はリンクPE1-CE11、PE1-CE15、およびPE2-CE13に関する情報が含まれています。 PE1とPE2のPIT2はリンクPE1-CE22およびPE3-CE24のエントリが含まれています。このように、全てのPEは、PESでサポートされているすべてのL1VPNsためのすべてのリモートPE-へ-CEリンクについて学習します。
Note that P in this configuration does not have links connecting it to any L1VPNs. It neither originates L1VPN LSAs nor maintains any PITs. However, it does participate in the flooding of all of the L1VPN LSAs and hence maintains the LSAs in its LSDB. This is a cause for scalability concerns and could prove to be problematic in large networks.
Pは、この構成で任意のL1VPNsにそれを接続するリンクを持っていないことに注意してください。これはどちらもL1VPN LSAを発信したり任意のピットを維持します。しかし、それはL1VPN LSAの全ての氾濫に参加しないので、そのLSDBにLSAを維持しています。これは、スケーラビリティの問題の原因であると、大規模なネットワークでは問題になるかもしれません。
Neither the TLV nor the LSA introduced in this document present any interoperability issues. Per [RFC5250], OSPF speakers that do not support the L1VPN auto-discovery application (Ps for example) just participate in the L1VPN LSAs flooding process but should ignore the LSAs contents.
TLVもLSAどちらも、任意の相互運用性の問題を提示し、この文書で紹介しました。パー[RFC5250]、（例えばPS）L1VPN自動検出アプリケーションをサポートしていないOSPFのスピーカーだけL1VPNのLSAフラッディングプロセスに参加するが、LSAの内容を無視すべきです。
The approach presented in this document describes how PEs dynamically learn L1VPN-specific information. Mechanisms to deliver the VPN membership information to CEs are explicitly out of scope of this document. Therefore, the security issues raised in this document are limited to within the OSPF domain.
この文書のアプローチは、PEは動的L1VPN固有の情報を知る方法を説明します。 CEにVPNメンバーシップ情報を提供するためのメカニズムはこの文書の範囲の外に明示されています。したがって、本書で提起されたセキュリティ上の問題は、OSPFドメイン内に限定されています。
This defined approach reuses mechanisms defined in [RFC2328] and [RFC5250]. Therefore, the same security approaches and considerations apply to this approach. OSPF provides several security mechanisms that can be applied. Specifically, OSPF supports multiple types of authentication, limits the frequency of LSA origination and acceptance, and provides techniques to avoid and limit impact database overflow. In cases where end-to-end authentication is desired, OSPF's neighbor-to-neighbor authentication approach can be augmented with an experimental extension to OSPF; see [RFC2154], which supports the signing and authentication of LSAs.
この定義されたアプローチは、[RFC2328]及び[RFC5250]で定義されたメカニズムを再利用します。そのため、同じセキュリティアプローチと考慮事項は、このアプローチに適用されます。 OSPFを適用することができるいくつかのセキュリティメカニズムを提供します。具体的には、OSPFは、認証の複数のタイプをサポートLSA発信及び受け入れの頻度を制限し、影響データベースオーバーフローを回避し、制限する技術を提供します。エンドツーエンドの認証が望まれる場合には、OSPFの隣接対の隣接認証アプローチは、OSPFに実験的拡張で拡張することができます。 LSAの署名および認証をサポートしています[RFC2154]を参照してください。
This document requests the assignment of an OSPF Opaque LSA type. IANA has made the assignment in the form:
この文書では、OSPFオペークLSAタイプの割り当てを要求します。 IANAは、フォームでの割り当てを行いました。
Value Opaque Type Reference
------- ----------- ---------
5 L1VPN LSA [RFC5252]
We would like to thank Adrian Farrel and Anton Smirnov for their useful comments.
私たちは彼らの有益なコメントをエードリアンファレルとアントン・スミルノフに感謝したいと思います。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、エド。、およびY. Rekhter、エド。、RFC 4203、2005年10月 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"。
[RFC5250] Berger, L., Bryskin, I., and A. Zinin, "The OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5250]バーガー、L.、Bryskin、I.、およびA.ジニン、 "OSPF Opaque LSAオプション"、RFC 5250、2008年7月。
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, July 2008.
[RFC5251] Fedyk、D.、エド。、Rekhter、Y.、エド。、Papadimitriou、D.、Rabbat、R.、およびL.バーガー、 "レイヤ1 VPN基本モード"、RFC 5251、2008年7月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154]マーフィー、S.、アナグマ、M.、およびB.ウェリントン、 "デジタル署名とOSPF"、RFC 2154、1997年6月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[RFC4847]武田、T.、エド。、 "フレームワークおよびレイヤ1つの仮想プライベートネットワークの要件"、RFC 4847、2007年4月。
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5195]ウルド - Brahimの、H.、Fedyk、D.、およびY. Rekhter、 "BGPベースの自動検出のためのレイヤ1のVPN"、RFC 5195、2008年6月。
Authors' Addresses
著者のアドレス
Igor Bryskin ADVA Optical Networking Inc 7926 Jones Branch Drive Suite 615 McLean, VA 22102 EMail: ibryskin@advaoptical.com
イゴールBryskin ADVA社株式会社7926・ジョーンズ支店ドライブスイート615マクリーン、VA 22102 Eメール：ibryskin@advaoptical.com
Lou Berger LabN Consulting, LLC EMail: lberger@labn.net
ルー・バーガーLabNコンサルティング、LLCメール：lberger@labn.net
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に情報を記述してください。