[要約] RFC 5523は、OSPFv3を使用したLayer 1 VPNの自動検出に関する仕様です。このRFCの目的は、OSPFv3を使用してLayer 1 VPNの自動検出を実現し、ネットワーク管理者がVPNの構成を簡素化することです。
Network Working Group L. Berger
Request for Comment: 5523 LabN Consulting, LLC
Category: Experimental April 2009
OSPFv3-Based Layer 1 VPN Auto-Discovery
OSPFV3ベースのレイヤー1 VPNオートディスコーブリー
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6.
このドキュメントでは、OSPFV3ベースの（最も短いパスファーストバージョン3）レイヤー1仮想プライベートネットワーク（L1VPN）自動指定メカニズムを定義します。このドキュメントは、既存のOSPFバージョン2 L1VPNオート配分メカニズムと類似しています。顕著な機能の違いは、IPv6のサポートです。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. Conventions Used in This Document ..........................3
1.3. Overview ...................................................3
2. OSPFv3 L1VPN LSA and Its TLVs ...................................5
2.1. OSPFv3 L1VPN LSA ...........................................5
2.2. L1VPN IPv6 INFO TLV ........................................7
3. OSPFv3 L1VPN LSA Advertising and Processing .....................8
4. Backward Compatibility ..........................................9
5. Manageability Considerations ....................................9
5.1. Coexistence with and Migration from OSPFv2 .................9
6. Security Considerations ........................................10
7. IANA Considerations ............................................11
8. Acknowledgment .................................................11
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6.
このドキュメントでは、OSPFV3ベースの（最も短いパスファーストバージョン3）レイヤー1仮想プライベートネットワーク（L1VPN）自動指定メカニズムを定義します。このドキュメントは、既存のOSPFバージョン2 L1VPNオート配分メカニズムと類似しています。顕著な機能の違いは、IPv6のサポートです。
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 [RFC5340], [RFC5329], and [RFC5252]. In particular, the following terms:
このドキュメントの読者は、[RFC4847]および[RFC5251]で使用される用語に精通している必要があります。このドキュメントの読者は、[RFC5340]、[RFC5329]、および[RFC5252]にも精通している必要があります。特に、次の用語：
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カスタマー（EDGE）プロバイダーネットワークに直接接続されているネットワーク要素（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プロバイダー（Edge）ネットワーク要素は、1つ以上の顧客ネットワークに直接接続されています（同じまたは異なるL1VPNに関連付けられた1つまたは複数のCESへの1つ以上のリンクを終了します）。また、1つ以上のPSおよび/または他のPEに接続されています。
P Provider (core) network element that is not directly connected to any of Customer networks; P is connected to one or more other Ps and/or PEs.
Pプロバイダー（コア）ネットワーク要素は、顧客ネットワークのいずれにも直接接続されていません。Pは、1つ以上の他のPSおよび/またはPESに接続されています。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
The framework for Layer 1 VPNs is described in [RFC4847]. Basic mode operation is further defined in [RFC5251]. [RFC5251] identifies the information that is necessary to map customer information (port identifiers) to provider information (identifiers). It also states that this mapping information may be provided via provisioning or via an auto-discovery mechanism. [RFC5252] provides such an auto-discovery mechanism using Open Shortest Path First (OSPF) version 2. This document provides the same functionality using OSPF version 3 and adds support for IPv6.
レイヤー1 VPNのフレームワークは[RFC4847]で説明されています。基本モードの操作は、[RFC5251]でさらに定義されています。[RFC5251]顧客情報（ポート識別子）をプロバイダー情報（識別子）にマッピングするために必要な情報を識別します。また、このマッピング情報は、プロビジョニングまたは自動発見メカニズムを介して提供される可能性があると述べています。[RFC5252]は、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 Layer 1 VPNs. 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つの異なるレイヤー1 VPNに属する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オートディスコーブリー
The approach used in this document to provide OSPFv3-based L1VPN auto-discovery uses a new type of Link State Advertisement (LSA), which is referred to as an OSPFv3 L1VPN LSA. The OSPFv3 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.
このドキュメントで使用されているアプローチは、OSPFV3ベースのL1VPNオートディスコービリを提供するために、OSPFV3 L1VPN LSAと呼ばれる新しいタイプのリンク状態広告（LSA）を使用します。OSPFV3 L1VPN LSAは、TLV（タイプ、長さ、値）構造で情報を掲載しています。L1VPN固有のTLVは、VPNメンバーシップとポート情報を伝播するために以下に定義されています。このTLVは、L1VPN情報TLVと呼ばれます。
The OSPFv3 L1VPN LSA may also carry Traffic Engineering (TE) TLVs; see [RFC3630], [RFC4203], and [RFC5329].
OSPFV3 L1VPN LSAは、トラフィックエンジニアリング（TE）TLVを運ぶこともあります。[RFC3630]、[RFC4203]、および[RFC5329]を参照してください。
This section defines the OSPFv3 L1VPN LSA and its TLVs.
このセクションでは、OSPFV3 L1VPN LSAとそのTLVを定義します。
The format of a OSPFv3 L1VPN LSA is as follows:
OSPFV3 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 | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN Info TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Link TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LS age
LS年齢
As defined in [RFC5340].
[RFC5340]で定義されています。
LS type
LSタイプ
As defined in [RFC5340]. The U-bit MUST be set to 1, and the S1 and S2 bits MUST be set to indicate either area or Autonomous System (AS) scoping. The LSA Function Code portion of this field MUST be set to 14, i.e., the OSPFv3 L1VPN LSA.
[RFC5340]で定義されています。Uビットは1に設定する必要があり、S1およびS2ビットは、領域または自律システム（AS）スコープのいずれかを示すように設定する必要があります。このフィールドのLSA関数コード部分は、14、つまりOSPFV3 L1VPN LSAに設定する必要があります。
Advertising Router
広告ルーター
As defined in [RFC5340].
[RFC5340]で定義されています。
LS Sequence Number
LSシーケンス番号
As defined in [RFC5340].
[RFC5340]で定義されています。
LS checksum
LSチェックサム
As defined in [RFC5340].
[RFC5340]で定義されています。
Length
長さ
As defined in [RFC5340].
[RFC5340]で定義されています。
L1VPN Info TLV
L1VPN INFO TLV
A single L1VPN Info TLV, as defined in Section 2.2 of [RFC5252] or Section 2.2 of this document, 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. If no L1VPN Info TLV is present, the LSA is processed (and flooded) as normal, but the L1VPN PIT table MUST NOT be modified in any way.
[RFC5252]のセクション2.2またはこのドキュメントのセクション2.2で定義されている単一のL1VPN情報TLVが存在する必要があります。複数のL1VPN情報TLVが存在する場合、最初のTLVのみが処理され、他のTLVは受領時に無視する必要があります。L1VPN情報TLVが存在しない場合、LSAは通常どおり処理されます（および浸水します）が、L1VPNピットテーブルは決して変更してはなりません。
TE Link TLV
te link tlv
A single TE Link TLV MAY be included in an OSPFv3 L1VPN LSA. When an L1VPN IPv4 Info TLV is present, a single TE Link TLV as defined in [RFC3630] and [RFC4203] MAY be included. When an L1VPN IPv6 Info TLV is present, a single TE Link TLV as defined in [RFC5329] MAY be included.
単一のTEリンクTLVは、OSPFV3 L1VPN LSAに含まれる場合があります。L1VPN IPv4 Info TLVが存在する場合、[RFC3630]および[RFC4203]で定義されている単一のTEリンクTLVが含まれる場合があります。L1VPN IPv6 Info TLVが存在する場合、[RFC5329]で定義されている単一のTEリンクTLVが含まれる場合があります。
The following TLV is introduced:
次のTLVが紹介されています。
Name: L1VPN IPv6 Info Type: 32768 Length: Variable
名前：L1VPN IPv6情報タイプ：32768長さ：変数
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
L1VPN TLVタイプ
The type of the TLV (see above).
TLVのタイプ（上記参照）。
TLV Length
TLV長
The length of the TLV in bytes, excluding the four (4) bytes of the TLV header and, if present, the length of the Padding field.
TLVのTLVの長さは、TLVヘッダーの4バイト（4）バイト、および存在する場合、パディングフィールドの長さを除きます。
L1VPN Globally Unique Identifier
L1VPNグローバルに一意の識別子
As defined in [RFC5251].
[RFC5251]で定義されています。
PE TE Address
PE TEアドレス
This field MUST carry an address that has been advertised by the LSA originator per [RFC5329] and is either the Router IPv6 Address TLV or Local Interface IPv6 Address link sub-TLV. It will typically carry the TE Router Address.
このフィールドは、[RFC5329]ごとにLSAオリジネーターによって宣伝されており、Router IPv6アドレスTLVまたはローカルインターフェイスIPv6アドレスリンクSub-TLVのいずれかであるアドレスを搭載する必要があります。通常、TEルーターアドレスが搭載されます。
Link-Local Identifier
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 [RFC5340] in a Router LSA. When a numbered link is represented, this field MUST be set to zero (0).
このフィールドは、数え切れないほどのリンクをサポートするために使用されます。数のペテリンクが表される場合、このフィールドには、ルーターLSAの[RFC5340]ごとにLSAオリジネーターによって宣伝されている値を含める必要があります。番号付きリンクが表されている場合、このフィールドはゼロ（0）に設定する必要があります。
L1VPN Auto-Discovery Information
L1VPN自動配置情報
As defined in [RFC5251].
[RFC5251]で定義されています。
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 L1VPN Auto-Discovery Information field is 4-byte aligned.
TLVが4バイトの境界に並べられるように、可変長さと十分なサイズのフィールド。このフィールドは、L1VPNオートディスコービリ情報フィールドが4バイトアライメントされていない場合にのみ必要です。このフィールドは4バイト未満の長さでなければならず、L1VPNオートディスコービリ情報フィールドのサイズが4バイトアライメントされている場合は、存在しないでください。
PEs advertise local <CPI, PPI> tuples in OSPFv3 L1VPN LSAs containing L1VPN Info TLVs. Each PE MUST originate a separate OSPFv3 L1VPN LSA with area or AS flooding scope, based on configuration, for each local CE-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-PE link. The LSA MUST include a single L1VPN Info TLV and MAY include a single TE Link TLV. The TE Link TLV carries TE attributes of the associated CE-PE link. Note that because CEs are outside of the provider TE domain, the attributes of CE-PE links are not advertised via normal OSPF-TE procedures as described in [RFC5329]. 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を含むOSPFV3 L1VPN LSAのローカル<CPI、PPI> TUPPLEを宣伝します。各PEは、各ローカルCE-PEリンクの構成に基づいて、面積または洪水範囲として別のOSPFV3 L1VPN LSAを発生する必要があります。LSAは、PEが再起動するたびに発信し、ローカルCE-PEリンクに関連付けられたピットエントリに変更があるたびに発信する必要があります。LSAには、単一のL1VPN情報TLVを含める必要があり、単一のTEリンクTLVを含めることができます。TEリンクTLVには、関連するCE-PEリンクのTE属性が含まれています。CESはプロバイダーTEドメインの外側にあるため、[RFC5329]で説明されているように、CE-PEリンクの属性は通常のOSPF-TE手順を介して宣伝されていないことに注意してください。複数のL1VPN情報TLVおよび/またはTEリンクTLVがLSAにある場合、その後のTLVは受信PESによって無視される必要があります。
Every time a PE receives a new, removed, or modified OSPFv3 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-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-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.
PEが新しい、除去、または変更されたOSPFV3 L1VPN LSAを受信するたびに、PEはL1VPNグローバルに一意の識別子フィールドで指定されたL1VPNに関連付けられたPITを維持するかどうかを確認する必要があります。この場合（L1VPNに属する1つ以上のローカルCE-PEリンクが設定されている場合、適切なピットが見つかります）、PEは、広告された各CE-に関連付けられた各ピットエントリを追加、削除、または変更する必要があります。それに応じてPEがリンクします。（実装は、ローカルポリシーまたは管理指令に従ってPITを削除または変更しないことを選択できます。）したがって、通常の定常状態の場合、特定のL1VPNに関連付けられたすべてのPEには、L1VPNの同一のローカルピットがあります。
Neither the TLV nor the LSA introduced in this document present any interoperability issues. Per [RFC5340], and due to the U-bit being set, OSPFv3 speakers that do not support the OSPFv3 L1VPN LSA (Ps for example) just participate in the LSA's flooding process but should ignore the LSA's contents.
このドキュメントで導入されたTLVもLSAも、相互運用性の問題を提示しません。[RFC5340]ごとに、およびUビットが設定されているため、OSPFV3 L1VPN LSA（PSなど）をサポートしていないOSPFV3スピーカーは、LSAの洪水プロセスに参加するだけでなく、LSAの内容を無視する必要があります。
The principal concern in operating an auto-discovery mechanism for an L1VPN is that the PE needs to be configured with information about which VPNs it supports. This information can be discovered from the CEs using some form of membership negotiation, but is more likely to be directly configured by the operator as described in [RFC4847], [RFC5251], and [RFC5253]. No standardized mechanisms to configure this information have been defined, and it is a matter for individual implementations with input from operator policy how a PE is told which L1VPNs it supports. It is probable that configuration of this information is closely tied to the configuration of CE-facing ports on the PE, which in turn causes PITs to be established in the PE.
L1VPNの自動発見メカニズムを操作する際の主な関心事は、PEをサポートするVPNに関する情報とともに構成する必要があることです。この情報は、何らかの形のメンバーシップネゴシエーションを使用してCESから発見できますが、[RFC4847]、[RFC5251]、および[RFC5253]で説明されているように、オペレーターによって直接構成される可能性が高くなります。この情報を構成する標準化されたメカニズムは定義されていません。また、PEがどのL1VPNSをサポートするかをPEがどのように通知されるかを入力した個々の実装の問題です。この情報の構成は、PE上のCEに向かうポートの構成に密接に結び付けられている可能性があり、これによりPEにピットが確立されます。
Additionally, it may be of value to an operator to view the L1VPN membership information that has been learned by a PE. An implementation may supply this information through a proprietary interface, or may allow it to be inspected through the OSPFv3 MIB module [OSPFv3-MIB] or the Traffic Engineering Database MIB [TED-MIB].
さらに、PEによって学習されたL1VPNメンバーシップ情報を表示することは、オペレーターにとって価値がある場合があります。実装は、独自のインターフェイスを介してこの情報を提供したり、OSPFV3 MIBモジュール[OSOSPFV3-MIB]またはトラフィックエンジニアリングデータベースMIB [TED-MIB]を介して検査することを可能にする場合があります。
Note that the operation of the control plane has no impact on IP network traffic because all of the user data is in Layer 1, while the control plane is necessarily out of band in a Data Communications Network (DCN).
すべてのユーザーデータはレイヤー1にあるため、コントロールプレーンの動作はIPネットワークトラフィックに影響を与えませんが、コントロールプレーンは必然的にデータ通信ネットワーク（DCN）でバンドから外れています。
It is expected that only a single routing protocol instance will be used to operate auto-discovery within an L1VPN at any time. Thus, coexistence issues only apply to the migration from OSPFv2 to OSPFv3 and can be expected to be transient.
L1VPN内の自動発見をいつでも使用するために、単一のルーティングプロトコルインスタンスのみが使用されることが予想されます。したがって、共存の問題は、OSPFV2からOSPFV3への移行にのみ適用され、一時的であると予想されます。
Migration from OSPFv2 to OSPFv3 would be a once-only event for any network and would probably depend on the migration of the routing protocol used within the network for normal GMPLS procedures. The migration process would not be any different from the process used to migrate the normal GMPLS routing protocol. The steps to follow are clearly a matter for the operator of the network and are not a matter for standardization, but the following sequence is provided to illustrate the potential actions:
OSPFV2からOSPFV3への移行は、あらゆるネットワークの回数のみのイベントであり、おそらく通常のGMPLS手順のためにネットワーク内で使用されるルーティングプロトコルの移行に依存します。移行プロセスは、通常のGMPLSルーティングプロトコルを移行するために使用されるプロセスと違いはありません。従うべき手順は明らかにネットワークのオペレーターにとって問題であり、標準化の問題ではありませんが、潜在的なアクションを説明するために次のシーケンスが提供されています。
1. Assign IPv6 addresses to all control plane and data plane resources.
1. すべての制御プレーンおよびデータプレーンリソースにIPv6アドレスを割り当てます。
2. Install and enable OSPFv3 on all controllers.
2. すべてのコントローラーにOSPFV3をインストールして有効にします。
3. Use OSPFv3 to advertise IPv4 and IPv6 resource identifiers.
3. OSPFV3を使用して、IPv4およびIPv6リソース識別子を宣伝します。
4. Manually verify the advertised membership and topology information from the OSPFv2 and OSPFv3 databases.
4. OSPFV2およびOSPFV3データベースから広告されたメンバーシップおよびトポロジ情報を手動で検証します。
5. Start a maintenance window where data continues to flow, but no L1VPN connections can be changed.
5. データが流れ続けるメンテナンスウィンドウを開始しますが、L1VPN接続は変更できません。
6. Cut over to the OSPFv3 membership and topology information.
6. OSPFV3メンバーシップとトポロジー情報に切り替えます。
7. Close the maintenance window.
7. メンテナンスウィンドウを閉じます。
8. Turn off OSPFv2.
8. OSPFv2をオフにします。
9. Remove/disable the IPv4 address for all control plane and data plane resources.
9. すべての制御プレーンおよびデータプレーンのリソースのIPv4アドレスを削除/無効にします。
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 [RFC5340]. 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 the impact of database overflow. In cases were end-to-end authentication is desired, OSPF's neighbor-to-neighbor authentication approach can be augmented with an approach similar to the experimental extension to OSPF, see [RFC2154], which supports the signing and authentication of LSAs.
この定義されたアプローチは、[RFC5340]で定義されたメカニズムを再利用します。したがって、このアプローチには同じセキュリティアプローチと考慮事項が適用されます。OSPFは、適用できるいくつかのセキュリティメカニズムを提供します。具体的には、OSPFは複数のタイプの認証をサポートし、LSAの起源と受け入れの頻度を制限し、データベースオーバーフローの影響を回避および制限する手法を提供します。エンドツーエンドの認証が望まれている場合、OSPFの隣人から隣の認証アプローチは、LSAの署名と認証をサポートする実験的拡張と同様のアプローチで補強できます。[RFC2154]を参照してください。
IANA has assigned an OSPFv3 LSA Function Code as described in Section 2.1 of this document. IANA has made an assignment in the form:
IANAは、このドキュメントのセクション2.1で説明されているように、OSPFV3 LSA関数コードを割り当てました。イアナは次の形式で割り当てられました。
Value OSPFv3 LSA type function Type Reference
------- ----------------------------- ---------
14 OSPFv3 L1VPN LSA [RFC5523]
This document was created at the request of Pasi Eronen. Adrian Farrel and Acee Lindem provided valuable reviews of this document. Adrian also provided the text for Section 5.
このドキュメントは、Pasi Eronenの要請により作成されました。Adrian FarrelとAcee Lindemは、この文書の貴重なレビューを提供しました。エイドリアンはセクション5のテキストも提供しました。
[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月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[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月。
[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月。
[RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-Discovery", RFC 5252, July 2008.
[RFC5252] Bryskin、I。およびL. Berger、「OSPFベースのレイヤー1 VPN自動配置」、RFC 5252、2008年7月。
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008.
[RFC5329] Ishiguro、K.、Manral、V.、Davey、A。、およびA. Lindem、ed。、「Traffic Engineering Extensions to OSPFバージョン3」、RFC 5329、2008年9月。
[OSPFv3-MIB] Joyal, D., Ed. and V. Manral, Ed., "Management Information Base for OSPFv3", Work in Progress, November 2008.
[Ospfv3-mib] Joyal、D.、ed。and V. Manral、ed。、「OSPFV3の管理情報ベース」、2008年11月、進行中の作業。
[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月。
[RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, July 2008.
[RFC5253] Takeda、T.、ed。、「レイヤー1仮想プライベートネットワーク（L1VPN）基本モードの適用声明」、RFC 5253、2008年7月。
[TED-MIB] Miyazawa, M., Otani, T., Nadeau, T., and K. Kumaki, "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Work in Progress, January 2009.
[Ted-Mib] Miyazawa、M.、Otani、T.、Nadeau、T。、およびK. Kumaki、「MPLS-TE/GMPLSをサポートするトラフィックエンジニアリングデータベース管理情報ベース」、2009年1月の進行中。
Author's Address
著者の連絡先
Lou Berger LabN Consulting, LLC EMail: lberger@labn.net
Lou Berger Labn Consulting、LLCメール：lberger@labn.net