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
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（例えばをサポートするデバイスで構成され、レイヤ1サービスプロバイダのネットワークを考慮し、ラムダができる（LSC）デバイス、光クロスコネクト、同期光ネットワーク/同期デジタル階層（SONET / SDH）クロスコネクトスイッチ、など）。我々は、P（プロバイダ）とPE（プロバイダーエッジ）デバイスにこれらのデバイスを仕切ります。本文書の文脈において、我々は、単に「P」として、そして単に「PE」として後者のデバイスに前者のデバイスを指します。 PSは唯一のプロバイダのネットワーク内のデバイスに接続されています。 PEがネットワーク内の他のデバイス（PSまたはPEのいずれか）に、ならびにサービス・プロバイダ・ネットワークの外部デバイスに接続されています。私たちは、カスタマーエッジ（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]はPEにCEからのシグナリングを定義します。 [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）シグナリング[RFC3471]、[RFC3473]、ルーティング[RFC4202]、およびLMP [RFC4204を使用して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およびインタープロバイダL1VPNsの検討は、このドキュメントの範囲を超えてさらなる分析が必要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This 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]、[RFC3477]、[RFC4201]、[RFC4202]、[RFC4204]、[RFC4208]、およびドキュメントそこ参照。
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は、CEおよびPE間（（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を形成するCEのセットにメンバーシップの概念を導入し、VPNのメンバーである論理的構築物です。 GMPLSによってサポートされるように、各リンクの端部にインタフェースは、TDMまたはLSCのいずれかに限定されます。より具体的には、<CE、PE>リンクは、X = PSC（パケット対応のスイッチ）、L2SC（可能なレイヤ2スイッチ）、またはTDMおよびY = PSCタイプ<X、LSC>または<Y、TDM>でなければなりませんまたはL2SC。場合LSPも= LSCおよびY = TDM CE、X MAYによって終了されていません。 L1VPN接続の用途の一つは、「仮想プライベートラムダ」または類似を提供することです。この場合、CEは真にGMPLS用語でエンドポイントであり、その一般プロトコル識別子（GPID）は、両方のCESでシグナリングと同じでなければならないがTEリンクにそのスイッチング能力は、（すなわち、ヘッドエンドとテール関係がありません末端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).
CEは、このようなSDHクロスコネクトとして層1における装置、2、3、であってもよいが、同様に、PEは、GMPLS（例えば、光クロスコネクト、SDHクロスコネクト）によって支持されている任意のレイヤ1つのデバイスとすることができますイーサネットスイッチ、ルータ、それぞれ）。
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ごとに少なくとも1つのポートを有する）複数のPEに接続されてもよいです。そして、逆に、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に属している場合、（ASコンポーネントリンクと呼ばれる）これらのリンクは、構築物をバンドルリンクを使用して単一のTEリンク[RFC4201]として扱うことができます。
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つのデータ・ベアリング・チャネルを有し、チャネルを担持する少なくとも一つの制御、又はそこことが要求されます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.
CE上の一方とPE上のいずれかのポイントツーポイントリンクは、2つのエンドポイントを有します。この文書では、「CEポート」として、および「PEポート」、後者に前者を指します。以上のことから、CEは、各ポートは1つまたは複数のチャネルまたはサブチャネル（例えば、波長または波長およびタイムスロットのそれぞれ）から成ることができる一つまたは複数のポートを介してPEに接続されていることに、すべてのチャネル所与のポート内に同様の特性を共有しているビューのCEの点から交換することができます。 TEリンクの定義と同様に、本明細書の文脈では、ポートごとのL1VPN基づいてPEにCEを接続するために使用される物理リソースのグループを表すために使用される論理構築体です。
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によって維持されます異なるポート情報の表と、より正確には異なるL1VPNs、または、）。 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サービスにおけるもう一つの重要な目標は、サービスプロバイダのデバイスのいずれかに設定の変更を伴うことなくCEデバイスからL1VPN以内（既存の）ポートのペア間のLSPを確立/終了する機能です。換言すれば、VPNトポロジーは（下地PE対PE接続が提供され、ネットワークによって許可されていると仮定して）CEデバイス制御下にあります。
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）ポートのサブセットに実際のLSPを確立するためにイネーブルCE 。最後に、メカニズムは、任意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サービスの提供に関与するすべての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
所与L1VPN内、PEにCEを接続CE上の各ポートは、L1VPN内で一意である識別子を有している（ただし、いくつかのL1VPNs全体で一意である必要はありません）。そのような識別子を構築する一つの方法は、各ポートに与えL1VPN内で一意のアドレスを割り当て、ポート識別子としてこのアドレスを使用することです。そのような識別子を構築する別の方法は、CEそのCE内で一意であるインデックスの各ポートを割り当て、各CEを与えL1VPN内で一意のアドレスを割り当て、その後としてタプル<ポートインデックス、CEアドレス>を使用することですポート識別子。ポートおよびCEアドレスの両方が、いくつかのフォーマットでのアドレスであってもよいことに注意してください。これには、IPv4とIPv6が、これらに限定されません。この識別子は、の一部であります
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.
顧客は、レルムをアドレッシングし、シグナリングのためにCEポートとCEリモートポートを識別するために、CEデバイスによって使用されます。 CEは、サービスプロバイダレルムアドレスを知っているか理解していません。
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.
サービス・プロバイダ・ネットワーク内で、CEへのPEを接続するPE上の各ポートは、ネットワーク内で一意の識別子を有します。そのような識別子を構築する一つの方法は、PEそのPE内で一意であるインデックスの各ポートを割り当て、各PEにサービスプロバイダのアドレス指定領域内で一意のIPアドレスを割り当て、次に、タプル<ポートインデックス、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).
その結果、PEとCEを接続する各リンクは、所与L1VPN内で一意の識別子を有するCEポートに関連付けられ、サービスプロバイダネットワーク内で一意の識別子を有するPEポートを備えています。私たちは、プロバイダポート識別子（PPI）などの顧客ポート識別子（CPI）など、および前者と後者を指します。
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顧客内で一意である識別子を有することを必要とします。そのような識別子を構築する一つの方法は、各ポートにレルムをアドレッシング所与L1VPN顧客内で一意のアドレスを割り当て、ポート識別子としてこのアドレスを使用することです。そのような識別子を構築する別の方法は、各ポート所与のPE内で一意のインデックスを割り当て、各PEを所与L1VPN顧客アドレッシング領域内で一意のIPアドレスを割り当てる（ただし、サービスプロバイダネットワーク内で一意である必要はない）ことです、その後ポート識別子として作用するタプル<ポートインデックス、PE IPアドレス>を使用します。私たちは、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.
L1VPNsの場合は、サービスプロバイダの操作はVPNの顧客のアドレシング分野の独立しており、サービスプロバイダのアドレス指定レルムは、顧客から隠されている要件があります。これを達成するために、我々はPE、1つの顧客対面と直面する他のサービスプロバイダの2つの識別子を定義します。 （二つの異なるアドレスレルムから取得されたように、VPNサービスプロバイダのアドレス指定領域から顧客のアドレス指定領域から、前者と後者の）VPN-PPIのために使用されるPE IPアドレスがPPIのために使用されるPEのIPアドレスとは無関係です。 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:
PEとCEを接続する所定のリンクのために：
- 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.
この文書では、のCPIとPPIのVPN-で使用されているアドレスの割り当てはもっぱらL1VPNの管理者によって制御されている間のPPIの割り当ては、もっぱら（L1VPNの顧客との任意の調整なし）、サービスプロバイダによって制御されていることを前提としています。これは、最大の柔軟性を提供します。 L1VPN管理者は、L1VPNの顧客のためのL1VPNサービスの仕様を制御するエンティティです。この機能は、サービスプロバイダーが所有することができるだけでなく、サービスプロバイダとの契約があり、第三者によって行われてもよいです。そして、もちろん、各L1VPNの顧客は他のL1VPNsとの任意の調整なし、自分自身でそのようなアドレスを割り当てることができます。
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接続を必要とします。この接続は、L3VPNのように、専用のリンクのいずれかによって、またはL2 VPNによって実現することができる単一のIPホップ、またはIPプライベートネットワークのいずれかとすることができます。この接続上の唯一の要件は、特定L1VPNと特定のCEツーPE制御チャネルを相関させる明確な方法です。このようなチャネルは、専用リンクによって実現される場合、そのようなリンクは、特定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-CC-ADDR）として、及びPE制御チャネルアドレス（PE-CC-ADDR）としてこのチャネルのPEのアドレスに、このチャネルのCEのアドレスを参照してくださいます。 CE-CC-addrとPE-CC-ADDRの両方が、彼らが属するL1VPN内で一意であることが要求されるが、複数のL1VPNs全体で一意である必要はありません。制御チャネルアドレスは、複数の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は、CEのペアが与えられたVPNポート・トポロジ内のGMPLSベースのLSPを介してサービス・プロバイダ・ネットワークを介して接続することができるポートベースのVPNサービスです。それは正確にサービスプロバイダのネットワークが提供していますL1VPNサービスの基本的な単位を形成し、このLSPです。 CEは、PEに接続されるポートは、複数のチャネル（例えば、複数の波長）で構成されている場合、CEは、この単一ポート上同じVPN内の複数の他のCEに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接続がのCE自身の制御下にあります。換言すれば、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>タプルのリストが含まれています。加えて、所与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を示します。 PITは、局所的な情報だけでなく、リモートの情報から構成されています。所与のPE上のPITは、2つの情報源から取り込まれることになります。
1. The information related to the CEs' ports that are attached to the ports local to that PE.
そのPEのローカルポートに接続されたCEポートに関する1.情報。
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は<CPI、VPN-PPI>リンク情報を取り込むためにLMPを活用してもよい（MAY）。このローカル情報は、同じVPNを共有する他のPEに伝播する必要があります。このためのメカニズムはこの文書の範囲外であるが、交換するために必要な情報は、セクション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.
PITは、自然のVPN固有です。 PEは、それがローカルに接続された部材のCEを持っている各L1VPNためのPITを維持するために必要とされます。 PEは、他のL1VPNsのためのピットを維持する必要はありません。しかし、複数の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の、すなわち、遠隔CES）の文脈における遠隔情報は、同じVPNに属するローカルCEに送ってもよいです。この情報の交換は、この文書の範囲外です。
The information that needs to be discovered on a PE local port is the local CPI and the VPN-PPI.
PEローカルポート上で発見される必要のある情報は、ローカルCPIとPPI-VPNです。
This information MAY be configured; or, if LMP is used between the CE and PE, LMP MAY be used to exchange this information.
この情報を構成してもよいです。 LMPは、CEとPEの間で使用される場合は、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コンテキストを実施する一つの方法は、VPN識別子で予め規定VPN-のPPIです。これを達成するために、他のポリシーメカニズムはこの文書の範囲外です。ポートは、VPNに属するものとしてプロビジョニングされたときにこのように、VPNおよびPPIポートへのCPIの関係を確立することができます。
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.
このセクションでは、任意の自動検出機構によって搬送される情報を提供し、動的PITを移入するために使用されます。情報は、単一の<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>タプルはコードの形式
+---------------------------------------+
| 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.
その値は1オクテットフィールドは、PPIのフィールドの長さを示します。
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:
ICC AFI：
A two-octet field whose value indicates the address family of the CPI. This value is taken from [RFC1700].
その値は2オクテットのフィールドは、CPIのアドレスファミリを示します。この値は[RFC1700]から取られます。
CPI Length:
CPIの長さ：
A one-octet field whose value indicates the length of the CPI field.
その値は1オクテットフィールドはCPIフィールドの長さを示します。
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>タプルとの関連付けを定義します。 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内のポートの所与の対について、これらのポートに接続されたCEのそれぞれが同時に他のCEにLSPを確立しようとすることが起こり得ます。ポートの対の間のLSPの組を有する望ましくないと見なされる場合、これを解決する方法は、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は、ターゲットポートにLSPを確立するために、プロバイダネットワークを要求するGMPLSシグナリングのサブセットを使用します。
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.
間-CE接続の場合は、CEは、それがLSPのために使用したいそのポートのいずれか、およびターゲットポートのCPIのCPIが含まれている要求を発信します。要求を発信しCEに取り付けられたPEが要求を受信した場合、PEは、適切なPITを識別し、その要求内で運ばターゲットポートのCPIに関連付けられたPPIを見つけるために、そのPIT内の情報を使用します。 PPIは、LSPを確立するPEのために十分であるべきです。最終的に、要求は、ターゲットCPI（要求がまだ要求を発信したCEのCPIを運ぶことに注意）に関連付けられたCEに到達します。目標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ポリシーの問題であり、CEが知っているすべてのターゲットポートにLSPを確立する必要はないことに注意してください。
The procedures for establishing an individual connection between two corresponding CEs is the same as the procedure specified for GMPLS overlay [RFC4208].
対応する二つの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.
入口CEは、入口PEにRSVP Pathメッセージを送信するとき、メッセージを運ぶIPパケットの送信元IPアドレスが適切なCE-CC-ADDRに設定され、パケットの宛先IPアドレスが適切に設定されていますPE-CC-ADDR。入口PEは入口CEに対応するResvメッセージ、PE-CC-ADDRに設定されているメッセージを運ぶIPパケットの送信元IPアドレス、宛先IPアドレスを返送する場合CE-CC-に設定されています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が出力CEにRSVP Pathメッセージを送信すると同様に、メッセージを運ぶIPパケットの送信元IPアドレスは、適切なPE-CC-ADDRに設定され、パケットの宛先IPアドレスは次のように設定されています適切なCE-CC-ADDR。出口CEが出力PEに戻す対応するResvメッセージ、CE-CC-ADDRに設定されているメッセージを運ぶIPパケットの送信元IPアドレス、宛先IPアドレスを送信するときPE-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、CE-CC-ADDRおよびPE-CC-ADDR間RSVPメッセージを運ぶIPパケット内のIPアドレスのために使用されていることに加えてもIF_ID RSVP_HOPオブジェクトの次/前のホップアドレスフィールドで使用されていますCEとPE間で実施。
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オブジェクト処理」）および4.1 RFC 3477 [RFC3477]の（「番号なし転送隣接関係」を参照）。
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).
入口CEは、特定のターゲットポートへのCE上の特定のポートからのLSPを確立するためのPathメッセージを発信する場合、CEは、送信者テンプレートオブジェクトにそのポートのCPIを使用します。ターゲットポートのCPIは、IPアドレスである場合には、CEは、Sessionオブジェクトにそれを使用しています。ターゲットポートのCPIは、<ポートインデックス、IPアドレス>タプルであれば、その後、CEは、明示的経路オブジェクト内アンナンバードインターフェイスIDのサブオブジェクトとしてSessionオブジェクト内のタプルのIPアドレスの一部、および全体のタプルを使用しています（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セッションの終わりを持つことです。これはシャッフルと呼ばれています。ステッチまたは階層は二つのLSPセッション、プロバイダPE（S）とCEとの間の別のエンドツーエンドのセッションの間に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.
欲求は、単一のLSPは、CEから発信し、遠端CEで終端持っているときにシャッフルセッションが使用されています。顧客アドレスはPITによって提供されるマッピングを使用して、入口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.
Pathメッセージが入口PEに到達すると、PEはL1VPNに関連付けられたPITを選択し、適切なのPPIにセッションで運ばのCPIと送信者テンプレートオブジェクトをマッピングするために、このPITを使用します。マッピングが完了すると、入力PEは、これらのPPIとのCPIを置き換えます。結果として、セッションとサービスプロバイダネットワーク内のGMPLSシグナリングで運ばれる送信者テンプレートオブジェクトはのPPI、およびいないのCPIを運びます。
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を見つけるために適切なPITを識別する。マッピングが検索されると、出口PEは、対応するCPI値と入口/出口PPI値を置き換えます。結果として、（出力CEに出力PEから送信されたGMPLSのRSVP-TE Pathメッセージに含まれている）セッションおよび送信者テンプレートオブジェクトはのCPI、およびいないのPPIを運びます。
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.
ここでも、CEに出口PEから送信されたGMPLSのRSVP-TEのPathメッセージのために、（このメッセージを運ぶIPパケットの）送信元IPアドレスが適切なPE-CC-ADDRに設定され、宛先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.
（ - ）PE-CE CE-PE：この時点で、CEのビューは、ポイントツーポイントPEノード間の仮想リンクを有する2つのCE間で単一のLSPです。 L1VPN PEノードは、そのすべての詳細PE対PE LSPセグメントのビューを持っています。 PEは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メッセージのために実行しなければなりません。この場合、1つのCE-に-CEセッションがあります。
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-CE-およびPE-に-PEのLSPタイプとスイッチング容量に同一である場合、LSPは、一緒にステッチされてもよく、[RFC5150]の手順が適用されます。 CEツーCEのLSPとPE-に-PEのLSPがない同じスイッチング型であるか、または異なるが互換性の容量である場合、LSPは入れ子にすることができて、[RFC4206]の手順が適用されます。両方のステッチとネストされた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, 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に関連付けられたPITを選択し、適切なのPPIにセッションで運ばのCPIと送信者テンプレートオブジェクトをマッピングするために、このPITを使用します。マッピングが完了すると、新しいPE-に-PEセッションはCEセッションと互換性のあるパラメータで確立されます。 PE-に-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-に-PE LSPまたは転送隣接LSP（FA-LSP）を関連付けます。
- Establishing a compliant PE-to-PE LSP segment.
- 対応PE-に-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.
（ - ）PE-CE CE-PE：この時点で、CEのビューは、ポイントツーポイントPEノード間の仮想ノードを持つ2つのCE間で単一のLSPです。 L1VPN PEノードは、そのすべての詳細PE対PE LSPセグメントのビューを持っています。 PEは、PE対PEシグナリングはCEノードには見えないので、プロバイダ・トポロジについての情報を除去することにより、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)>}.
イングレスPEは、受信および潜在的に明示的なルートオブジェクトを含むPathメッセージを拒否し、そのスイッチの接続設定が失敗する可能性があります。しかし、入口PEは、の配列を含むエロスを、受け入れることができる{<入口PE（厳密）、出口CEのCPI（緩いです）>}。
- 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なしのPathメッセージ：入口PEはないEROが含まれていない入口CEからPathメッセージを受信した場合、それはPE-に-PE LSPの宛先へのルートを計算しなければならないし、転送する前に、EROにその経路を含みますPathメッセージ。出口コアノードは、このコア・ノードに隣接していた場合は、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とPathメッセージ：入口PEは、（上で詳述した形態の）EROが含ま入口CEからPathメッセージを受信した場合、前者は出口PEに到達する経路を計算します。その後、Pathメッセージを転送する前に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
シャフリングの場合には、通知とRRO処理のためのオーバーレイ・ルールはユーザ・ネットワークIntercase（UNI）またはオーバレイモデル[RFC4208]、エッジPEは/編集を除去することができる状態と同一であります
Provider Notification and RRO objects when passing the messages to the CEs.
プロバイダの通知とRROオブジェクトCEにメッセージを渡します。
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は、ネットワーク保護LSPを要求する（すなわち、PE-に-PEから保護されるLSP）[RFC4873]に記載された技術を使用して。マージノードの動的な識別は、（[RFC4873]のセクション6.2を参照）は保護対象で運ばLSPセグメント回復フラグを介して支持されています。
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:
通知Requestオブジェクトは、LSPの障害を通知しなければならないCEのアドレスを示すために、パスまたはRESVメッセージに挿入することができます。通知は両方の上流と下流の方向に要求されることがあります。
- Upstream notification is indicated via the inclusion of a Notify Request object in the corresponding Path message.
- アップストリーム通知は、対応するPathメッセージで通知Requestオブジェクトの包含を介して示されています。
- Downstream notification is indicated via the inclusion of a Notify Request object in the corresponding Resv message.
- ダウンストリーム通知は、対応するResvメッセージで通知Requestオブジェクトの包含を介して示されています。
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.
対応するRSVP状態ブロック内のノードアドレスを通知格納する必要が通知要求オブジェクトを含むメッセージを受信したPE。 PEはまた、送信パスまたはResvメッセージで通知リクエストオブジェクトを含むべきです。送信通知ノードアドレスは、ローカルポリシーに基づいて更新されてもよいです。これは、PEは、CEからこのオブジェクトを受信すると、通知ノードアドレスの値を更新してもよいことを意味します。
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.
入口CEは、Pathメッセージに通知リクエストオブジェクトを含む場合、入口PEは、選択された独自によって受信された「ノードアドレスを通知する」交換「ノードアドレスを通知」、特にローカルTE ROUTER_ID MAY。通知要求オブジェクトは、パスまたはRESVメッセージ（[RFC3473]のセクション7）で実施することができます。通知リクエスト・オブジェクトのフォーマットは、[RFC3473]で定義されています。 [RFC3473]のセクション4.2.1あたり、通知ノードアドレスは、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.
通知Requestオブジェクトを含めることは、障害発生時の通知の生成を要求するために使用されますが、通知メッセージが生成されることを保証するものではありません。
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（又は特定のPITと、より正確に）を有する特定のポートの関連付けは、一般に、サービス・プロビジョニング・プロセスの一部としてサービスプロバイダによって手動で行う構成操作、です。従って、CEおよびPE間のシグナリングを介して変更することができません。これは、シグナリングが間違った顧客にL1VPNトラフィックを配信するために使用することができないことを意味します。オペレータは、管理と構成のプロセスに適切なセキュリティメカニズムを適用する必要があり、そして偶然の設定ミスから保護するために、データ・プレーン・検証技術を検討すべきです。顧客はまた、誤接続を検出するためL1VPN接続を介してエンド・ツー・エンド（すなわち、CE-に-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]、[RFC4306]を利用してもよいです、および[RFC2411]）PEとCEの間のポイントツーポイントシグナリングのため。 GMPLS制御プレーンのために利用可能なセキュリティオプションの完全な議論については[MPLS-SEC]を参照してください。
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またはレイヤ3 VPN 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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング（GMPLS）のサポートで"、RFC 4202、2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]ラング、J.、エド。、 "リンク管理プロトコル（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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[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]ツバメ、G.、ドレイク、J.、石松、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]バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、 "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.ファレルは、2008年2月、RFC 5150 "ラベルは、トラフィックエンジニアリング（TE GMPLS）をスイッチング汎用マルチプロトコルラベルとステッチスイッチパス"。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994.
[RFC1700]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、RFC 1700、1994年10月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（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.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（TE）"、RFC 4201、2005年10月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[RFC4847]武田、T.、エド。、 "フレームワークおよびレイヤ1つの仮想プライベートネットワークの要件"、RFC 4847、2007年4月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]セイヤー、R.、Doraswamy、N.、およびR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、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.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5195]ウルド - Brahimの、H.、Fedyk、D.、およびY. Rekhter、 "BGPベースの自動検出のためのレイヤ1のVPN"、RFC 5195、2008年6月。
[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月。
[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）基本モードのための適用性に関する声明"。
[MPLS-SEC] Fang, L., Ed., " Security Framework for MPLS and GMPLS Networks", Work in Progress, February 2008.
[MPLS-SEC]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、進歩、2008年2月に作業。
The authors would like to thank Adrian Farrel, Hamid Ould-Brahim, and Tomonori Takeda for their valuable comments.
作者は彼らの貴重なコメントをエードリアンファレル、ハミドウルド-Brahimの、および智則武田に感謝したいと思います。
Sandy Murphy, Charlie Kaufman, Pasi Eronen, Russ Housley, Tim Polk, and Ron Bonica provided input during the IESG review process.
サンディマーフィー、チャーリー・カウフマン、パシEronen、ラスHousley、ティムポーク、そしてロンBonicaはIESGレビュープロセス中に入力を提供します。
Authors' Addresses
著者のアドレス
Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01821 Phone: +1 (978) 288 3041 EMail: dwfedyk@nortel.com
ドン・ルブランNortel Networksの600テクノロジーパーク、ビレリカ、MA 01821電話：+1（978）288 3041 Eメール：dwfedyk@nortel.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 EMail: yakov@juniper.net
ヤコフ・レックタージュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089 Eメール：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
ディミトリPapadimitriouアルカテル・Lykent属。 Vellesplein 1 B-2018アントワープ、Velgiomボイス：X2 + 3 240から8491 Eメール：Δημήτρη.Παπαδημητρίου@αλκατελ-λυκεντ.βε
Richard Rabbat Google Inc. 1600 Amphitheatre Pky Mountain View, CA 95054 EMail: rabbat@alum.mit.edu
リチャードRabbatグーグル株式会社1600アンフィシアターPKYマウンテンビュー、CA 95054 Eメール：rabbat@alum.mit.edu
Lou Berger LabN Consulting, LLC Phone: +1 301-468-9228 EMail: lberger@labn.net
ルー・バーガーLabNコンサルティング、LLC電話：+1 301-468-9228電子メール：lberger@labn.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。