[要約] RFC 5251は、Layer 1 VPN Basic Modeの仕様を定義しており、物理的なリンクを使用して仮想プライベートネットワーク（VPN）を構築するための手法を提供しています。このRFCの目的は、異なる物理的なネットワークを接続するための標準化された方法を提供することです。
Network Working Group D. Fedyk, Ed.
Request for Comments: 5251 Nortel
Category: Standards Track Y. Rekhter, Ed.
Juniper Networks
D. Papadimitriou
Alcatel-Lucent
R. Rabbat
Google
L. Berger
LabN
July 2008
Layer 1 VPN Basic Mode
レイヤー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 describes the Basic Mode of Layer 1 VPNs (L1VPNs). L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN Basic Mode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology. This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM.
このドキュメントでは、レイヤー1 VPN（L1VPNS）の基本モードについて説明します。L1VPN基本モード（L1VPN BM）は、ポートベースのVPNです。L1VPN基本モードでは、基本的なサービスユニットは、特定のVPNポートトポロジ内の一対の顧客ポート間のラベルスイッチ付きパス（LSP）です。このドキュメントでは、プロビジョニングまたはVPNオートディスコーブリメカニズムのいずれかを使用して、L1VPN BMのシグナリング拡張を使用して運用モデルを定義します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Layer 1 VPN Service .............................................4
3. Addressing, Ports, Links, and Control Channels ..................7
3.1. Service Provider Realm .....................................7
3.2. Layer 1 Ports and Index ....................................7
3.3. Port and Index Mapping .....................................8
4. Port-Based L1VPN Basic Mode ....................................10
4.1. L1VPN Port Information Tables .............................11
4.1.1. Local Auto-Discovery Information ...................12
4.1.2. PE Remote Auto-Discovery Information ...............12
4.2. CE-to-CE LSP Establishment ................................14
4.3. Signaling .................................................15
4.3.1. Signaling Procedures ...............................15
4.3.1.1. Shuffling Sessions ........................16
4.3.1.2. Stitched or Nested Sessions ...............17
4.3.1.3. Other Signaling ...........................18
4.4. Recovery Procedures .......................................19
5. Security Considerations ........................................20
6. References .....................................................21
6.1. Normative References ......................................21
6.2. Informative References ....................................22
7. Acknowledgments ................................................23
This document describes the Basic Mode of Layer 1 VPNs (L1VPN BM) that is outlined in [RFC4847]. The applicability of Layer 1 VPNS is covered in [RFC5253]. In this document, we consider a layer 1 service provider network that consists of devices that support GMPLS (e.g., Lambda Switch Capable (LSC) devices, optical cross-connects, Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) cross-connects, etc.). We partition these devices into P (provider) and PE (provider edge) devices. In the context of this document we will refer to the former devices as just "P", and to the latter devices as just "PE". The Ps are connected only to the devices within the provider's network. The PEs are connected to the other devices within the network (either Ps or PEs), as well as to the devices outside of the service provider network. We'll refer to such other devices as Customer Edge (CE) devices. An example of a CE would be a GMPLS-enabled device that is either a router, an SDH cross-connect, or an Ethernet switch.
このドキュメントでは、[RFC4847]で概説されているレイヤー1 VPN（L1VPN BM）の基本モードについて説明します。レイヤー1 VPNの適用性は[RFC5253]でカバーされています。このドキュメントでは、GMPLS（例えば、Lambdaスイッチ対応デバイス、光クロスコネクト、同期光ネットワーク /同期デジタル階層（SONET / SDH）クロスコネクティをサポートするデバイスで構成されるレイヤー1サービスプロバイダーネットワークを検討します。、など）。これらのデバイスをP（プロバイダー）およびPE（プロバイダーエッジ）デバイスに分割します。このドキュメントのコンテキストでは、以前のデバイスを単なる「P」と呼び、後者のデバイスを「PE」と呼びます。PSは、プロバイダーのネットワーク内のデバイスにのみ接続されています。PESは、ネットワーク内の他のデバイス（PSまたはPES）、およびサービスプロバイダーネットワーク外のデバイスに接続されています。そのような他のデバイスを顧客Edge（CE）デバイスと呼びます。CEの例は、ルーター、SDHクロスコネクト、またはイーサネットスイッチのいずれかであるGMPLS対応デバイスです。
[RFC4208] defines signaling from the CE to the PE. In [RFC4208], the term "Core Node (CN)" corresponds to P and PE nodes, and the term "Edge Node (EN)" corresponds to CE nodes. We additionally define an "edge Core Node" corresponding to a PE.
[RFC4208]は、CEからPEへのシグナル伝達を定義します。[RFC4208]では、「コアノード（CN）」という用語はPおよびPEノードに対応し、「エッジノード（EN）」という用語はCEノードに対応します。さらに、PEに対応する「エッジコアノード」を定義します。
Figure 1 illustrates the components in an L1VPN network.
図1は、L1VPNネットワークのコンポーネントを示しています。
+---+ +---+
| P |....| P |
+---+ +---+
/ \
+-----+ +-----+ +--+
+--+ | PE | | |----| |
|CE|----| | | | |CE|
+--+\ +-----+ | |----| |
\ | | PE | +--+
\ +-----+ | |
\| PE | | | +--+
| | | |----|CE|
+-----+ +-----+ +--+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
Figure 1: Generalized Layer 1 VPN Reference Model
図1：一般化されたレイヤー1 VPN参照モデル
This document specifies how the L1VPN Basic Mode service can be realized using off-line provisioning or VPN auto-discovery, Generalized Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471], [RFC3473], Routing [RFC4202], and LMP [RFC4204] mechanisms.
このドキュメントは、オフラインプロビジョニングまたはVPNオートディスコービリ、一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達[RFC3473]、[RFC4202]、および[RFC4202]、およびLMP [RFC42042044204204204204204204204204204204204204204204204204204204204204204204204204204204204204204204204204204204204204を使用して、L1VPN基本モードサービスを実現する方法を指定します。]メカニズム。
L1VPN auto-discovery has similar requirements [RFC4847] to L3VPN auto-discovery. As with L3VPNs, there are protocol choices to be made with auto-discovery. Section 4.1.1 deals with the information that needs to be discovered.
L1VPNオートディスコベリーには、L3VPNオートディスコーブリと同様の要件[RFC4847]があります。L3VPNSと同様に、自動発見でプロトコルの選択を行う必要があります。セクション4.1.1では、発見する必要がある情報を扱います。
GMPLS routing and signaling are used without extensions within the service provider network to establish and maintain LSC or SONET/SDH (Time Division Multiplexing (TDM)) connections between service provider nodes. This follows the model in [RFC4208].
GMPLSルーティングとシグナリングは、サービスプロバイダーネットワーク内の拡張機能なしで使用され、LSCまたはSONET/SDH（タイムディビジョンマルチプレックス（TDM））サービスプロバイダーノード間の接続を確立および維持します。これは[RFC4208]のモデルに従います。
In L1VPN Basic Mode, the use of LMP facilitates the population of the Port Information Tables of the service provider. Indeed, LMP MAY be used as an option to automate local CE-to-PE link discovery. LMP also MAY augment routing (in enhanced mode) as well as failure handling capabilities.
L1VPN基本モードでは、LMPを使用すると、サービスプロバイダーのポート情報表の母集団が容易になります。実際、LMPは、ローカルCEからPEリンクの発見を自動化するオプションとして使用できます。また、LMPは、ルーティング（強化されたモード）と障害処理機能を強化する場合があります。
Consideration of inter-AS and inter-provider L1VPNs requires further analysis beyond the scope of this document.
AS間およびプロバイダー間のL1VPNを考慮するには、このドキュメントの範囲を超えてさらに分析する必要があります。
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 document expects that the reader is familiar with the terminology defined and used in [RFC3945], [RFC3471], [RFC3473], [RFC3477], [RFC4201], [RFC4202], [RFC4204], [RFC4208], and the documents referenced therein.
このドキュメントは、読者が[RFC3945]、[RFC3471]、[RFC3473]、[RFC4201]、[RFC4202]、[RFC4204]、[RFC4204]、[RFC4208]、および[RFC4202]、[RFC3477]、[RFC3477]、[RFC3477]、[RFC3477]、[RFC3477]、[RFC3477]、[RFC3477]、[RFC3477]、[RFC3477]、[RFC3477]、[RFC3477]」で定義されている用語に精通していることを期待しています。その中で参照されます。
Layer 1 VPN services on the interfaces of customer and service provider ports MAY be any of the Layer 1 interfaces supported by GMPLS. Since the mechanisms specified in this document use GMPLS as the signaling mechanism, and since GMPLS applies to both SONET/SDH (TDM) and LSC interfaces, it follows that L1VPN services include (but are not restricted) to LSC- or TDM-based equipment. Note that this document describes Basic Mode L1VPNs and as such requires that: (1) GMPLS RSVP-TE is used for signaling both within the service provider (between PEs), as well as between the customer and the service provider (between CE and PE);
顧客およびサービスプロバイダーポートのインターフェイス上のレイヤー1 VPNサービスは、GMPLSでサポートされているレイヤー1インターフェイスのいずれかである場合があります。このドキュメントで指定されたメカニズムはGMPLSをシグナル伝達メカニズムとして使用し、GMPLSはSONET/SDH（TDM）とLSCインターフェイスの両方に適用されるため、L1VPNサービスはLSCまたはTDMベースの機器に含まれる（ただし制限されていません）。。このドキュメントは、基本モードL1VPNSを記述しているため、次のことが必要であることに注意してください。（1）GMPLS RSVP-TEは、サービスプロバイダー（PES間）内、および顧客とサービスプロバイダーの両方（CEとPEの間のシグナリングに使用されます。）;
(2) GMPLS Routing on the CE-to-PE link is outside the scope of the Basic Mode of operation of L1VPN; see [RFC4847].
(2) CE-PEリンクのGMPLSルーティングは、L1VPNの基本的な動作モードの範囲外です。[RFC4847]を参照してください。
A CE is connected to a PE via one or more links. In the context of this document, a link is a GMPLS Traffic Engineering (TE) link construct, as defined in [RFC4202]. In the context of this document, a TE link is a logical construct that is a member of a VPN, hence introducing the notion of membership to a set of CEs forming the VPN. Interfaces at the end of each link are limited to either TDM or LSC as supported by GMPLS. More specifically, a <CE, PE> link MUST be of the type <X, LSC> or <Y, TDM> where X = PSC (Packet Switch Capable), L2SC (Layer 2 Switch Capable), or TDM and Y = PSC or L2SC. In case the LSP is not terminated by the CE, X MAY also = LSC and Y = TDM. One of the applications of a L1VPN connection is to provide a "virtual private lambda" or similar. In this case, the CE is truly the endpoint in GMPLS terms, and its switching capability on the TE link is not relevant (although its Generalized Protocol Identifier (GPID) MUST be signaled and identical at both CEs, i.e., head-end and tail-end CE).
CEは、1つ以上のリンクを介してPEに接続されています。このドキュメントのコンテキストでは、リンクは[RFC4202]で定義されているように、GMPLSトラフィックエンジニアリング（TE）リンク構成です。このドキュメントのコンテキストでは、TEリンクはVPNのメンバーである論理的な構造であるため、VPNを形成するCESのセットにメンバーシップの概念を導入します。各リンクの最後のインターフェイスは、GMPLSでサポートされているTDMまたはLSCに限定されています。より具体的には、a <ce、pe>リンクは、x = psc（パケットスイッチ対応）、l2sc（レイヤー2スイッチ対応）、またはtdmおよびy = pscである<x、lsc>または<y、tdm>のタイプ<x、lsc>または<y、tdm>のものでなければなりません。またはL2SC。LSPがCEによって終了しない場合、Xは= LSCおよびY = TDMもできます。L1VPN接続のアプリケーションの1つは、「仮想プライベートラムダ」などを提供することです。この場合、CEはGMPLS用語の真のエンドポイントであり、TEリンクでのその切り替え機能は関連性がありません（ただし、その一般化プロトコル識別子（GPID）は、両方のCES、つまりヘッドエンドとテールで同一である必要があります。-END CE）。
Likewise, PEs could be any Layer 1 devices that are supported by GMPLS (e.g., optical cross-connects, SDH cross-connects), while CEs MAY be devices at layers 1, 2, and 3, such as an SDH cross-connect, an Ethernet switch, and a router, respectively).
同様に、PESはGMPLS（たとえば、光クロスコネクト、SDHクロスコネクトなど）でサポートされているレイヤー1デバイスである可能性がありますが、CESはSDHクロスコネクトなどのレイヤー1、2、および3のデバイスである場合があります。それぞれイーサネットスイッチとルーター）。
Each TE link MAY consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot, respectively). For the purpose of this discussion, all the channels within a given link MUST have similar shared characteristics (e.g., switching capability, encoding, type, etc.), and MAY be selected independently from the CE's point of view. Channels on different links of a CE need not have the same characteristics.
各TEリンクは、1つ以上のチャネルまたはサブチャネル（それぞれ、波長または波長とタイムスロットなど）で構成されている場合があります。この議論の目的のために、特定のリンク内のすべてのチャネルには、同様の共有特性（たとえば、スイッチング機能、エンコード、タイプなど）が必要であり、CEの観点から独立して選択できます。CEのさまざまなリンク上のチャネルには、同じ特性が必要ありません。
There MAY be more than one TE link between a given CE-PE pair. A CE MAY be connected to more than one PE (with at least one port per PE). And, conversely, a PE MAY have more than one CE from different VPNs connected to it.
特定のCE-PEペアの間に複数のTEリンクがある場合があります。CEは、複数のPE（PEごとに少なくとも1つのポート）に接続される場合があります。そして、逆に、PEは、それに接続された異なるVPNから複数のCEを持っている場合があります。
If a CE is connected to a PE via multiple TE links and all the links belong to the same VPN, these links (referred to as component links) MAY be treated as a single TE link using the link bundling constructs [RFC4201].
CEが複数のTEリンクを介してPEに接続され、すべてのリンクが同じVPNに属している場合、これらのリンク（コンポーネントリンクと呼ばれる）は、リンクバンドリングコンストラクト[RFC4201]を使用して単一のTEリンクとして扱うことができます。
In order to satisfy the requirements of the L1VPN Basic Mode, it is REQUIRED that for a given CE-PE pair at least one of the links between them has at least one data bearing channel, and at least one control bearing channel, or that there is IP reachability between the CE and the PE that could be used to exchange control information.
L1VPN基本モードの要件を満たすために、特定のCE-PEペアでは、少なくとも1つのリンクに少なくとも1つのデータベアリングチャネルがあり、少なくとも1つのコントロールベアリングチャネル、またはそこにあることが必要です。制御情報を交換するために使用できるCEとPEの間のIPリーチ可能性です。
A point-to-point link has two end-points: one on the CE and one on the PE. This document refers to the former as "CE port", and to the latter as "PE port". From the above, it follows that a CE is connected to a PE via one or more ports, where each port MAY consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot, respectively), and all the channels within a given port have shared similar characteristics and can be interchanged from the CE's point of view. Similar to the definition of a TE link, in the context of this document, ports are logical constructs that are used to represent a grouping of physical resources that are used to connect a CE to a PE on a per-L1VPN basis.
ポイントツーポイントリンクには2つのエンドポイントがあります。1つはCEに、もう1つはPEに1つです。このドキュメントは、前者を「CEポート」と呼び、後者は「PEポート」と呼んでいます。上記から、CEは1つ以上のポートを介してPEに接続されています。各ポートは、1つ以上のチャネルまたはサブチャネル（それぞれ、波長または波長とタイムスロットなど）、およびすべてのチャネルで構成されている可能性があります。特定のポート内で同様の特性を共有しており、CEの観点から交換することができます。TEリンクの定義と同様に、このドキュメントのコンテキストでは、ポートは、L1VPNごとにCEをPEに接続するために使用される物理リソースのグループ化を表すために使用される論理的なコンストラクトです。
At any point in time, a given port on a PE is associated with at most one L1VPN, or, to be more precise, with at most one Port Information Table maintained by the PE (although different ports on a given PE could be associated with different L1VPNs, or, to be more precise, with different Port Information Tables). The association of a port with a VPN MAY be defined by provisioning the relationship on the service provider devices. In other words, the context of a VPN membership in Basic Mode is enforced through service provider control.
いつでも、PEの特定のポートは最大1つのL1VPNに関連付けられています。または、より正確には、最大で1つのポート情報テーブルがPEによって維持されています（特定のPEの異なるポートは、異なるL1VPN、または、より正確に言うと、異なるポート情報テーブルを使用します）。ポートとVPNの関連付けは、サービスプロバイダーデバイス上の関係をプロビジョニングすることにより定義できます。言い換えれば、基本モードのVPNメンバーシップのコンテキストは、サービスプロバイダーの制御を通じて実施されます。
It is REQUIRED that the interface (that is between the CE and PE and that is used for the purpose of signaling) be capable of initiating/processing GMPLS protocol messages [RFC3473] and of following the procedures described in [RFC4208].
インターフェイス（CEとPEの間で、シグナリングの目的で使用される）は、GMPLSプロトコルメッセージ[RFC3473]を開始/処理し、[RFC4208]に記載されている手順に従うことができます。
An important goal of L1VPN service is the ability to support what is known as "single-ended provisioning", where the addition of a new port to a given L1VPN involves configuration changes only on the PE that has this port. The extension of this model to the CE is outside the scope of the L1VPN BM.
L1VPNサービスの重要な目標は、「シングルエンドプロビジョニング」として知られているものをサポートする機能です。特定のL1VPNに新しいポートを追加するには、このポートがあるPEでのみ構成変更が含まれます。このモデルのCEへの拡張は、L1VPN BMの範囲外です。
Another important goal in the L1VPN service is the ability to establish/terminate an LSP between a pair of (existing) ports within an L1VPN from the CE devices without involving configuration changes in any of the service provider's devices. In other words, the VPN topology is under the CE device control (assuming that the underlying PE-to-PE connectivity is provided and allowed by the network).
L1VPNサービスのもう1つの重要な目標は、サービスプロバイダーのデバイスの構成変更を伴うことなく、CEデバイスからL1VPN内の（既存の）ポートのペア間でLSPを確立/終了する機能です。言い換えれば、VPNトポロジはCEデバイス制御の下にあります（基礎となるPE-PE接続がネットワークによって提供され、許可されていると仮定します）。
The mechanisms outlined in this document aim to achieve the above goals. Specifically, as part of the L1VPN service offering, these mechanisms (1) enable the service provider to restrict the set of ports to which a given port could be connected and (2) enable a CE to establish the actual LSP to a subset of ports. Finally, the mechanisms allow arbitrary L1VPN topologies to be supported; including topologies ranging from hub-and-spoke to full mesh point-to-point connections. Only point-to-point links are supported.
このドキュメントで概説されているメカニズムは、上記の目標を達成することを目的としています。具体的には、L1VPNサービス提供の一部として、これらのメカニズムは（1）サービスプロバイダーが特定のポートを接続できるポートのセットを制限し、（2）CEが実際のLSPをポートのサブセットに確立できるようにすることができます。。最後に、メカニズムにより、任意のL1VPNトポロジをサポートすることができます。ハブアンドスポークからフルメッシュポイントツーポイント接続までのトポロジを含みます。ポイントツーポイントリンクのみがサポートされています。
The exchange of CE routing or topology information to the service provider is out of scope for L1VPN BM mode.
CEルーティングまたはトポロジ情報のサービスプロバイダーとの交換は、L1VPN BMモードの範囲外です。
GMPLS-established conventions for addressing and link numbering are discussed in [RFC3945]. This section builds on those definitions for the L1VPN case where we now have customer and service provider addresses in a Layer 1 context.
アドレス指定とリンク番号のためのGMPLSが確立した規則については、[RFC3945]で説明しています。このセクションでは、レイヤー1コンテキストに顧客とサービスプロバイダーのアドレスが現在あるL1VPNケースのこれらの定義に基づいています。
It is REQUIRED that a service provider, or a group of service providers that collectively offer L1VPN service, have a single addressing realm that spans all PE devices involved in providing the L1VPN service. This is necessary to enable GMPLS mechanisms for path establishment and maintenance. We will refer to this realm as the service provider addressing realm. It is further REQUIRED that each L1VPN customer have its own addressing realm with complete freedom to use private or public addresses. We will refer to such realms as the customer addressing realms. Customer addressing realms MAY overlap addresses (i.e., non-unique address) with each other, and MAY also overlap addresses with the service provider realm.
L1VPNサービスを集合的に提供するサービスプロバイダー、または集合的にL1VPNサービスを提供するサービスプロバイダーのグループが、L1VPNサービスの提供に関与するすべてのPEデバイスにまたがる単一のアドレス指定領域を持つことが必要です。これは、パスの確立とメンテナンスのためにGMPLSメカニズムを有効にするために必要です。この領域を、領域に対処するサービスプロバイダーと呼びます。さらに、各L1VPN顧客は、プライベートまたはパブリックアドレスを使用する完全な自由を備えた独自のアドレス指定領域を持っていることが必要です。そのような領域を顧客に扱う領域のように言及します。顧客アドレス指定レルムは、互いにアドレス（つまり、非ユニークのアドレス）を重複させる可能性があり、サービスプロバイダーの領域とアドレスを重複させることもあります。
Within a given L1VPN, each port on a CE that connects the CE to a PE has an identifier that is unique within that L1VPN (but need not be unique across several L1VPNs). One way to construct such an identifier is to assign each port an address that is unique within a given L1VPN, and use this address as a port identifier. Another way to construct such an identifier is to assign each port on a CE an index that is unique within that CE, assign each CE an address that is unique within a given L1VPN, and then use a tuple <port index, CE address> as a port identifier. Note that both the port and the CE address MAY be an address in several formats. This includes, but is not limited to, IPv4 and IPv6. This identifier is part of the Customer addressing Realm and is used by the CE device to identify the CE port and the CE remote port for signaling. CEs do not know or understand the service provider realm addresses.
特定のL1VPN内で、CEをPEに接続するCEの各ポートには、そのL1VPN内で一意の識別子があります（ただし、いくつかのL1VPNで一意である必要はありません）。このような識別子を構築する1つの方法は、特定のL1VPN内で一意のアドレスを各ポートに割り当て、このアドレスをポート識別子として使用することです。このような識別子を構築する別の方法は、各ポートにそのCE内で一意のインデックスをCEに割り当て、各CEを特定のL1VPN内で一意のアドレスを割り当て、次にTuple <Port Index、CEアドレス>を使用することです。ポート識別子。ポートアドレスとCEアドレスの両方が、いくつかの形式のアドレスである可能性があることに注意してください。これには、IPv4およびIPv6が含まれますが、これらに限定されません。この識別子は、顧客アドレス指定の領域の一部であり、CEデバイスでCEポートとCEリモートポートを信号のために識別するために使用されます。CESは、サービスプロバイダーの領域を知らないか理解していません。
Within a service provider network, each port on a PE that connects that PE to a CE has an identifier that is unique within that network. One way to construct such an identifier is to assign each port on a PE an index that is unique within that PE, assign each PE an IP address that is unique within the service provider addressing realm, and then use a tuple <port index, PE IPv4 address> or <port index, PE IPv6 address> as a port identifier within the service provider network. Another way to construct such an identifier is to assign an IPv4 or IPv6 address that is unique within the service provider addressing realm to each such port. Either way, this IPv4 or IPv6 address is internal to the service provider network and is used for GMPLS signaling within the service provider network.
サービスプロバイダーネットワーク内で、PEをCEに接続するPE上の各ポートには、そのネットワーク内で一意の識別子があります。このような識別子を構築する1つの方法は、各ポートをPEに割り当て、そのPE内で一意のインデックスを割り当て、各PEをサービスプロバイダーにアドレス指定するIPアドレスを割り当て、Tuple <Port Index、PEを使用することです。IPv4アドレス>または<ポートインデックス、PE IPv6アドレス>サービスプロバイダーネットワーク内のポート識別子として。このような識別子を構築する別の方法は、そのようなポートごとに領域をアドレス指定するサービスプロバイダー内で一意のIPv4またはIPv6アドレスを割り当てることです。いずれにせよ、このIPv4またはIPv6アドレスはサービスプロバイダーネットワークの内部であり、サービスプロバイダーネットワーク内のGMPLSシグナリングに使用されます。
As a result, each link connecting the CE to the PE is associated with a CE port that has a unique identifier within a given L1VPN, and with a PE port that has a unique identifier within the service provider network. We'll refer to the former as the Customer Port Identifier (CPI), and to the latter as the Provider Port Identifier (PPI).
その結果、CEをPEに接続する各リンクは、特定のL1VPN内に一意の識別子を備えたCEポートと、サービスプロバイダーネットワーク内に一意の識別子を持つPEポートに関連付けられています。前者を顧客ポート識別子（CPI）と呼び、後者をプロバイダーポート識別子（PPI）と呼びます。
This document requires that each PE port that has a PPI also has an identifier that is unique within the L1VPN customer addressing realm of the L1VPN associated with that port. One way to construct such an identifier is to assign each port an address that is unique within a given L1VPN customer addressing realm, and use this address as a port identifier. Another way to construct such an identifier is to assign each port an index that is unique within a given PE, assign each PE an IP address that is unique within a given L1VPN customer addressing realm (but need not be unique within the service provider network), and then use a tuple <port index, PE IP address> that acts as a port identifier. We'll refer to such port identifier as the VPN-PPI. See Figure 2.
このドキュメントでは、PPIを持つ各PEポートには、そのポートに関連付けられたL1VPNの領域にアドレス指定するL1VPN顧客内で一意の識別子も備えていることが必要です。このような識別子を構築する1つの方法は、各ポートを特定のL1VPN顧客アドレス指定領域内で一意のアドレスを割り当て、このアドレスをポート識別子として使用することです。このような識別子を構築する別の方法は、各ポートを特定のPE内で一意のインデックスを割り当てることです。各PEを特定のL1VPN顧客アドレス指定領域内で一意のIPアドレスを割り当てることです（ただし、サービスプロバイダーネットワーク内で一意である必要はありません）、そして、ポート識別子として機能するtuple <port index、pe ip address>を使用します。そのようなポート識別子をVPN-PPIと呼びます。図2を参照してください。
For L1VPNs, it is a requirement that service provider operations are independent of the VPN customer's addressing realm and the service provider addressing realm is hidden from the customer. To achieve this, we define two identifiers at the PE, one customer facing and the other service provider facing. The PE IP address used for the VPN-PPI is independent of the PE IP address used for the PPI (as the two are taken from different address realms, the former from the customer's addressing realm and the latter from a VPN service provider's addressing realm). If for a given port on a PE, the PPI and the VPN-PPI port identifiers are unnumbered, then they both could use exactly the same port index. This is a mere convenience since the PPI and VPN_PPI can be in any combination of valid formats.
L1VPNの場合、サービスプロバイダーの運用はVPN顧客のアドレス指定領域とは無関係であり、アドレス指定領域が顧客から隠されていることが要件です。これを達成するために、PEで2つの識別子、1つの顧客が向いています。VPN-PPIに使用されるPE IPアドレスは、PPIに使用されるPE IPアドレスとは独立しています（2つは異なるアドレスの領域から取得され、前者は顧客のアドレス指定領域から、後者はVPNサービスプロバイダーのアドレス指定領域から取得されます）。PEの特定のポートに対して、PPIとVPN-PPIポート識別子が数えられていない場合、どちらもまったく同じポートインデックスを使用できます。PPIとVPN_PPIは有効な形式の任意の組み合わせであるため、これは単なる便利さです。
(Customer realm)
+----+ +----+
| |<Port Index> <Port Index> | |
| |CPI VPN-PPI | |
---| CE |-----------------------------| PE |---
| | <Port Index> | |
| | PPI | |
+----+ +----+
(Provider realm)
Figure 2: Customer/Provider Port/Index Mapping
図2：顧客/プロバイダーポート/インデックスマッピング
Note, as stated earlier, that IP addresses used for the CPIs, PPIs, and VPN-PPIs could be either IPv4 or IPv6 format addresses.
前述のように、CPI、PPI、およびVPN-PPIに使用されるIPアドレスは、IPv4またはIPv6形式のアドレスのいずれかである可能性があることに注意してください。
For a given link connecting a CE to a PE:
CEをPEに接続する特定のリンクの場合：
- If the CPI is an IPv4 address, then the VPN-PPI MUST be an IPv4 address as well since VPN-PPIs are created from the customer address space. If the CPI is a <port index, CPI IPv4 address> tuple, then the VPN-PPI MUST be a <port index, PE IPv4 address> tuple for the same reason.
- CPIがIPv4アドレスの場合、VPN-PPIは顧客アドレススペースから作成されるため、VPN-PPIもIPv4アドレスである必要があります。CPIが<ポートインデックス、CPI IPv4アドレス>タプルの場合、VPN-PPIは同じ理由で<ポートインデックス、PE IPv4アドレス>タプルでなければなりません。
- If the CPI is an IPv6 address, then the VPN-PPI MUST be an IPv6 address as well since VPN-PPIs are created from the customer address space. If the CPI is a <port index, CPI IPv6 address> tuple, then the VPN-PPI MUST be a <port index, PE IPv6 address> tuple for the same reason.
- CPIがIPv6アドレスの場合、VPN-PPIは顧客アドレススペースから作成されるため、VPN-PPIもIPv6アドレスである必要があります。CPIが<ポートインデックス、CPI IPv6アドレス>タプルの場合、VPN-PPIは同じ理由で<ポートインデックス、PE IPv6アドレス>タプルでなければなりません。
Note: for a given port on the PE, whether the VPN-PPI of that port is an IP address or a <port index, PE IP address> is independent of the format of the PPI of that port.
注：PEの特定のポートについては、そのポートのVPN-PPIがIPアドレスであるか<ポートインデックスであるかどうか、PE IPアドレス>はそのポートのPPIの形式とは無関係です。
This document assumes that assignment of the PPIs is controlled solely by the service provider (without any coordination with the L1VPN customers), while assignment of addresses used by the CPIs and VPN-PPIs is controlled solely by the administrators of L1VPN. This provides maximum flexibility. The L1VPN administrator is the entity that controls the L1VPN service specifics for the L1VPN customers. This function may be owned by the service provider but may also be performed by a third party who has agreements with the service provider. And, of course, each L1VPN customer could assign such addresses on its own, without any coordination with other L1VPNs.
このドキュメントは、PPIの割り当てはサービスプロバイダーのみによって制御されることを前提としています（L1VPN顧客との調整なし）、CPIおよびVPN-PPIが使用するアドレスの割り当てはL1VPNの管理者のみによって制御されます。これにより、最大の柔軟性が得られます。L1VPN管理者は、L1VPN顧客向けのL1VPNサービスの詳細を制御するエンティティです。この機能はサービスプロバイダーが所有する場合がありますが、サービスプロバイダーと契約を結ぶ第三者によっても実行される場合があります。そして、もちろん、各L1VPNの顧客は、他のL1VPNと調整することなく、そのようなアドレスを単独で割り当てることができます。
This document also requires IP connectivity between the CE and the PE as specified earlier, which is used for the control channel between CE and PE. This connectivity could be either a single IP hop, which could be realized by either a dedicated link or by an L2 VPN, or an IP private network, such as an L3VPN. The only requirement on this connectivity is an unambiguous way to correlate a particular CE-to-PE control channel with a particular L1VPN. When such a channel is realized by a dedicated link, such a link should be associated with a particular L1VPN. When such channel is realized by an L2VPN, a distinct L2VPN should be associated with an L1VPN. When such channel is realized by an L3VPN, a distinct L3VPN should be associated with an L1VPN.
このドキュメントには、CEとPEの間のCEとPEの間のIP接続性も必要であり、CEとPEの間の制御チャネルに使用されます。この接続性は、単一のIPホップであり、専用のリンクまたはL2 VPN、またはL3VPNなどのIPプライベートネットワークによって実現できます。この接続の唯一の要件は、特定のCE-PE対照チャネルを特定のL1VPNと相関させる明確な方法です。このようなチャネルが専用のリンクによって実現される場合、そのようなリンクは特定のL1VPNに関連付けられる必要があります。このようなチャネルがL2VPNによって実現される場合、異なるL2VPNはL1VPNに関連付けられる必要があります。そのようなチャネルがL3VPNによって実現される場合、異なるL3VPNはL1VPNに関連付けられる必要があります。
We'll refer to the CE's address of this channel as the CE Control Channel Address (CE-CC-Addr), and to the PE's address of this channel as the PE Control Channel Address (PE-CC-Addr). Both CE-CC-Addr and PE-CC-Addr are REQUIRED to be unique within the L1VPN they belong to, but are not REQUIRED to be unique across multiple L1VPNs. Control channel addresses are not shared amongst multiple VPNs. Assignment of CE-CC-Addr and PE-CC-Addr is controlled by the administrators of the L1VPN.
このチャネルのCEのアドレスをCEコントロールチャネルアドレス（CE-CC-ADDR）と呼び、このチャネルのPEのアドレスをPEコントロールチャネルアドレス（PE-CC-ADDR）と呼びます。CE-CC-ADDRとPE-CC-ADDRの両方は、それらが属するL1VPN内で一意である必要がありますが、複数のL1VPNで一意である必要はありません。制御チャネルアドレスは、複数のVPN間で共有されません。CE-CC-ADDRおよびPE-CC-ADDRの割り当ては、L1VPNの管理者によって制御されます。
Multiple ports on a CE could share the same control channel only as long as all these ports belong to the same L1VPN. Likewise, multiple ports on a PE could share the same control channel only as long as all these ports belong to the same L1VPN.
CEの複数のポートは、これらすべてのポートが同じL1VPNに属している限り、同じ制御チャネルを共有できます。同様に、PEの複数のポートは、これらすべてのポートが同じL1VPNに属している限り、同じ制御チャネルを共有できます。
An L1VPN is a port-based VPN service where a pair of CEs could be connected through the service provider network via a GMPLS-based LSP within a given VPN port topology. It is precisely this LSP that forms the basic unit of the L1VPN service that the service provider network offers. If a port by which a CE is connected to a PE consists of multiple channels (e.g., multiple wavelengths), the CE could establish LSPs to multiple other CEs in the same VPN over this single port.
L1VPNは、特定のVPNポートトポロジ内のGMPLSベースのLSPを介して、サービスプロバイダーネットワークを介してCESのペアを接続できるポートベースのVPNサービスです。サービスプロバイダーネットワークが提供するL1VPNサービスの基本ユニットを形成するのは、まさにこのLSPです。CEがPEに接続されているポートが複数のチャネル（たとえば、複数の波長）で構成されている場合、CEはこの単一ポート上の同じVPNの複数のCESにLSPを確立できます。
In the L1VPN, the service provider does not initiate the creation of an LSP between a pair of CE ports. The LSP establishment is initiated by the CE. However, the SP, by using the mechanisms/toolkit outlined in this document, restricts the set of other CE ports, which may be the remote endpoints of LSPs that have the given port as the local endpoint. Subject to these restrictions, the CE-to-CE connectivity is under the control of the CEs themselves. In other words, the SP allows a L1VPN to have a certain set of topologies (expressed as a port-to-port connectivity matrix). CE-initiated signaling is used to choose a particular topology from that set.
L1VPNでは、サービスプロバイダーは、CEポートのペア間のLSPの作成を開始しません。LSP施設はCEによって開始されます。ただし、SPは、このドキュメントで概説されているメカニズム/ツールキットを使用することにより、特定のポートをローカルエンドポイントとして持つLSPのリモートエンドポイントである可能性のある他のCEポートのセットを制限します。これらの制限に従い、CEからCEへの接続性はCES自体の制御下にあります。言い換えれば、SPはL1VPNが特定の一連のトポロジ（ポート間接続マトリックスとして表される）を持つことができます。CEが挿入したシグナル伝達は、そのセットから特定のトポロジを選択するために使用されます。
For each L1VPN that has at least one port on a given PE, the PE maintains a Port Information Table (PIT) associated with that L1VPN. This table contains a list of <CPI, PPI> tuples for all the ports within its L1VPN. In addition, for local PE ports of a given L1VPN, the tuples also include the VPN-PPIs of these ports.
特定のPEに少なくとも1つのポートがある各L1VPNについて、PEはそのL1VPNに関連付けられたポート情報テーブル（PIT）を維持します。このテーブルには、L1VPN内のすべてのポートの<CPI、PPI> TULPLEのリストが含まれています。さらに、特定のL1VPNのローカルPEポートの場合、タプルにはこれらのポートのVPN-PPIも含まれます。
PE PE
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || Route | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+|Dissemination| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| 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 3: Basic Mode L1VPN Service
図3：基本モードL1VPNサービス
Figure 3 illustrates three VPNs, VPN-A, VPN-B, and VPN-C, with their associated PITs. A PIT consists of local information as well as remote information. It follows that a PIT on a given PE is populated from two information sources:
図3は、関連するピットを備えた3つのVPN、VPN-A、VPN-B、およびVPN-Cを示しています。ピットは、ローカル情報とリモート情報で構成されています。与えられたPEのピットは、2つの情報ソースから入力されます。
1. The information related to the CEs' ports that are attached to the ports local to that PE.
1. そのPEにローカルなポートに接続されているCESのポートに関連する情報。
2. The information about the CEs connected to the remote PEs.
2. リモートPEに接続されたCESに関する情報。
A PIT MAY be populated via provisioning or by auto-discovery procedures. When provisioning is used, the entire table MAY be populated by provisioning commands either at a console or by a management system that may have some automation capability. As the network grows, some form of automation is desirable.
PITは、プロビジョニングまたは自動発見手順により入力される場合があります。プロビジョニングを使用すると、テーブル全体が、コンソールまたは自動化機能を備えた管理システムのいずれかでコマンドをプロビジョニングすることで入力できます。ネットワークが成長するにつれて、何らかの形の自動化が望ましい。
For local information between a CE and a PE, a PE MAY leverage LMP to populate the <CPI, VPN-PPI> link information. This local information also needs to be propagated to other PEs that share the same VPN. The mechanisms for this are out of scope for this document, but the information needed to be exchanged is described in Section 4.1.1.
CEとPEの間のローカル情報の場合、PEはLMPを活用して<CPI、VPN-PPI>リンク情報を入力する場合があります。また、このローカル情報は、同じVPNを共有する他のPESに伝播する必要があります。これのメカニズムはこのドキュメントの範囲外ですが、交換する必要がある情報はセクション4.1.1で説明されています。
The PIT is by nature VPN-specific. A PE is REQUIRED to maintain a PIT for each L1VPN for which it has member CEs locally attached. A PE does not need to maintain PITs for other L1VPNs. However, the full set of PITs with all L1VPN entries for multiple VPNs MAY also be available to all PEs.
ピットは本質的にVPN固有です。PEは、メンバーCESがローカルに接続されている各L1VPNのピットを維持するために必要です。PEは、他のL1VPNのピットを維持する必要はありません。ただし、複数のVPNのすべてのL1VPNエントリを備えたピットの完全なセットも、すべてのPEで利用できる場合があります。
The remote information in the context of a VPN identifier (i.e., the remote CEs of this VPN) MAY also be sent to the local CE belonging to the same VPN. Exchange of this information is outside the scope of this document.
VPN識別子のコンテキスト（つまり、このVPNのリモートCE）のコンテキストでのリモート情報も、同じVPNに属するローカルCEに送信できます。この情報の交換は、このドキュメントの範囲外です。
The information that needs to be discovered on a PE local port is the local CPI and the VPN-PPI.
PEローカルポートで発見する必要がある情報は、ローカルCPIとVPN-PPIです。
This information MAY be configured; or, if LMP is used between the CE and PE, LMP MAY be used to exchange this information.
この情報は構成される場合があります。または、CEとPEの間でLMPを使用する場合、LMPを使用してこの情報を交換することができます。
Once a CPI has been discovered, the corresponding VPN-PPI maps in a local context to a VPN identifier and a corresponding PPI. One way to enforce a provider-controlled VPN context is to pre-provision VPN-PPIs with a VPN identifier. Other policy mechanisms to achieve this are outside the scope of this document. In this manner, a relationship of a CPI to a VPN and PPI port can be established when the port is provisioned as belonging to the VPN.
CPIが発見されると、対応するVPN-PPIは、VPN識別子と対応するPPIに対してローカルコンテキストでマップします。プロバイダー制御されたVPNコンテキストを実施する1つの方法は、VPN識別子を使用してVPN-PPIを事前に進化させることです。これを達成する他のポリシーメカニズムは、このドキュメントの範囲外です。このようにして、ポートがVPNに属するものとしてプロビジョニングされている場合、CPIとVPNおよびPPIポートとPPIポートの関係を確立できます。
This section provides the information that is carried by any auto-discovery mechanism, and is used to dynamically populate a PIT. The information provides a single <CPI, PPI> mapping. Each auto-discovery mechanism will define the method(s) by which multiple <CPI, PPI> mappings are communicated, as well as invalidated.
このセクションでは、自動発見メカニズムによって実行される情報を提供し、ピットを動的に埋めるために使用されます。情報は、単一の<CPI、PPI>マッピングを提供します。各自動発見メカニズムは、複数の<CPI、PPI>マッピングが通信され、無効化される方法を定義します。
This information should be consistent regardless of the mechanism used to distribute the information [RFC5195], [RFC5252].
この情報は、情報[RFC5195]、[RFC5252]の配布に使用されるメカニズムに関係なく、一貫している必要があります。
The format of encoding a single <PPI, CPI> tuple is:
単一の<ppi、cpi> tupleをエンコードする形式は次のとおりです。
+---------------------------------------+
| PPI Length (1 octet) |
+---------------------------------------+
| PPI (variable) |
+---------------------------------------+
| CPI AFI (2 octets) |
+---------------------------------------+
| CPI (length) |
+---------------------------------------+
| CPI (variable) |
+---------------------------------------+
Figure 4: Auto-Discovery Information
図4：自動発見情報
The use and meaning of these fields are as follows:
これらのフィールドの使用と意味は次のとおりです。
PPI Length:
PPIの長さ：
A one-octet field whose value indicates the length of the PPI field.
値がPPIフィールドの長さを示す1オクセットフィールド。
PPI:
PPI：
A variable-length field that contains the value of the PPI (either an address or <port index, address> tuple). Note, PPI is always encoded consistently within a provider domain so the format of the PPI field is implicit within a given provider network.
PPIの値を含む可変長フィールド（アドレスまたは<ポートインデックス、アドレス>タプル）。注、PPIは常にプロバイダードメイン内で一貫してエンコードされるため、PPIフィールドの形式は特定のプロバイダーネットワーク内で暗黙的です。
CPI AFI:
CPI AFI：
A two-octet field whose value indicates the address family of the CPI. This value is taken from [RFC1700].
CPIの住所ファミリを示す値の2オクセットフィールド。この値は[RFC1700]から取得されます。
CPI Length:
CPIの長さ：
A one-octet field whose value indicates the length of the CPI field.
値がCPIフィールドの長さを示す1オクセットフィールド。
CPI:
CPI：
A variable-length field that contains the CPI value (either an address or <port index, address> tuple).
CPI値（アドレスまたは<ポートインデックス、アドレス>タプルのいずれか）を含む可変長いフィールド。
<PPI, CPI> tuples MUST also be associated with one or more globally unique identifiers associated with a particular VPN. A globally unique identifier can encode a VPN-ID, a route target, or any other globally unique identifier. The globally unique identifiers are under control of network providers. Uniqueness within a service provider administrative domain is sufficient for Basic Mode operation. In the case of multiple provider networks (which is beyond the scope of this document), the globally unique identifier need only be unique and consistent between the those providers. In this document, we specify a generic encoding format for the globally unique identifier common to all the auto-discovery mechanisms. However, each auto-discovery mechanism will define the specific method(s) by which the encoding is distributed and the association with a <PPI, CPI> tuple is made. The encoding of the globally unique identifier associated with the VPN is:
<ppi、cpi>タプルは、特定のVPNに関連付けられた1つ以上のグローバルに一意の識別子にも関連付けられている必要があります。グローバルに一意の識別子は、VPN-ID、ルートターゲット、またはその他のグローバルに一意の識別子をエンコードできます。グローバルに一意の識別子は、ネットワークプロバイダーの管理下にあります。サービスプロバイダー管理ドメイン内の一意性は、基本モードの操作に十分です。複数のプロバイダーネットワーク（このドキュメントの範囲を超えている）の場合、グローバルに一意の識別子は、これらのプロバイダー間で一意して一貫性がある必要があります。このドキュメントでは、すべての自動配置メカニズムに共通するグローバルに一意の識別子の一般的なエンコード形式を指定します。ただし、各自動発見メカニズムは、エンコーディングが分布する特定の方法を定義し、<PPI、cpi> tupleとの関連を定義します。VPNに関連付けられたグローバルに一意の識別子のエンコードは次のとおりです。
+------------------------------------------------+
| L1VPN globally unique identifier (8 octets) |
+------------------------------------------------+
Figure 5: Auto-Discovery Globally Unique Identifier Format
図5：グローバルに一意の識別子形式の自動配分
In order to establish an LSP, a CE needs to identify all other CEs in the CE's L1VPN that it wants to connect to. A CE may already have obtained this information through provisioning or through some other schemes (such schemes are outside the scope of this document).
LSPを確立するには、CEは、接続したいCEのL1VPNの他のすべてのCEを特定する必要があります。CEは、プロビジョニングまたは他のいくつかのスキームを通じてすでにこの情報を取得している可能性があります（このようなスキームは、このドキュメントの範囲外です）。
Ports associated with a given CE-to-PE link MAY also have other information, in addition to their CPI and PPI, associated with them that describes characteristics and constraints of the channels within these ports, such as encoding supported by the channels, bandwidth of a channel, total unreserved bandwidth within the port, etc. This information could be further augmented with the information about certain capabilities of the service provider network (e.g., support regeneration section overhead (RSOH), Data Communications Channel (DCC) transparency, arbitrary concatenation, etc.). This information is used to ensure that ports at each end of an LSP have compatible characteristics, and that there are sufficient unallocated resources to establish an LSP between these ports.
特定のCE-PEリンクに関連付けられたポートには、CPIとPPIに加えて、これらのポート内のチャネルの特性と制約を説明する他の情報も含まれている場合があります。この情報は、サービスプロバイダーネットワークの特定の機能に関する情報をさらに強化することができます（例：サポート再生セクションオーバーヘッド（RSOH）、データ通信チャネル（DCC）透明性、任意の連結性、任意の連結、など）。この情報は、LSPの両端にあるポートが互換性のある特性を持ち、これらのポート間にLSPを確立するのに十分な未割り当てリソースがあることを保証するために使用されます。
It may happen that for a given pair of ports within an L1VPN, each of the CEs connected to these ports would concurrently try to establish an LSP to the other CE. If having a pair of LSPs between a pair of ports is viewed as undesirable, the way to resolve this is to require the CE with the lower value of the CPI to terminate the LSP originated by the CE. This option could be controlled by configuration on the CE devices.
L1VPN内の特定のポートのペアについて、これらのポートに接続されている各CESが同時にLSPを他のCEに確立しようとすることがあります。ポートのペア間にLSPのペアを持っていることが望ましくないと見なされる場合、これを解決する方法は、CEがCEによって発生するLSPを終了するためにCPIの値が低いことをCEに要求することです。このオプションは、CEデバイスの構成によって制御できます。
In L1VPN BM, a CE needs to be configured with the CPIs of other ports. Once a CE is configured with the CPIs of the other ports within the same L1VPN, which we'll refer to as "target ports", the CE uses a subset of GMPLS signaling to request the provider network to establish an LSP to a target port.
L1VPN BMでは、CEを他のポートのCPIで構成する必要があります。CEが同じL1VPN内の他のポートのCPIで構成されたら、これを「ターゲットポート」と呼びます。CEはGMPLSシグナリングのサブセットを使用してプロバイダーネットワークを要求してターゲットポートにLSPを確立します。
For inter-CE connectivity, the CE originates a request that contains the CPI of one of its ports that it wants to use for the LSP, and the CPI of the target port. When the PE attached to the CE that originated the request receives the request, the PE identifies the appropriate PIT, and then uses the information in that PIT to find out the PPI associated with the CPI of the target port carried in the request. The PPI should be sufficient for the PE to establish an LSP. Ultimately, the request reaches the CE associated with the target CPI (note that the request still carries the CPI of the CE that originated the request). If the CE associated with the target CPI accepts the request, the LSP is established.
Inter-CE接続の場合、CEは、LSPに使用したいポートの1つのCPIと、ターゲットポートのCPIを含むリクエストを発信します。リクエストを開始したCEに添付されたPEがリクエストを受信すると、PEは適切なピットを識別し、そのピットの情報を使用して、リクエストに掲載されたターゲットポートのCPIに関連付けられたPPIを見つけます。PPIがLSPを確立するには、PPIで十分でなければなりません。最終的に、リクエストはターゲットCPIに関連付けられたCEに到達します（リクエストには、リクエストを発信したCEのCPIがまだ運ばれていることに注意してください）。ターゲットCPIに関連付けられたCEがリクエストを受け入れると、LSPが確立されます。
Note that a CE needs not establish an LSP to every target port that the CE knows about, i.e., it is a local CE policy matter to select a subset of target ports to which that CE will try to establish LSPs.
CEは、CEが知っているすべてのターゲットポートにLSPを確立する必要はないことに注意してください。つまり、CEがLSPを確立しようとするターゲットポートのサブセットを選択するのはローカルCEポリシーの問題です。
The procedures for establishing an individual connection between two corresponding CEs is the same as the procedure specified for GMPLS overlay [RFC4208].
対応する2つのCE間で個別の接続を確立する手順は、GMPLSオーバーレイ[RFC4208]に指定された手順と同じです。
When an ingress CE sends an RSVP Path message to an ingress PE, the source IP address in the IP packet that carries the message is set to the appropriate CE-CC-Addr, and the destination IP address in the packet is set to the appropriate PE-CC-Addr. When the ingress PE sends back to the ingress CE the corresponding Resv message, the source IP address in the IP packet that carries the message is set to the PE-CC-Addr, and the destination IP address is set to the CE-CC-Addr.
Ingress CEがRSVPパスメッセージをIngress PEに送信すると、メッセージを運ぶIPパケットのソースIPアドレスが適切なCE-CC-ADDRに設定され、パケット内の宛先IPアドレスが適切に設定されていますPE-CC-ADDR。Ingress PEがIngress CEに対応するRESVメッセージを送り返すと、メッセージを運ぶIPパケット内のソースIPアドレスがPE-CC-ADDRに設定され、宛先IPアドレスがCE-CC-onに設定されます。addr。
Likewise, when an egress PE sends an RSVP Path message to an egress CE, the source IP address in the IP packet that carries the message is set to the appropriate PE-CC-Addr, and the destination IP address in the packet is set to the appropriate CE-CC-Addr. When the egress CE sends back to the egress PE the corresponding Resv message, the source IP address in the IP packet that carries the message is set to the CE-CC-Addr, and the destination IP address is set to the PE-CC-Addr.
同様に、出力PEがRSVPパスメッセージを出力CEに送信すると、メッセージを運ぶIPパケットのソースIPアドレスが適切なPE-CC-ADDRに設定され、パケット内の宛先IPアドレスはに設定されています。適切なCE-CC-ADDR。出力CEが対応するRESVメッセージを出力PEに送り返すと、メッセージを運ぶIPパケットのソースIPアドレスがCE-CC-ADDRに設定され、宛先IPアドレスがPE-CC-CC-に設定されます。addr。
In addition to being used for IP addresses in the IP packet that carries RSVP messages between CE and PE, CE-CC-Addr and PE-CC-Addr are also used in the Next/Previous Hop Address field of the IF_ID RSVP_Hop Object that is carried between CEs and PEs.
CEとPEの間にRSVPメッセージを掲載するIPパケットのIPアドレスに使用されることに加えて、CE-CC-ADDRとPE-CC-ADDRは、if_id rsvp_hopオブジェクトの次の/前のホップアドレスフィールドでも使用されます。CEとPESの間に運ばれます。
In the case where a link between CE and PE is a numbered non-bundled link, the CPI and VPN-PPI of that link are used for the Type 1 or 2 TLVs of the IF_ID RSVP_Hop Object that is carried between the CE and PE. In the case where a link between CE and PE is an unnumbered non-bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLV. In the case where a link between CE and PE is a bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLVs.
CEとPEの間のリンクが番号付きの非バンドルリンクである場合、そのリンクのCPIとVPN-PPIは、CEとPEの間に運ばれるIF_ID RSVP_HOPオブジェクトのタイプ1または2 TLVに使用されます。CEとPEの間のリンクが非仮定されていない非バンドルリンクである場合、そのリンクのCPIとVPN-PPIは、タイプ3 TLVのIPアドレスフィールドに使用されます。CEとPEのリンクがバンドルリンクである場合、そのリンクのCPIとVPN-PPIは、タイプ3 TLVのIPアドレスフィールドに使用されます。
Additional processing related to unnumbered links is described in Sections 3 ("Processing the IF_ID RSVP_HOP object") and 4.1 ("Unnumbered Forwarding Adjacencies") of RFC 3477 [RFC3477].
リンクのないリンクに関連する追加の処理は、セクション3（「if_id rsvp_hopオブジェクトの処理」）およびRFC 3477 [RFC3477]の4.1（「非仮定されていない転送隣接」）で説明されています。
When an ingress CE originates a Path message to establish an LSP from a particular port on that CE to a particular target port, the CE uses the CPI of its port in the Sender Template object. If the CPI of the target port is an IP address, then the CE uses it in the Session object. And if the CPI of the target port is a <port index, IP address> tuple, then the CE uses the IP address part of the tuple in the Session object, and the whole tuple as the Unnumbered Interface ID subobject in the Explicit Route Object (ERO).
Ingress CEがパスメッセージを発信して、そのCEの特定のポートから特定のターゲットポートにLSPを確立する場合、CEは送信者テンプレートオブジェクトでポートのCPIを使用します。ターゲットポートのCPIがIPアドレスである場合、CEはセッションオブジェクトでそれを使用します。また、ターゲットポートのCPIが<ポートインデックス、IPアドレス>タプルの場合、CEはセッションオブジェクトのタプルのIPアドレス部分を使用し、タプル全体を明示的なルートオブジェクトの非仮定インターフェイスIDサブオブジェクトとして使用します。（ERO）。
There are two options for RSVP-TE sessions. One option is to have a single RSVP-TE session end to end where the addresses of the customer and the provider are swapped at the PE; this is termed shuffling. The other option is when stitching or hierarchy is used to create two LSP sessions, one between the provider PE(s) and another end-to-end session between the CEs.
RSVP-TEセッションには2つのオプションがあります。1つのオプションは、顧客とプロバイダーのアドレスがPEに交換される単一のRSVP-TEセッションの終了から終了することです。これはシャッフルと呼ばれます。もう1つのオプションは、ステッチまたは階層を使用して2つのLSPセッションを作成する場合です。1つはプロバイダーPEとCES間のもう1つのエンドツーエンドセッションの間です。
Shuffling sessions are used when the desire is to have a single LSP originating at the CE and terminating at the far end CE. The customer addresses are shuffled to provider addresses at the ingress PE, and back to customer addresses at the egress PE by using the mapping provided by the PIT.
Shufflingセッションは、CEで1つのLSPを発信し、遠端CEで終了することを望んでいる場合に使用されます。顧客アドレスは、イングレスPEのプロバイダーアドレスにシャッフルされ、ピットが提供するマッピングを使用して、出力PEの顧客アドレスに戻ります。
When the Path message arrives at the ingress PE, the PE selects the PIT associated with the L1VPN, and then uses this PIT to map CPIs carried in the Session and the Sender Template objects to the appropriate PPIs. Once the mapping is done, the ingress PE replaces CPIs with these PPIs. As a result, the Session and the Sender Template objects that are carried in the GMPLS signaling within the service provider network carry PPIs, and not CPIs.
パスメッセージが侵入PEに到着すると、PEはL1VPNに関連付けられたピットを選択し、このピットを使用してセッションに掲載されたCPIと送信者テンプレートオブジェクトを適切なPPIにマップします。マッピングが完了すると、Ingress PEはCPIをこれらのPPIに置き換えます。その結果、Service Providerネットワーク内のGMPLSシグナル伝達に携帯されているセッションおよび送信者テンプレートオブジェクトは、CPIではなくPPIを運びます。
At the egress PE, the reverse mapping operation is performed. The PE extracts the ingress/egress PPI values carried in the Sender Template and Session objects (respectively). The egress PE identifies the appropriate PIT to find the appropriate CPI associated with the PPI of the egress CE. Once the mapping is retrieved, the egress PE replaces the ingress/egress PPI values with the corresponding CPI values. As a result, the Session and the Sender Template objects (included in the GMPLS RSVP-TE Path message sent from the egress PE to the egress CE) carry CPIs, and not PPIs.
出力PEでは、逆マッピング操作が実行されます。PEは、送信者テンプレートとセッションオブジェクトに掲載された侵入/出口PPI値を（それぞれ）抽出します。出口PEは、出力CEのPPIに関連する適切なCPIを見つけるための適切なピットを識別します。マッピングが取得されると、出口PEは、侵入/出口PPI値を対応するCPI値に置き換えます。その結果、セッションと送信者のテンプレートオブジェクト（GMPLS RSVP-TEパスメッセージにEgress PEからEgress CEに送信されたメッセージに含まれる）は、PPIではなくCPIを運びます。
Here also, for the GMPLS RSVP-TE Path messages sent from the egress PE to CE, the source IP address (of the IP packet carrying this message) is set to the appropriate PE-CC-Addr, and the destination IP address (of the IP packet carrying this message) is set to the appropriate CE-CC-Addr.
ここでも、gmpls rsvp-teパスメッセージから出力PEからCEに送信される場合、（このメッセージを伝えるIPパケットの）ソースIPアドレスが適切なPE-CC-ADDRに設定され、宛先IPアドレス（の宛先IPアドレス）が設定されます。このメッセージを伝えるIPパケット）は、適切なCE-CC-ADDRに設定されています。
At this point, the CE's view is a single LSP that is point-to-point between the two CEs with a virtual link between the PE nodes: CE-PE(-)PE-CE. The L1VPN PE nodes have a view of the PE-to-PE LSP segment in all its detail. The PEs MAY filter the RSVP-TE signaling, i.e., remove information about the provider topology and replace it with a view of a virtual link.
この時点で、CEのビューは、2つのCES間のポイントツーポイントである単一のLSPです。PEノード間の仮想リンク：CE-PE（ - ）PE-CE。L1VPN PEノードには、PE-PE LSPセグメントのすべての詳細が表示されます。PESは、RSVP-TEシグナル伝達をフィルタリングする場合があります。つまり、プロバイダートポロジに関する情報を削除し、仮想リンクのビューに置き換えます。
This translation of addresses and session IDs is termed shuffling and is driven by the L1VPN Port Information Tables (see Section 4). This MUST be performed for all RSVP-TE messages at the PE edges. In this case, there is one CE-to-CE session.
アドレスとセッションIDのこの翻訳はシャッフルと呼ばれ、L1VPNポート情報表によって駆動されます（セクション4を参照）。これは、PEエッジのすべてのRSVP-TEメッセージに対して実行する必要があります。この場合、CE-CEからCEからCEからCEから1つのセッションがあります。
Stitching or Nesting options are dependent on the LSP switching types. If the CE-to-CE and PE-to-PE LSPs are identical in switching type and capacity, the LSP MAY be stitched together and the procedures in [RFC5150] apply. If the CE-to-CE LSPs and the PE-to-PE LSPs are of not the same switching type, or are of different but compatible capacity, the LSPs MAY be Nested and the procedures for [RFC4206] apply. As both Stitched and Nested LSP signaling procedures involve a PE-to-PE session establishment compatible with CE session parameters, they are described together.
ステッチまたはネストオプションは、LSPスイッチングタイプに依存します。CE-to-CEおよびPE-To-PE LSPがスイッチングタイプと容量で同一である場合、LSPは一緒に縫い合わせて、[RFC5150]の手順が適用される場合があります。CE-to-CE LSPとPE-toPE LSPが同じスイッチングタイプではない場合、または異なるが互換性のある容量である場合、LSPはネストされ、[RFC4206]の手順が適用されます。ステッチとネストされたLSPシグナル伝達手順の両方に、CEセッションパラメーターと互換性のあるPE-To-PEセッション確立が含まれるため、それらについては一緒に説明されています。
When the Path Message arrives at the ingress PE, the PE selects the PIT associated with the L1VPN, and then uses this PIT to map CPIs carried in the Session and the Sender Template objects to the appropriate PPIs. Once the mapping is done, a new PE-to-PE session is established with the parameters compatible with the CE session. Upon successful establishment of the PE-to-PE session, the CE signaling request is sent to the egress PE.
パスメッセージが侵入PEに到着すると、PEはL1VPNに関連付けられたピットを選択し、このピットを使用してセッションに掲載されたCPIと送信者テンプレートオブジェクトを適切なPPIにマップします。マッピングが完了すると、CEセッションと互換性のあるパラメーターを使用して、新しいPE-ToPEセッションが確立されます。PE-To-PEセッションを確立すると、CEシグナリング要求が出口PEに送信されます。
At the ingress PE, when stitching and nesting are used, a PE-to-PE session is established. This could be achieved by several means:
イングレスPEでは、ステッチとネストが使用されると、PE-PEセッションが確立されます。これはいくつかの手段で達成できます。
- Associating an already established PE-to-PE LSP or Forwarding Adjacency LSP (FA-LSP) to the destination that meets the requested parameters.
- すでに確立されたPE-To-PE LSPを関連付けるか、要求されたパラメーターを満たす宛先に隣接するLSP（FA-LSP）を転送します。
- Establishing a compliant PE-to-PE LSP segment.
- 準拠したPE-To-PE LSPセグメントの確立。
At this point, the CE's view is a single LSP that is point-to-point between the two CEs with a virtual node between the PE nodes: CE-PE(-)PE-CE. The L1VPN PE nodes have a view of the PE-to-PE LSP segment in all its detail. The PEs do not have to filter the RSVP-TE signaling by removing information about the provider topology because the PE-to-PE signaling is not visible to the CE nodes.
この時点で、CEのビューは、PEノードの間に仮想ノードを持つ2つのCEの間のポイントツーポイントである単一のLSPです：Ce-Pe（ - ）Pe-CE。L1VPN PEノードには、PE-PE LSPセグメントのすべての詳細が表示されます。PE-PEシグナル伝達がCEノードに表示されないため、PESはプロバイダートポロジに関する情報を削除してRSVP-TEシグナル伝達をフィルタリングする必要はありません。
An ingress PE may receive and potentially reject a Path message that contains an Explicit Route Object and so cause the switched connection setup to fail. However, the ingress PE may accept EROs, which include a sequence of {<ingress PE (strict), egress CE CPI (loose)>}.
Ingress PEは、明示的なルートオブジェクトを含むパスメッセージを受信し、潜在的に拒否する可能性があるため、スイッチされた接続セットアップが失敗します。ただし、イングレスPEは、{<ingress pe（strict）、girs ce cpi（loose）>}のシーケンスを含むerosを受け入れる場合があります。
- Path message without ERO: when an ingress PE receives a Path message from an ingress CE that contains no ERO, it MUST calculate a route to the destination for the PE-to-PE LSP and include that route in an ERO, before forwarding the Path message. One exception would be if the egress core node were also adjacent to this core node.
- EROなしのパスメッセージ：Ingress PEがEROを含むIngress CEからパスメッセージを受信した場合、パスを転送する前に、PE-To-PE LSPの宛先へのルートを計算し、EROにそのルートを含める必要があります。メッセージ。1つの例外は、出力コアノードもこのコアノードに隣接していた場合です。
- Path message with ERO: when an ingress PE receives a Path message from an ingress CE that contains an ERO (of the form detailed above), the former computes a path to reach the egress PE. It then inserts this path as part of the ERO before forwarding the Path message.
- EROのパスメッセージ：侵入PEが（上記のフォームの）EROを含むIngress CEからパスメッセージを受信すると、前者は出口PEに到達するパスを計算します。次に、パスメッセージを転送する前に、EROの一部としてこのパスを挿入します。
In the case of shuffling, the overlay rules for notification and RRO processing are identical to the User-Network Intercase (UNI) or Overlay Model [RFC4208], which state that Edge PE MAY remove/edit Provider Notification and RRO objects when passing the messages to the CEs.
シャッフルの場合、通知とRRO処理のオーバーレイルールは、ユーザーネットワークインターケース（UNI）またはオーバーレイモデル[RFC4208]と同じです。CESに。
Signaling:
シグナリング：
A CE requests a network-protected LSP (i.e., an LSP that is protected from PE-to-PE) by using the technique described in [RFC4873]. Dynamic identification of merge nodes is supported via the LSP Segment Recovery Flags carried in the Protection object (see Section 6.2 of [RFC4873]).
CEは、[RFC4873]で説明されている手法を使用して、ネットワークで保護されたLSP（つまり、PE-To-PEから保護されているLSP）を要求します。マージノードの動的識別は、保護オブジェクトに掲載されたLSPセグメントリカバリフラグを介してサポートされます（[RFC4873]のセクション6.2を参照）。
Notification:
通知：
A Notify Request object MAY be inserted in Path or Resv messages to indicate the address of a CE that should be notified of an LSP failure. Notifications MAY be requested in both the upstream and downstream directions:
通知要求オブジェクトをPATHまたはRESVメッセージに挿入して、LSP障害を通知するCEのアドレスを示す場合があります。通知は、上流と下流の両方の方向の両方で要求される場合があります。
- Upstream notification is indicated via the inclusion of a Notify Request object in the corresponding Path message.
- 上流の通知は、対応するパスメッセージに通知要求オブジェクトを含めることにより示されます。
- Downstream notification is indicated via the inclusion of a Notify Request object in the corresponding Resv message.
- 下流の通知は、対応するRESVメッセージに通知要求オブジェクトを含めることにより示されます。
A PE receiving a message containing a Notify Request object SHOULD store the Notify Node Address in the corresponding RSVP state block. The PE SHOULD also include a Notify Request object in the outgoing Path or Resv message. The outgoing Notify Node Address MAY be updated based on local policy. This means that a PE, upon receipt of this object from the CE, MAY update the value of the Notify Node Address.
通知要求オブジェクトを含むメッセージを受信するPEは、対応するRSVP状態ブロックにNotifyノードアドレスを保存する必要があります。PEには、発信パスまたはRESVメッセージにNotify Requestオブジェクトも含める必要があります。発信Notifyノードアドレスは、ローカルポリシーに基づいて更新される場合があります。これは、CEからこのオブジェクトを受け取ったときに、PEがNotifyノードアドレスの値を更新できることを意味します。
If the ingress CE includes a Notify Request object into the Path message, the ingress PE MAY replace the received 'Notify Node Address' by its own selected 'Notify Node Address', and in particular the local TE Router_ID. The Notify Request object MAY be carried in Path or Resv messages (Section 7 of [RFC3473]). The format of the Notify Request object is defined in [RFC3473]. Per Section 4.2.1 of [RFC3473], Notify Node Addresses SHALL be set to either IPv4 or IPv6.
Ingress CEに通知要求オブジェクトがパスメッセージに含まれている場合、Ingress PEは、選択した「Nodify Node Address」、特にローカルTE Router_IDで受信した「Notify Nodeアドレス」を置き換えることができます。Notify Requestオブジェクトは、パスまたはRESVメッセージ（[RFC3473]のセクション7）に携帯する場合があります。Notifyリクエストオブジェクトの形式は[RFC3473]で定義されています。[RFC3473]のセクション4.2.1ごとに、NodeアドレスはIPv4またはIPv6のいずれかに設定する必要があります。
Inclusion of a Notify Request object is used to request the generation of notifications upon failure occurrence but does not guarantee that a Notify message will be generated.
通知要求オブジェクトを含めることは、障害発生時に通知の生成を要求するために使用されますが、通知メッセージが生成されることを保証するものではありません。
Security for L1VPNs is covered in [RFC4847] and [RFC5253]. In this document, we discuss the security aspects with respect to the control plane.
L1VPNSのセキュリティは[RFC4847]および[RFC5253]でカバーされています。このドキュメントでは、コントロールプレーンに関するセキュリティの側面について説明します。
The association of a particular port with a particular L1VPN (or to be more precise, with a particular PIT) is a configuration operation, generally done manually by the service provider as part of the service provisioning process. Thus, it cannot be altered via signaling between CE and PE. This means that the signaling cannot be used to deliver L1VPN traffic to the wrong customer. The operator should apply appropriate security mechanisms to the management and configuration process, and should consider data plane verification techniques to protect against accidental misconfiguration. The customer may also apply end-to-end (i.e., CE-to-CE) data plane connectivity tests over the L1VPN connection to detect misconnection. Data plane connectivity testing can be performed using the Link Management Protocol (LMP) [RFC4204].
特定のポートと特定のL1VPNとの関連（または、より正確に、特定のピットを使用）は、サービスプロビジョニングプロセスの一部としてサービスプロバイダーによって手動で行われる構成操作です。したがって、CEとPEの間のシグナル伝達によって変更することはできません。これは、シグナリングを使用してL1VPNトラフィックを間違った顧客に配信できないことを意味します。オペレーターは、管理および構成プロセスに適切なセキュリティメカニズムを適用し、偶発的な誤解から保護するためにデータプレーン検証手法を考慮する必要があります。顧客は、L1VPN接続にエンドツーエンド（CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-Ty-CE）を適用して、ミスと接続を検出することもできます。データプレーンの接続性テストは、リンク管理プロトコル（LMP）[RFC4204]を使用して実行できます。
Note that it is also possible to populate the local part of a PIT using auto-discovery through LMP. LMP may be secured as described in [RFC4204]. Signaling between CE and PE is assumed to be over a private link (for example, in-band or in-fiber) or a private network. Use of a private link makes the CE-to-PE connection secure at the same level as the data link described in the previous paragraphs. The use of a private network assumes that entities outside the network cannot spoof or modify control plane communications between CE and PE. Furthermore, all entities in the private network are assumed to be trusted. Thus, no security mechanisms are required by the protocol exchanges described in this document.
LMPを介して自動配信を使用して、PITのローカル部分に登録することも可能であることに注意してください。[RFC4204]に記載されているように、LMPは確保される場合があります。CEとPEの間のシグナリングは、プライベートリンク（帯域内や繊維内または繊維など）またはプライベートネットワークを超えていると想定されています。プライベートリンクを使用すると、前の段落で説明されているデータリンクと同じレベルでCEとPEの接続が安全になります。プライベートネットワークの使用は、ネットワーク外のエンティティがCEとPE間の制御プレーン通信をスプーフィングまたは変更できないことを前提としています。さらに、プライベートネットワーク内のすべてのエンティティは信頼されていると想定されています。したがって、このドキュメントで説明されているプロトコル交換では、セキュリティメカニズムは必要ありません。
However, an operator that is concerned about the security of their private control plane network may use the authentication and integrity functions available in RSVP-TE [RFC3473] or utilize IPsec ([RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411]) for the point-to-point signaling between PE and CE. See [MPLS-SEC] for a full discussion of the security options available for the GMPLS control plane.
ただし、プライベートコントロールプレーンネットワークのセキュリティに懸念しているオペレーターは、RSVP-TE [RFC3473]で利用可能な認証および整合性関数を使用するか、IPSEC（[RFC4301]、[RFC4302]、[RFC4835]、[RFC43066]を利用する場合があります。、および[RFC2411]）PEとCEの間のポイントツーポイントシグナル伝達の場合。[MPLS-SEC]を参照して、GMPLSコントロールプレーンで利用可能なセキュリティオプションの完全な議論を参照してください。
Note further that a private network (e.g., Layer 2 VPN or Layer 3 VPN) might be used to provide control plane connectivity between a PE and more than one CE. In this scenario, it is RECOMMENDED that each L1 VPN customer have its own such private network. Then, the security mechanisms provided by the private network SHOULD be used to ensure security of the control plane communication between a customer and a service provider.
さらに、プライベートネットワーク（レイヤー2 VPNまたはレイヤー3 VPNなど）を使用して、PEと複数のCE間の制御プレーン接続を提供することに注意してください。このシナリオでは、各L1 VPN顧客が独自のプライベートネットワークを持つことをお勧めします。次に、プライベートネットワークが提供するセキュリティメカニズムを使用して、顧客とサービスプロバイダー間の制御プレーン通信のセキュリティを確保する必要があります。
[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月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K。およびY. Rekhter、「リソース予約プロトコルにおける無数のリンク - トラフィックエンジニアリング（RSVP -TE）」、RFC 3477、2003年1月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）：リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、2005年10月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「Gmplsセグメントリカバリー」、RFC 4873、2007年5月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150] Ayyangar、A.、Kompella、K.、Vasseur、Jp。、およびA. Farrel、「一般化されたマルチプロトコルラベルスイッチングトラフィックエンジニアリング（GMPLS TE）を使用したラベルスイッチングパスステッチ」、RFC 5150、2008年2月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994.
[RFC1700] Reynolds、J。およびJ. Postel、「割り当てられた番号」、RFC 1700、1994年10月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[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月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4835、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月。
[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月。
[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月。
[MPLS-SEC] Fang, L., Ed., " Security Framework for MPLS and GMPLS Networks", Work in Progress, February 2008.
[MPLS-SEC] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2008年2月、Work in Progress。
The authors would like to thank Adrian Farrel, Hamid Ould-Brahim, and Tomonori Takeda for their valuable comments.
著者は、貴重なコメントをしてくれたエイドリアン・ファレル、ハミド・ロールド・ブラヒム、トモノリ・タケダに感謝したいと思います。
Sandy Murphy, Charlie Kaufman, Pasi Eronen, Russ Housley, Tim Polk, and Ron Bonica provided input during the IESG review process.
Sandy Murphy、Charlie Kaufman、Pasi Eronen、Russ Housley、Tim Polk、およびRon Bonicaは、IESGレビュープロセス中に入力を提供しました。
Authors' Addresses
著者のアドレス
Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01821 Phone: +1 (978) 288 3041 EMail: dwfedyk@nortel.com
Don Fedyk Nortel Networks 600 Technology Park Billerica、MA 01821電話：1（978）288 3041メール：dwfedyk@nortel.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 EMail: yakov@juniper.net
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale、CA 94089メール：yakov@juniper.net
Dimitri Papadimitriou Alcatel-Lucent Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: Dimitri.Papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel-Lucent Fr.Wellesplein 1、B-2018 Antwerpen、ベルギー電話：32 3 240-8491メール：dimitri.papadimitriou@alcatel-lucent.be
Richard Rabbat Google Inc. 1600 Amphitheatre Pky Mountain View, CA 95054 EMail: rabbat@alum.mit.edu
Richard Rabbat Google Inc. 1600 Amphitheater Pky Mountain View、CA 95054メール：rabbat@alum.mit.edu
Lou Berger LabN Consulting, LLC Phone: +1 301-468-9228 EMail: lberger@labn.net
Lou Berger Labn Consulting、LLC電話：1 301-468-9228メール：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への情報をお問い合わせください。