[要約] RFC 5252は、OSPFベースのレイヤー1 VPNの自動検出に関する仕様です。このRFCの目的は、異なるネットワーク間でのレイヤー1 VPNの自動検出と設定を容易にすることです。
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
OSPFベースのレイヤー1 VPNオートディスコーブリー
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）ベースのレイヤー1仮想プライベートネットワーク（L1VPN）自動発見メカニズムを定義します。このメカニズムにより、OSPFを使用したプロバイダーエッジ（PE）デバイスが互いの存在と、構成された顧客エッジ（CE）リンクの属性とL1VPNとの関連について動的に学習できます。このドキュメントは、L1VPNフレームワークと要件に基づいて構築され、L1VPN Basic Modeの自動配置メカニズムを提供します。
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]は、プロバイダー情報（識別子）に顧客情報（ポート識別子）をマッピングするために必要な情報を識別します。また、このマッピング情報は、プロビジョニングまたは自動発見メカニズムを介して提供される可能性があると述べています。このドキュメントでは、Open Shortest Path First（OSPF）バージョン2を使用したこのような自動ディスコービリメカニズムを提供します。OSPFバージョン3の使用とIPv6のサポートは、このドキュメントの範囲外であり、個別に定義されます。
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]で使用される用語に精通している必要があります。このドキュメントの読者は、[RFC2328]、[RFC5250]、および[RFC3630]にも精通している必要があります。特に、次の用語：
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-プロバイダーネットワークに直接接続された顧客（エッジ）ネットワーク要素（1つ以上のPESへの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および/またはCESに接続されているカスタマーネットワーク要素
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-プロバイダー（エッジ）ネットワーク要素は、1つ以上の顧客ネットワークに直接接続されています（同じまたは異なるL1VPNに関連付けられた1つまたは複数のCESへの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は1つ以上の他の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
ピット - ポート情報テーブル
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
不透明タイプこのフィールドの値は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 INFO TLVセクション3.2で定義されている単一のTLVが存在する必要があります。複数のL1VPN情報TLVが存在する場合、最初の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の長さTLVの長さは、TLVヘッダーの4バイト、および存在する場合、パディングフィールドの長さを除きます。
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アドレスリンクSub-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.
Link Local Identifierこのフィールドは、非番号のリンクをサポートするために使用されます。リンクのリンクリンクリンクリンクSub-TLVに、非数のPE TEリンクが表されている場合、このフィールドはLSAオリジネーター[RFC4203]ごとに宣伝されている値を含める必要があります。番号付きリンクが表されている場合、このフィールドは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.
PESは、L1VPN情報TLVを含むL1VPN LSAでローカル<CPI、PPI> Tulplesを宣伝します。各PEは、各ローカルCE-PEリンクの洪水スコープを備えた個別のL1VPN LSAを発信する必要があります。LSAは、PEが再起動するたびに発信し、ローカルCEからPEリンクに関連するピットエントリに変更があるたびに発信する必要があります。LSAには、単一のL1VPN情報TLVを含める必要があり、[RFC3630]および[RFC4203]に従って単一のTEリンクTLVを含めることができます。TEリンクTLVには、関連するCE-PEリンクのTE属性が含まれています。CESはプロバイダーTEドメインの外側にあるため、[RFC3630]および[RFC4203]で説明されているように、CE-PEリンクの属性は通常のOSPF-TE手順を介して宣伝されていないことに注意してください。複数のL1VPN情報TLVおよび/またはTEリンクTLVがLSAにある場合、その後のTLVは受信PESによって無視される必要があります。
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はASSCOPE（LSタイプは11に設定されている）であるため、[RFC5250]に従ってAS内のすべてのPEに浸水します。PEが新しい、除去、または変更されたL1VPN LSAを受信するたびに、PEはL1VPNグローバルに一意の識別子フィールドで指定されたL1VPNに関連付けられたPITを維持するかどうかを確認する必要があります。この場合（L1VPNに属する1つまたは複数のローカルCE-PEリンクが設定されている場合、適切なピットが見つかります）それに応じてCE-ToPEリンク。（実装は、ローカルポリシーまたは管理指令に従って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自動配記メカニズムは、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 INFO TLVのPE TEアドレスフィールドで指定された値が有効なPE TEルーターIDまたは番号付きTEリンクIDと一致する必要がある理由は、このPEに接続されたCEがPEに解決できることを確認するためです。トラフィックエンジニアリングデータベース（TED）で知られているため、プロバイダードメインを介したCESに向かって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のPIT1とL1VPN2のPIT2。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のエントリが含まれます。したがって、すべてのPESは、PESでサポートされているすべてのL1VPNのすべてのリモートPE-To-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]ごとに、L1VPNオート配置アプリケーション（PSなど）をサポートしていないOSPFスピーカーは、L1VPN LSAS洪水プロセスに参加するだけでなく、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.
このドキュメントに示されているアプローチは、PESがL1VPN固有の情報を動的に学習する方法を説明しています。VPNメンバーシップ情報をCESに配信するメカニズムは、このドキュメントの範囲外です。したがって、このドキュメントで提起されたセキュリティの問題は、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タイプの割り当てを要求します。イアナは次の形式で割り当てを行いました。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、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] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to 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.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[RFC5250] Berger, L., Bryskin, I., and A. Zinin, "The OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5250] Berger、L.、Bryskin、I。、およびA. Zinin、「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.、ed。、Rekhter、Y.、ed。、Papadimitriou、D.、Rabbat、R。、およびL. Berger、「レイヤー1 VPN基本モード」、RFC 5251、2008年7月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154] Murphy、S.、Badger、M.、およびB. Wellington、「Digital Signatures with Digital Signatures」、RFC 2154、1997年6月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[RFC4847] Takeda、T.、ed。、「レイヤー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] Oould-Brahim、H.、Fedyk、D。、およびY. Rekhter、「Layer-1 VPNSのBGPベースの自動分類」、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
Igor Bryskin Adva Optical Networking Inc 7926 Jones Branch Drive Suite 615 McLean、VA 22102メール：ibryskin@advaoptical.com
Lou Berger LabN Consulting, LLC EMail: lberger@labn.net
Lou Berger Labn Consulting、LLCメール：lberger@labn.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。