Network Working Group L. Berger
Request for Comment: 5523 LabN Consulting, LLC
Category: Experimental April 2009
OSPFv3-Based Layer 1 VPN Auto-Discovery
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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のベース（Open Shortest Path Firstバージョン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のベース（Open Shortest Path Firstバージョン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]で使用される用語に精通しなければなりません。この文書の読者はまた、[RFC5329]及び[RFC5252]、[RFC5340]に精通しなければなりません。具体的には、次の用語：
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.
プロバイダ・ネットワークに接続されていないが、1つ以上の他CSおよび/またはCEに接続されているC顧客ネットワーク要素。
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 of 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]に記載されているように解釈されます。
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]はこのドキュメントはOSPFバージョン3を使用して同じ機能を提供し、IPv6のサポートを追加オープンショーテストパスファースト（OSPF）バージョン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 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機能コード部分は、すなわち、OSPFv3のL1VPN LSA、14に設定しなければなりません。
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情報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が処理され、他の人は、領収書で無視しなければなりません。何L1VPN情報TLVが存在しない場合、LSAが処理されます（浸水）通常通り、しかしL1VPN PITテーブルが何らかの方法で変更してはいけません。
TE Link TLV
TEリンク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情報TLVが存在する場合、単一のTEリンク[RFC3630]で定義されるようにTLV及び[RFC4203]は含まれるかもしれません。 [RFC5329]で定義されるようL1VPNのIPv6情報TLVは、単一の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.
4つのTLVヘッダのバイトを除いたバイト数TLVの長さは、存在する場合、パディングフィールドの長さ。
L1VPN Globally Unique Identifier
L1VPNグローバル一意識別子
As defined in [RFC5251].
[RFC5251]で定義されます。
PE TE Address
有料住所
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の創始によってアドバタイズおよびルータのIPv6アドレスTLVまたはローカル・インタフェースのIPv6アドレスリンクサブ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 [RFC5340] in a Router LSA. When a numbered link is represented, this field MUST be set to zero (0).
このフィールドは、非番号リンクをサポートするために使用されます。無数PE TEリンクが表されている場合、このフィールドは、ルータ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.
PEはL1VPN情報TLVを含むOSPFv3のL1VPNのLSAの中にローカル<CPI、PPI>タプルを宣伝します。各PEは、それぞれのローカルCE-PEリンクのために、コンフィギュレーションに基づいて、領域またはフラッディングスコープとして別のOSPFv3 L1VPN LSAを発信しなければなりません。 LSAは、ローカルCE-PEリンクに関連付けられたPITエントリに変更があるたびにPEが再起動し、毎回を発信しなければなりません。 LSAは、単一L1VPN情報TLVを含まなければならないし、単一TEリンクTLVを含むかもしれません。 TEリンクTLVは、関連するCE-PEリンクのTE属性を運びます。 CEが、プロバイダTEドメインの外にあるので、CE-PEリンクの属性は、[RFC5329]に記載されているように、通常のOSPF-TEの手順によってアドバタイズされないことに留意されたいです。複数のL1VPN情報のTLVおよび/またはTEリンクのTLVがLSAに発見された場合、それ以降のTLVは受信のPEによって無視されるべきです。
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リンクが設定されている場合、適切なPITが発見される）、PEは、追加、削除、または広告さCE-のそれぞれに関連するPITエントリを変更する必要がありますしたがって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-ビットが設定されているには、（例えばPS）OSPFv3のL1VPN LSAをサポートしていないの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のかについての情報を使用して構成する必要があることです。この情報は、会員ネゴシエーションのいくつかのフォームを使用してのCEから発見されたが、[RFC4847]、[RFC5251]及び[RFC5253]に記載されているように、直接オペレータによって設定される可能性が高くなることができます。この情報を設定するための標準化のメカニズムが定義されていない、それはPEが、それがサポートするL1VPNs語られているかオペレータポリシーからの入力に個々の実装のための問題です。この情報の構成が密接順番にピットがPEで確立させるPE、CEに対向ポートのコンフィギュレーションに関連付けられている可能性が高いです。
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モジュール[OSPFv3の-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であるため、制御プレーンは、データ通信ネットワーク（DCN）に帯域外必ずしもである制御プレーンの動作は、IPネットワークトラフィックに影響を及ぼさないことに留意されたいです。
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内の自動検出を動作させるために使用されることが予想されます。このように、共存の問題はのみのOSPFv3へのOSPFv2からの移行に適用され、一過性であることを期待することができます。
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は、すべてのコントロールプレーンとデータプレーンリソースに対応しています。
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接続は変更できません。
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.
この文書のアプローチは、PEが動的にL1VPN具体的な情報を知る方法を説明します。 CEにVPNメンバーシップ情報を提供するためのメカニズムはこの文書の範囲の外に明示されています。したがって、本書で提起されたセキュリティ上の問題は、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の隣接対の隣接認証アプローチは、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:
このドキュメントのセクション2.1で説明したようにIANAは、OSPFv3のLSA機能コードが割り当てられています。 IANAは、フォームでの割り当てを行いました。
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.
この文書は、パシEronenの依頼で作成されました。エードリアンファレルとACEE Lindemは、このドキュメントの貴重なレビューを提供します。エイドリアンはまた、第5節のテキストを提供します。
[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月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、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]カッツ、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）のサポートで"。
[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月。
[RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-Discovery", RFC 5252, July 2008.
[RFC5252] Bryskin、I.およびL.バーガー、 "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]石黒、K.、Manral、V.、デイビー、A.、およびA. Lindem、エド。、RFC 5329、2008年9月 "OSPFバージョン3へのトラフィックエンジニアリングの拡張"。
[OSPFv3-MIB] Joyal, D., Ed. and V. Manral, Ed., "Management Information Base for OSPFv3", Work in Progress, November 2008.
[OSPFv3の-MIB] Joyal、D.、エド。そして、V. Manral、エド。、「OSPFv3のための管理情報ベース」、進歩、2008年11月の作業。
[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月。
[RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, July 2008.
[RFC5253]武田、T.、エド。、RFC 5253、2008年7月 "レイヤ1仮想プライベートネットワーク（L1VPN）基本モードのための適用性に関する声明"。
[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]宮沢、M.、大谷、T.、ナドー、T.、およびK.熊木、 "MPLS-TE / GMPLSをサポートするトラフィックエンジニアリングデータベース管理情報ベース"、進歩、2009年1月の作業。
Author's Address
著者のアドレス
Lou Berger LabN Consulting, LLC EMail: lberger@labn.net
ルー・バーガーLabNコンサルティング、LLCメール：lberger@labn.net