RFC5253 日本語訳
5253 Applicability Statement for Layer 1 Virtual Private Network(L1VPN) Basic Mode. T. Takeda, Ed.. July 2008. (Format: TXT=42675 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Takeda, Ed. Request for Comments: 5253 NTT Category: Informational July 2008
ワーキンググループT.竹田、エドをネットワークでつないでください。コメントのために以下を要求してください。 5253年のNTTカテゴリ: 情報の2008年7月
Applicability Statement for
Layer 1 Virtual Private Network (L1VPN) Basic Mode
層1の仮想私設網(L1VPN)の基本のモードのための適用性証明
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs).
このドキュメントは、Basic Mode Layer1Virtual兵士のNetworks(L1VPNs)をサポートするためにGeneralized Multiprotocol Label Switching(GMPLS)プロトコルとメカニズムの使用に関する適用性証明を提供します。
L1VPNs provide customer services and connectivity at Layer 1 over Layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN.
L1VPNsはLayer1でLayer1ネットワークの上に顧客サービスと接続性を提供します。 L1VPNsの操作はBasic ModeとEnhanced Modeに分割されます。そこでは、操作のBasic ModeがLayer1ネットワークと顧客ドメインの間のルーティング情報の少しの交換も特徴としません。 このドキュメントはBasic Mode L1VPNの要件を満たすのにどうGMPLSプロトコルを使用できるかを調べます。
Takeda Informational [Page 1] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[1ページ]のRFC5253
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Basic Mode Overview .............................................3
3. Supported Network Types .........................................4
3.1. Data Plane .................................................4
3.2. Control Plane ..............................................4
4. Addressing ......................................................5
5. Provider Control of Its Infrastructure ..........................5
5.1. Provisioning Model .........................................5
5.2. PE-to-PE Segment Control ...................................6
5.2.1. Path Computation and Establishment ..................6
5.2.2. Resource Management .................................7
5.2.3. Consideration of CE-to-PE Traffic Engineering
Information .........................................8
5.3. Connectivity Restriction ...................................8
6. Customer Control of Its L1VPN ...................................8
6.1. Topology Control ...........................................8
6.2. Note on Routing ............................................9
7. Scalability and Resiliency .....................................10
7.1. Scalability ...............................................10
7.2. Data Plane Resiliency .....................................11
7.3. Control Plane Resiliency ..................................12
8. Security Considerations ........................................12
8.1. Topology Confidentiality ..................................12
8.2. External Control of the Provider Network ..................13
8.3. Data Plane Security .......................................13
8.4. Control Plane Security ....................................14
9. Manageability Considerations ...................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................16
11. Acknowledgments ...............................................17
1. 序論…3 1.1. 用語…3 2. 基本的なモード概要…3 3. サポートしているネットワークはタイプされます…4 3.1. データ飛行機…4 3.2. 飛行機を制御してください…4 4. 扱います。5 5. インフラストラクチャのプロバイダーコントロール…5 5.1. モデルに食糧を供給します…5 5.2. PEからPEへのセグメントコントロール…6 5.2.1. 経路計算と設立…6 5.2.2. リソース管理…7 5.2.3. CeからPEへのトラフィック技術情報連合社の考慮…8 5.3. 接続性制限…8 6. L1VPNの顧客コントロール…8 6.1. トポロジーコントロール…8 6.2. ルート設定のときに、注意します。9 7. スケーラビリティと弾性…10 7.1. スケーラビリティ…10 7.2. データ飛行機の弾性…11 7.3. 飛行機の弾性を制御してください…12 8. セキュリティ問題…12 8.1. トポロジー秘密性…12 8.2. プロバイダーネットワークの外部のコントロール…13 8.3. データ飛行機セキュリティ…13 8.4. 飛行機セキュリティを制御してください…14 9. 管理可能性問題…15 10. 参照…15 10.1. 標準の参照…15 10.2. 有益な参照…16 11. 承認…17
Takeda Informational [Page 2] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[2ページ]のRFC5253
1. Introduction
1. 序論
This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to Basic Mode Layer 1 Virtual Private Networks (L1VPNs) as specified in [RFC4847].
このドキュメントは[RFC4847]の指定されるとしてのBasic Mode Layer1Virtual兵士のNetworks(L1VPNs)にGeneralized Multiprotocol Label Switching(GMPLS)プロトコルとメカニズムの使用に関する適用性証明を供給します。
The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode. The Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain, while the Enhanced Mode of operation features exchange of routing information between the Layer 1 network and the customer domain.
L1VPNsの操作はBasic ModeとEnhanced Modeに分割されます。 操作のBasic ModeはLayer1ネットワークと顧客ドメインの間のルーティング情報の少しの交換も特徴としません、操作のEnhanced ModeはLayer1ネットワークと顧客ドメインの間のルーティング情報の交換を特徴としますが。
The main GMPLS protocols and mechanisms applicable to the L1VPN Basic Mode are described in [RFC5251], [RFC5195], and [RFC5252], along with several other documents referenced within this document.
主なGMPLSプロトコルとL1VPN Basic Modeに適切なメカニズムは[RFC5251]、[RFC5195]、および[RFC5252]で説明されます、このドキュメントの中に参照をつけられた他のいくつかのドキュメントと共に。
Note that discussion in this document is focused on areas where GMPLS protocols and mechanisms are relevant.
議論が本書ではGMPLSプロトコルとメカニズムが関連している領域に焦点を合わせられることに注意してください。
1.1. Terminology
1.1. 用語
The reader is assumed to be familiar with the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC4026], and [RFC4847].
読者が[RFC3031]、[RFC3209]、[RFC3471]、[RFC3473]、[RFC4202]、[RFC4026]、および[RFC4847]の用語によく知られさせると思われます。
2. Basic Mode Overview
2. 基本的なモード概要
As described in [RFC4847], in the Basic Mode service model, there is no routing exchange between the Customer Edge (CE) and the Provider Edge (PE). CE-to-CE L1VPN connections (i.e., the CE-to-CE VPN connection in RFC 4847) are set up by GMPLS signaling between the CE and the PE, and then across the provider network. A L1VPN connection is limited to the connection between CEs belonging to the same L1VPN.
[RFC4847]、Basic Modeサービスモデルで説明されるように、Customer Edge(CE)とProvider Edge(PE)の間には、ルーティング交換が全くありません。 CEからCE L1VPNとの接続(すなわち、CEからCE VPNとのRFC4847での接続)はCEとPEの間と、そして、そして、プロバイダーネットワークの向こう側に合図するGMPLSによってセットアップされます。 L1VPN接続は、同じL1VPNに属しながら、CEsの間で接続に制限されます。
Note that in L1VPNs, routing operates within the provider network. Also note that routing may be used by PEs to exchange information specific to the L1VPNs supported by the provider network (e.g., membership information).
ルーティングがプロバイダーネットワークの中でL1VPNsでは、作動することに注意してください。 また、ルーティングがプロバイダーネットワーク(例えば、会員資格情報)によってサポートされたL1VPNsに特定の情報を交換するのにPEsによって使用されるかもしれないことに注意してください。
In the L1VPN Basic Mode, the provider network is completely under the control of the provider. This includes the PE-to-PE segment of the CE-to-CE L1VPN connection that is controlled and computed by the provider (PE-to-PE segment control). On the other hand, the L1VPN itself, constructed from a set of CEs and the L1VPN connections provided by the provider, is under the control of each customer. This control includes that a customer can request between which CEs a
L1VPN Basic Modeに、プロバイダーネットワークがプロバイダーのコントロールの完全下にあります。 これはCEからCE L1VPNとのプロバイダー(PEからPEへのセグメントコントロール)によって監督されて、計算される接続のPEからPEへのセグメントを含んでいます。 他方では、CEsの1セットとプロバイダーによって提供されたL1VPN接続から組み立てられたL1VPN自身がそれぞれの顧客のコントロールの下にあります。 このコントロールはどのCEs aの間でそのa顧客缶の要求を含んでいるか。
Takeda Informational [Page 3] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[3ページ]のRFC5253
connection is to be established (topology control). Note that a customer may outsource the management of its L1VPN to a third party, including to the provider itself. There is a confidentiality requirement between the provider and each customer.
接続は確立されることになっています(トポロジーコントロール)。 顧客がプロバイダーにそれ自体を含む第三者にL1VPNの管理を社外調達するかもしれないことに注意してください。 プロバイダーと各顧客の間には、機密保持の要求事項があります。
[RFC5251], which extends [RFC4208], specifies GMPLS signaling to establish CE-to-CE L1VPN connections.
[RFC5251](広がります)[RFC4208]はCEからCE L1VPNとの接続を確立すると合図するGMPLSを指定します。
[RFC5195] and [RFC5252] specify alternative mechanisms to exchange L1VPN membership information between PEs, based on BGP and OSPF, respectively.
[RFC5195]と[RFC5252]は、それぞれBGPとOSPFに基づくPEsの間のL1VPN会員資格情報を交換するために代替のメカニズムを指定します。
3. Supported Network Types
3. ネットワークタイプであるとサポートされます。
3.1. Data Plane
3.1. データ飛行機
The provider network can be constructed from any type of Layer 1 switches, such as Time Division Multiplexing (TDM) switches, Optical Cross-Connects (OXCs), or Photonic Cross-Connects (PXCs). Furthermore, a PE may be an Ethernet Private Line (EPL) type of device, that maps Ethernet frames onto Layer 1 connections (by means of Ethernet over TDM, etc.). The provider network may be constructed from switches providing a single switching granularity (e.g., only VC3 switches), or from switches providing multiple switching granularities (e.g., from VC3/VC4 switches, or from VC3 switches and OXCs). The provider network may provide a single type of L1VPN connection (e.g., VC3 connections only), or multiple types of connection (e.g., VC3/VC4 connections, or VC3 connections and wavelength connections).
プロバイダーネットワークは、どんなタイプのTime事業部Multiplexing(TDM)スイッチなどのLayer1スイッチからも構成できるか、Optical Cross接続するか(OXCs)、またはPhotonic Cross接続します(PXCs)。 その上、PEがデバイスのイーサネット兵士の線(EPL)タイプであるかもしれない、それはLayer1接続(TDMなどの上のイーサネットによる)にイーサネットフレームを写像します。 プロバイダーネットワークはただ一つの切り換え粒状を提供するスイッチ(例えば、VC3スイッチだけ)か、複数の切り換え粒状を提供するスイッチ(例えば、VC3/VC4スイッチか、VC3スイッチとOXCsからの)から構成されるかもしれません。 プロバイダーネットワークは単独のタイプのL1VPN接続(例えば、VC3接続専用)、または複数のタイプの接続(例えば、VC3/VC4接続か、VC3接続と波長接続)を提供するかもしれません。
A CE does not have to have the capability to switch at Layer 1, but it must be capable of receiving a Layer 1 signal and either switching it or terminating it with adaptation.
それは、CEには、Layer1で切り替わる能力がある必要はありませんが、Layer1信号を受信して、それを切り換えなければならないか、または適合でそれを終えることができなければなりません。
As described in [RFC4847] and [RFC5251], a CE and a PE are connected by one or more links. A CE may also be connected to more than one PE, and a PE may have more than one CE connected to it.
[RFC4847]と[RFC5251]で説明されるように、CEとPEは1個以上のリンクによって接続されます。 また、CEは1PEに接続されるかもしれません、そして、PEは1CEをそれに接続させるかもしれません。
A CE may belong to a single L1VPN, or to multiple L1VPNs, and a PE may support one or more L1VPNs through a single CE or through multiple CEs.
CEは独身のL1VPN、または、複数のL1VPNsに属するかもしれません、そして、PEは独身のCEを通して、または、複数のCEsを通して1L1VPNsをサポートするかもしれません。
3.2. Control Plane
3.2. 制御飛行機
The provider network is controlled by GMPLS. L1VPN Basic Mode provider networks are limited to a single AS within the scope of this document. Multi-AS Basic Mode L1VPNs are for future study.
プロバイダーネットワークはGMPLSによって制御されます。 L1VPN Basic Modeプロバイダーネットワークはこのドキュメントの範囲の中の独身のASに制限されます。 今後の研究にはマルチAS Basic Mode L1VPNsがあります。
Takeda Informational [Page 4] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[4ページ]のRFC5253
As described in [RFC4847] and [RFC5251], a CE and a PE need to be connected by at least one control channel. It is necessary to disambiguate control plane messages exchanged between a CE and a PE if the CE-to-PE relationship is applicable to more than one L1VPN. This makes it possible to determine to which L1VPN such control plane messages apply. Such disambiguation can be achieved by allocating a separate control channel to each L1VPN (either using a separate physical channel, a separate logical channel such as an IP tunnel, or using separate addressing).
[RFC4847]と[RFC5251]で説明されるように、CEと少なくとも1時までに接続されるべきPEの必要性はチャンネルを監督します。 CEからPEへの関係が1L1VPNに適切であるならCEとPEの間で交換されたコントロール飛行機メッセージのあいまいさを除くのが必要です。 これで、そのようなコントロール飛行機メッセージがどのL1VPNに適用されるかを決定するのが可能になります。 各L1VPN(別々の物理的なチャンネル、IPトンネルなどの別々の論理チャネルを使用するか、または別々のアドレシングを使用する)に別々の制御チャンネルを割り当てることによって、そのような曖昧さの解消を達成できます。
GMPLS allows any type of control channel to be used, as long as there is IP level reachability. In the L1VPN context, instantiation of a control channel between a CE and a PE may differ depending on security requirements, etc. This is discussed in Section 8.
IPの平らな可到達性がある限り、GMPLSは、どんなタイプの制御チャンネルも使用されるのを許容します。 L1VPN文脈では、セキュリティ要件などによって、CEとPEの間の制御チャンネルの具体化は異なるかもしれません。 セクション8でこれについて議論します。
4. Addressing
4. アドレシング
As described in [RFC5251], the L1VPN Basic Mode allows that customer addressing realms overlap with each other, and also overlap with the service provider addressing realm. That is, a customer network may reuse addresses used by the provider network, and may reuse addresses used in another customer network supported by the same provider network. This is the same as in any other VPN model.
[RFC5251]で説明されるように、L1VPN Basic Modeは顧客アドレシング分野を互いに重なって、また、サービスプロバイダーアドレシング分野に重ならせます。 すなわち、顧客ネットワークは、プロバイダーネットワークによって使用されたアドレスを再利用して、同じプロバイダーネットワークによってサポートされた別の顧客ネットワークに使用されるアドレスを再利用するかもしれません。 これはいかなる他のVPNモデルとも同じです。
In addition, the L1VPN Basic Mode allows CE-to-PE control channel addressing realms to overlap. That is, a CE-to-PE control channel address (CE's address of this control channel and PE's address of this control channel) is unique within the L1VPN that the CE-to-PE control channel belongs to, but not necessarily unique across multiple L1VPNs.
さらに、L1VPN Basic ModeはCEからPEへのコントロールチャンネルアドレシング分野を重ならせます。 すなわち、CEからPEへの規制チャンネル・アドレス(CEのこの制御チャンネルのアドレスとPEのこの制御チャンネルのアドレス)は、CEからPEへの制御チャンネルが属すL1VPNの中でユニークですが、必ず複数のL1VPNsの向こう側にユニークであるというわけではありません。
Furthermore, once a L1VPN connection has been established, the L1VPN Basic Mode does not enforce any restriction on address assignment for this L1VPN connection (treated as a link) for customer network operation (e.g., IP network, MPLS network).
その上、L1VPN接続がいったん確立されると、L1VPN Basic Modeは顧客ネットワーク操作(例えば、IPネットワーク、MPLSネットワーク)のためのこのL1VPN接続(リンクとして扱われる)のためにどんな制限にもアドレス課題に押しつけません。
5. Provider Control of Its Infrastructure
5. インフラストラクチャのプロバイダーコントロール
5.1. Provisioning Model
5.1. モデルに食糧を供給します。
As described in [RFC5251], for each L1VPN that has at least one customer-facing port on a given PE, the PE maintains a Port Information Table (PIT) associated with that L1VPN. A PIT provides a cross-reference between Customer Port Indices (CPIs) and Provider Port Indices (PPIs) and contains a list of <CPI, PPI> tuples for all the ports within the L1VPN. In addition, for local PE ports of a given L1VPN, the PE retains an identifier known as the VPN-PPI, and this is stored in the PIT with the <CPI, PPI> tuples.
与えられたPEに少なくとも1つの顧客に面するポートを持っている各L1VPNのために[RFC5251]で説明されるように、PEはPort情報Table(PIT)をそのL1VPNに関連しているのに維持します。 PITはCustomer Port Indices(CPI)とProvider Port Indices(PPIs)の間に相互参照を供給して、<CPI(L1VPNの中のすべてのポートへのPPI>tuples)のリストを含んでいます。 さらに、与えられたL1VPNの地方のPEポートに関して、PEはVPN-PPIとして知られている識別子を保有します、そして、これはPITに<CPI(PPI>tuples)で保存されます。
Takeda Informational [Page 5] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[5ページ]のRFC5253
When a new CE belonging to one or more L1VPNs is added to a PE, PIT entries associated to those L1VPNs need to be configured on the PE. Section 4 of [RFC5251] specifies such procedures:
1L1VPNsに属す新しいCEがPEに加えられるとき、それらのL1VPNsに関連づけられたPITエントリーは、PEで構成される必要があります。 [RFC5251]のセクション4はそのような手順を指定します:
- If no PIT exists for the L1VPN on the PE, a new PIT is created by
the provider and associated with the VPN identifier.
- どんなPITもPEの上のL1VPNのために存在していないなら、新しいPITはプロバイダーによって作成されて、VPN識別子に関連づけられます。
- The PIT (new or pre-existing) is updated to include information
related to the newly added CE. The VPN-PPI, PPI, and CPI are
installed in the PIT. Note that the PPI is well-known by the PE,
but the CPI must be discovered either through manual configuration
or automatically by mechanisms such as the Link Management Protocol
(LMP) [RFC4204]. In addition, a CE-to-PE control channel needs to
be configured.
- 新たに加えられたCEに関連する情報を含むように、PIT(新しいか先在の)をアップデートします。 VPN-PPI、PPI、およびCPIはPITにインストールされます。 PPIがPEでよく知られますが、Link Managementプロトコル(LMP)[RFC4204]などのメカニズムで手動の構成か自動的のどちらかにCPIを発見しなければならないことに注意してください。 さらに、CEからPEへの制御チャンネルは、構成される必要があります。
- The updated PIT information needs to be configured in the PITs on
the remote PE associated with the L1VPN. For such purposes, manual
configuration or some sort of auto-discovery mechanisms can be
used. [RFC5195] and [RFC5252] specify alternative auto-discovery
mechanisms.
- アップデートされたPIT情報は、L1VPNに関連しているリモートPEの上のPITsで構成される必要があります。 そのような目的、手動の構成またはある種の自動発見のために、メカニズムを使用できます。 [RFC5195]と[RFC5252]は代替の自動発見メカニズムを指定します。
- In addition, remote PIT information associated with the L1VPN needs
to be configured on this PE if the PIT has been newly created.
Again, this can be achieved through manual configuration or through
auto-discovery; see [RFC5195] and [RFC5252].
- さらに、PITが新たに作成されたなら、L1VPNに関連しているリモートPIT情報は、このPEで構成される必要があります。 一方、手動の構成を通して、または、自動発見を通してこれを達成できます。 [RFC5195]と[RFC5252]を見てください。
When L1VPN membership of an existing CE changes, or when a CE is removed from a PE, similar procedures need to be applied to update the local and remote PITs.
既存のCEのL1VPN会員資格が変化するか、またはCEがPEから取り外されるとき、同様の手順は、地方の、そして、リモートなPITsをアップデートするために適用される必要があります。
5.2. PE-to-PE Segment Control
5.2. PEからPEへのセグメントコントロール
In the L1VPN Basic Mode, a PE-to-PE segment of a CE-to-CE L1VPN connection is completely under the control of the provider network.
L1VPN Basic Modeに、CEからCE L1VPNとの接続のPEからPEへのセグメントがプロバイダーネットワークのコントロールの完全下にあります。
5.2.1. Path Computation and Establishment
5.2.1. 経路計算と設立
A PE-to-PE segment of a CE-to-CE L1VPN connection may be established based on various policies. Those policies can be applied per L1VPN or per L1VPN connection. The policy is configured by the provider, possibly based on the contracts with each customer.
CEからCE L1VPNとの接続のPEからPEへのセグメントは様々な方針に基づいて確立されるかもしれません。 L1VPNかL1VPN接続単位でそれらの方針を適用できます。 方針はことによると各顧客との契約に基づいてプロバイダーによって構成されます。
Examples of PE-to-PE segment connection establishment polices supported in the L1VPN Basic Mode are as follows.
PEからPEとのセグメントL1VPN Basic Modeでサポートされて、設立が取り締まる接続の例は以下の通りです。
- Policy 1: On-demand establishment, on-demand path computation - Policy 2: On-demand establishment, pre-computed path - Policy 3: Pre-establishment, pre-computed path
- 方針1: 要求次第の設立、要求次第の経路計算--方針2: 要求次第の設立、あらかじめ計算された経路--方針3: プレ設立、あらかじめ計算された経路
Takeda Informational [Page 6] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[6ページ]のRFC5253
In each policy, the PE-to-PE path may be computed by the local PE or by a path computation entity outside of the local PE (e.g., a Path Computation Element (PCE) [RFC4655] or a management system).
各方針で、PEからPEへの経路は地方のPE(例えば、Path Computation Element(PCE)[RFC4655]かマネージメントシステム)の外で地方のPEか経路計算実体によって計算されるかもしれません。
In policies 2 and 3, pre-computation of paths (and pre-establishment if applicable) can be done at the network planning phase, or just before signaling (e.g., triggered by an off-line customer request). As the result of pre-computation (and pre-establishment), there could be multiple PE-to-PE segments for a specific pair of PEs. When a PE receives a Path message from a CE for a L1VPN connection, a PE needs to determine which PE-to-PE segment to use. In such cases, the provider may want to control:
方針2と3、経路のプレ計算、(プレ設立、適切である、)、ネットワーク計画フェーズですることができるか、または合図して(例えば、オフライン顧客の要求で、引き起こされます)、ちょうど以前、してください。 プレ計算(そして、プレ設立)の結果として、PEからPEへのPEsの特定の組において複数のセグメントがあるかもしれません。 PEがL1VPN接続のためにCEからPathメッセージを受け取るとき、PEは、PEからPEへのどのセグメントを使用したらよいかを決定する必要があります。 そのような場合、プロバイダーは制御したがっているかもしれません:
- Which L1VPN uses which PE-to-PE L1VPN segment. - Which CE-to-CE L1VPN connection uses which PE-to-PE L1VPN segment.
- どのL1VPNがPEからPE L1VPNへのどのセグメントを使用しますか? - CEからCE L1VPNとのどの接続がPEからPE L1VPNへのどのセグメントを使用しますか?
The former requires mapping between the PIT and the PE-to-PE segment. The latter requires some more sophisticated mapping method, for example:
前者は、PITとPEからPEへのセグメントの間で写像するのを必要とします。 例えば、後者はそれ以上の高度なマッピング法を必要とします:
- Mapping between individual PIT entries and PE-to-PE segments.
- Use of a Path Key ID [CONF-SEG] supplied by the provider to the CE,
and signaled by the CE as part of the L1VPN connection request.
- 個々のPITエントリーとPEからPEへのセグメントの間で写像します。 - プロバイダーによってCEに供給されて、L1VPN接続要求の一部としてCEによって合図されたPath Key ID[CONF-SEG]の使用。
The L1VPN Basic Mode does not preclude usage of other methods, if applicable.
適切であるなら、L1VPN Basic Modeは他のメソッドの用法を排除しません。
In policy 3, stitching or nesting is necessary in order to map the CE-to-CE L1VPN connection to a pre-established PE-to-PE segment.
方針3で、ステッチか巣篭もりが、PEからPEへのプレ確立したセグメントにCEからCE L1VPNとの接続を写像するのに必要です。
5.2.2. Resource Management
5.2.2. 資源管理
The provider network may operate resource management based on various policies. These policies can be applied per L1VPN or per L1VPN connection. The policy is configured by the provider, possibly based on the contracts with each customer.
プロバイダーネットワークは様々な方針に基づく資源管理を経営するかもしれません。 L1VPNかL1VPN接続単位でこれらの方針を適用できます。 方針はことによると各顧客との契約に基づいてプロバイダーによって構成されます。
For example, a provider may choose to partition the resources of the provider network for limited use by different L1VPNs or customers. Such a function might be achieved within the scope of the Basic Mode using resource affinities [RFC3209], but the details of per-L1VPN resource models (especially in terms of CE-to-PE routing) are considered as part of the Enhanced Mode.
例えば、プロバイダーは、異なったL1VPNsか顧客による限られた使用のためにプロバイダーネットワークに関するリソースを仕切るのを選ぶかもしれません。 そのような機能はBasic Modeの範囲の中でリソースの親近感[RFC3209]を使用することで獲得されるかもしれませんが、1L1VPNあたりのリソースモデル(特にCEからPEへのルーティングによる)の細部はEnhanced Modeの一部であるとみなされます。
Takeda Informational [Page 7] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[7ページ]のRFC5253
5.2.3. Consideration of CE-to-PE Traffic Engineering Information
5.2.3. CeからPEへのトラフィック技術情報連合社の考慮
[RFC5252] and [BGP-TE] allow CE-to-PE Traffic Engineering (TE) link information to be injected into the provider network, and in particular to be exchanged between PEs. This may be helpful for the ingress PE to prevent connection setup failure due to lack of resources or incompatible switching capabilities on remote CE-to-PE TE links.
[RFC5252]と[BGP-TE]は、CEからPE Traffic Engineering(TE)へのリンク情報がPEsの間で交換するためにプロバイダーネットワークの中と、そして、特定で注入されるのを許容します。 イングレスPEが財源不足か両立しないスイッチング能力のためCEからPE TEへのリモートリンクの上に接続設定失敗を防ぐように、これは役立っているかもしれません。
Furthermore, the L1VPN Basic Mode allows a remote CE to be reached through more than one TE link connected to the same PE (single-homed) or to different PEs (dual-homed). In such cases, to facilitate route choice, the ingress CE needs to initiate signaling by specifying the egress CE's router ID, not the egress CPI, in the Session Object and the Explicit Route Object (ERO), if present, so as to not constrain the choice of route within the provider network. Therefore, the CE's router ID needs to be configured in the PITs.
その上、L1VPN Basic Modeが、リモートCEに同じPE(シングル家へ帰る)、または、異なったPEsに接続された1個以上のTEリンクを通して達するのを許容する、(二元的である、-、家へ帰り、) そのような場合、ルート選択を容易にするのに、イングレスCEは、出口CPIではなく、出口CEのルータIDを指定することによってシグナリングを開始する必要があります、Session ObjectとExplicit Route Object(ERO)で、存在しているなら、プロバイダーネットワークの中でルートの選択を抑制しないように。 したがって、CEのルータIDは、PITsで構成される必要があります。
Note that, as described in Section 7.2, consideration of the full feature set enabled by dual-homing (such as resiliency) is out of scope of the L1VPN Basic Mode.
L1VPN Basic Modeの範囲の外にデュアルホーミング(弾性などの)で可能にされた完全な特徴セットの考慮がセクション7.2で説明されるようにあることに注意してください。
5.3. Connectivity Restriction
5.3. 接続性制限
The L1VPN Basic Mode allows restricting connection establishment between CEs belonging to the same L1VPN for policy reasons (including L1VPN security). Since the PIT at each PE is associated with a L1VPN, this function can be easily supported. The restriction can be applied at the ingress PE or at the egress PE according to the applicable restriction policy, but note that applying the policy at the egress may waste signaling effort within the network as L1VPN connections are pointlessly attempted.
L1VPN Basic Modeは、方針理由で同じL1VPNに属しながら(L1VPNセキュリティを含んでいて)、CEsの間でコネクション確立を制限させます。 各PEのPITがL1VPNに関連しているので、容易にこの機能をサポートできます。 イングレスPEにおいて、または、適切な制限方針に従った出口PEにおいて制限を適用できますが、出口で方針を適用するとL1VPN接続が無意味に試みられるときシグナリング取り組みがネットワークの中で浪費されるかもしれないことに注意してください。
In addition, the L1VPN Basic Mode does not restrict use of any advanced admission control based on various policies.
さらに、L1VPN Basic Modeは様々な方針に基づくどんな高度な入場コントロールの使用も制限しません。
6. Customer Control of Its L1VPN
6. L1VPNの顧客コントロール
6.1. Topology Control
6.1. トポロジーコントロール
In the L1VPN Basic Mode, L1VPN connection topology is controlled by the customer. That is, a customer can request setup/deletion/modification of L1VPN connections using signaling mechanisms specified in [RFC5251].
L1VPN Basic Modeでは、L1VPN接続形態は顧客によって制御されます。 すなわち、顧客は、[RFC5251]で指定されたシグナル伝達機構を使用することでL1VPN接続のセットアップ/削除/変更を要求できます。
Takeda Informational [Page 8] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[8ページ]のRFC5253
Also note that if there are multiple CE-to-PE TE links (single-homed or multi-homed), a customer can specify which CE-to-PE TE link to use to support any L1VPN connection. Alternatively, a customer may let the provider choose the CE-to-PE TE link at the egress side, as described in Section 5.2.3.
または、また、CEからPE TEへの複数のリンクがあればそれに注意してください、(シングル家へ帰る、マルチ、家へ帰り、)、顧客は、何かL1VPN接続をサポートするのにCEからPE TEへのどのリンクを使用したらよいかを指定できます。 あるいはまた、顧客はプロバイダーに出口の側でCEからPE TEへのリンクを選ばせるかもしれません、セクション5.2.3で説明されるように。
6.2. Note on Routing
6.2. ルート設定に関する注
A CE needs to obtain the remote CPI to which it wishes to request a connection. Since, in the L1VPN Basic Mode, there is no routing information exchange between a CE and a PE, there is no dynamic mechanism supported as part of the Basic Mode L1VPN service, and the knowledge of remote CPIs must be acquired in a L1VPN-specific way, perhaps through configuration or through a directory server.
CEは、それが接続を要求したがっているリモートCPIを得る必要があります。 CEとPEの間には、ルーティング情報交換が全くL1VPN Basic Modeにないので、Basic Mode L1VPNサービスの一部としてサポートされたどんなダイナミックなメカニズムもありません、そして、恐らく構成を通して、または、L1VPN特有の道か、ディレクトリサーバを通してリモートCPIに関する知識を習得しなければなりません。
If an L1VPN is used by a customer to operate a private IP network, the customer may wish to form routing adjacencies over the CE-to-CE L1VPN connections. The L1VPN Basic Mode does not enforce any restriction on such operation by a customer, and the use made of the L1VPN connections is transparent to the provider network.
L1VPNがプライベートアイピーネットワークを経営するのに顧客によって使用されるなら、顧客はCEからCE L1VPNとの接続の上にルーティング隣接番組を形成したがっているかもしれません。 L1VPN Basic Modeはどんな制限にも顧客によるそのような操作に押しつけません、そして、L1VPN接続でされた使用はプロバイダーネットワークにわかりやすいです。
Furthermore, if an L1VPN is used by a customer to operate a private Multiprotocol Label Switching (MPLS) or GMPLS network, the customer may wish to treat a L1VPN connection as a TE link, and this requires a CE-to-CE control channel. Note that a Forwarding Adjacency [RFC4206] cannot be formed from the CE-to-CE L1VPN connection in the Basic Mode because there is no routing exchange between CE and PE. That is, the customer network and the provider network do not share a routing instance, and the customer control channel cannot be carried within the provider control plane. But where the CE provides suitable adaptation (for example, where the customer network is a packet- switched MPLS or GMPLS network), the customer control channel may be in-band and a routing adjacency may be formed between the CEs using the L1VPN connection. Otherwise, CE-to-CE control plane connectivity may form part of the L1VPN service provided to the customer by the provider and may be achieved within the L1VPN connection (for example, through the use of overhead bytes) or through a dedicated control channel connection or tunnel. The options available are discussed further in Section 10.2 of [RFC4847].
その上、L1VPNが個人的なMultiprotocol Label Switching(MPLS)かGMPLSネットワークを経営するのに顧客によって使用されるなら、顧客はTEリンクとしてL1VPN接続を扱いたがっているかもしれません、そして、これはCEからCEへの制御チャンネルを必要とします。 CEとPEの間には、ルーティング交換が全くないので、Basic ModeでCEからCE L1VPNとの接続からForwarding Adjacency[RFC4206]を形成できないことに注意してください。 すなわち、顧客ネットワークとプロバイダーネットワークはルーティングインスタンスを共有しません、そして、プロバイダー制御飛行機の中に顧客制御チャンネルは運ぶことができません。 しかし、CEが適当な適合を提供するところで(顧客ネットワークが例えば切り換えられたMPLSかGMPLSがネットワークでつなぐパケットであるところで)顧客制御チャンネルはバンドであるかもしれません、そして、ルーティング隣接番組は、CEsの間でL1VPN接続を使用することで形成されるかもしれません。 さもなければ、CEからCEへのコントロール飛行機接続性は、プロバイダーで顧客に提供されたL1VPNサービスの一部を形成して、L1VPN接続(例えばオーバーヘッドバイトの使用で)以内かひたむきなコントロールチャンネル接続かトンネルを通って達成されるかもしれません。 [RFC4847]のセクション10.2で、より詳しく利用可能なオプションについて議論します。
Takeda Informational [Page 9] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[9ページ]のRFC5253
7. Scalability and Resiliency
7. スケーラビリティと弾性
7.1. Scalability
7.1. スケーラビリティ
There are several factors that impact scalability.
スケーラビリティに影響を与えるいくつかの要素があります。
o Number of L1VPNs (PITs) configured on each PE
o 各PEで構成されたL1VPNs(PITs)の数
With the increase of this number, information to be maintained on
the PE increases. Theoretically, the upper limit of the number of
L1VPNs supported in a provider network is governed by how the ID
associated with a L1VPN is allocated, and the number of PITs
configured on each PE is limited by this number. However,
implementations may impose arbitrary limits on the number of PITs
supported by any one PE.
この数の増加によると、PEで保守される情報は増加します。 理論的に、プロバイダーネットワークでサポートされたL1VPNsの数の上限はどうL1VPNに関連しているIDを割り当てるかによって支配されます、そして、各PEで構成されたPITsの数はこの数によって制限されます。 しかしながら、実装はどんなPEによってもサポートされたPITsの数に任意の限界を課すかもしれません。
o Number of CE-to-PE TE links for each L1VPN
o 各L1VPNのためのCEからPE TEへのリンクの数
With the increase of this number, information to be maintained in
each PIT increases. When auto-discovery mechanisms are used, the
amount of information that an auto-discovery mechanism can support
may restrict this number.
この数の増加によると、各PITで保守される情報は増加します。 自動発見メカニズムが使用されているとき、自動発見メカニズムがサポートすることができる情報量はこの数を制限するかもしれません。
Note that [RFC5252] floods membership information not only among
PEs, but also to all P nodes. This may lead to scalability
concerns, compared to [RFC5195], which distributes membership
information only among PEs. Alternatively, a separate instance of
the OSPF protocol can be used just between PEs for distributing
membership information. In such a case, Ps do not participate in
flooding.
[RFC5252]がPEsへあふれるだけではなく、すべてのPノードへも会員資格情報をあふれさせることに注意してください。 [RFC5195](会員資格情報をPEsだけに分配する)と比べて、これはスケーラビリティ関心に通じるかもしれません。 あるいはまた、会員資格情報を分配するのにPEsのすぐ間でOSPFプロトコルの別々のインスタンスを使用できます。 このような場合には、Psは氾濫に参加しません。
Note that in the L1VPN Basic Mode, a PE needs to obtain only CE-
to-PE TE link information, and not customer routing information,
which is quite different from the mode of operation of an L3VPN.
Therefore, the scalability concern is considered to be less
problematic.
L1VPN Basic Modeでは、PEが、顧客ルーティング情報ではなく、PE TEへのCEリンク情報だけを得る必要に注意してください。情報はL3VPNの運転モードと全く異なっています。 したがって、スケーラビリティ関心がそれほど問題が多くないと考えられます。
o Number of L1VPN connections
o L1VPN接続の数
With the increase of this number, information to be maintained on
each PE/P increases. When stitching or nesting is used, the state
to be maintained at each PE increases compared to when connectivity
is achieved without stitching or nesting.
この数の増加によると、各PE/Pで保守される情報は増加します。 ステッチか巣篭もりが使用されているとき、接続性がステッチも巣篭もりなしで達成される時と比べて、各PEで維持される状態は増加します。
However, in a Layer 1 core, this number is always bounded by the
available physical resource because each LSP uses a separate label
which is directly bound to a physical, switchable resource
Layer1コアのこの数はいつもどのように境界があっても、利用可能な物理資源で、各LSPが別々のラベルを使用するので、どれが直接物理的で、スイッチできるリソースに縛られますか?
Takeda Informational [Page 10] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[10ページ]のRFC5253
(timeslot, lambda, or fiber). Thus, it can be safely assumed that
the PEs/Ps can comfortably handle the number of LSPs that they may
be called on to switch for a L1VPN.
(timeslot、λ、またはファイバー。) したがって、安全に、PEs/Psがゆったり彼らがL1VPNのために切り換えるよう呼びかけられるかもしれないLSPsの数を扱うことができると思うことができます。
7.2. Data Plane Resiliency
7.2. データ飛行機の弾性
The L1VPN Basic Mode supports the following data plane recovery techniques [RFC5251].
L1VPN Basic Modeは、以下のデータが飛行機リカバリ技術[RFC5251]であるとサポートします。
o PE-to-PE segment recovery
o PEからPEへのセグメント回復
The CE indicates to protect the PE-to-PE segment by including
Protection Object specified in [RFC4873] in the Path message and
setting Segment Recovery Flags. The CE may also indicate the
branch and merge nodes by including a Secondary Explicit Route
Object.
CEは、Protection Objectを含んでいることによってPEからPEへのセグメントを保護するのがPathメッセージとSegment Recovery Flagsを設定することにおける[RFC4873]で指定したのを示します。 CEは、また、ブランチを示して、Secondary Explicit Route Objectを含んでいることによって、ノードを合併するかもしれません。
Depending on the signaling mechanisms used within the provider
network, details on how to protect the PE-to-PE segment may differ
as follows.
プロバイダーネットワークの中で使用されたシグナル伝達機構によって、どうPEからPEへのセグメントを保護するかに関する詳細は以下の通り異なるかもしれません。
- If LSP stitching or LSP hierarchy are used to provision the PE-
to-PE segment, then the PE-to-PE LSP may be protected using end-
to-end recovery within the provider network.
- LSPステッチかLSP階層構造が次に、PEへのPEセグメント、PE LSPへのPEがそうする支給に使用されるなら、プロバイダーネットワークの中で終わりへの終わりの回復を使用することで、保護されてください。
- If the CE-to-CE L1VPN connection is a single end-to-end LSP
(including if session shuffling is used), then the PE-to-PE LSP
segment may be protected using segment protection [RFC4873].
- CEからCE L1VPNとの接続がただ一つの終わりから終わりへのLSP(セッションシャッフルが使用されているかどうかを含んでいて)であるなら、PEからPE LSPへのセグメントは、セグメント保護[RFC4873]を使用することで保護されるかもしれません。
o CE-to-PE recovery and PE-to-PE recovery via link protection
o リンク保護を通したCEからPEへの回復とPEからPEへの回復
The CE indicates to protect ingress and egress CE-to-PE links as
well as links within the provider network by including the
Protection Object specified in [RFC3473] and setting Link Flags in
the Path message.
CEは、Protection Objectを含んでいることによってプロバイダーネットワークの中のリンクと同様にイングレスと出口CEからPEへのリンクを保護するのが[RFC3473]とPathメッセージにLink Flagsをはめ込む際に指定したのを示します。
- The ingress and egress CE-to-PE link may be protected at a lower
layer.
- イングレスと出口CEからPEへのリンクは下層で保護されるかもしれません。
Depending on the signaling mechanisms used within the provider
network, details on how to protect links within the provider
network may differ as follows.
プロバイダーネットワークの中で使用されたシグナル伝達機構によって、プロバイダーネットワークの中にどうリンクを保護するかに関する詳細は以下の通り異なるかもしれません。
- If the PE-to-PE segment is provided as a single TE link
(stitching or hierarchy) so that the provider network can perform
simple PE-to-PE routing, then the TE link may offer link-level
protection through the instantiation of multiple PE-to-PE LSPs.
- プロバイダーネットワークがPEからPEへの簡単なルーティングを実行できるように単一のTEリンク(ステッチか階層構造)としてPEからPEへのセグメントを提供するなら、TEリンクは複数のPEからPE LSPsの具体化を通してリンク・レベル保護を提供するかもしれません。
Takeda Informational [Page 11] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[11ページ]のRFC5253
- The PE-to-PE segment may be provisioned using only link-protected
links within the core network.
- コアネットワークの中でリンクで保護されたリンクだけを使用することでPEからPEへのセグメントは食糧を供給されるかもしれません。
Note that it is not possible to protect only the CE-to-PE portion or the PE-to-PE portion by link protection because the CE-to-CE signaling request asks for a certain level of link protection on all links used by the LSP. Also, it is not possible to protect the CE- to-PE portion by link recovery and the PE-to-PE portion by segment recovery at the same time.
CEからCEへのシグナリング要求がLSPによって使用されたすべてのリンクの上に、あるレベルのリンク保護を求めるので、リンク保護でCEからPEへの部分かPEからPEへの部分だけを保護するのが可能でないことに注意してください。 また、同時にリンク回復とPEからPEへの部分のそばにセグメント回復でPEへのCE部分を保護するのも可能ではありません。
CE-to-CE recovery through the use of connections from one CE to diverse PEs (i.e., dual-homing) is not supported in the L1VPN Basic Mode.
CEからCEへの接続の1CEからさまざまのPEs(すなわち、デュアルホーミング)までの使用による回復はL1VPN Basic Modeでサポートされません。
7.3. Control Plane Resiliency
7.3. コントロール飛行機の弾性
The L1VPN Basic Mode allows use of GMPLS control plane resiliency mechanisms. This includes, but is not limited to, control channel management in LMP [RFC4204] and fault handling in RSVP-TE ([RFC3473] and [RFC5063]) between a CE and a PE, as well as within the provider network.
L1VPN Basic Modeは含んでいますが、メカニズムこれが制限されないGMPLSコントロール飛行機の弾性の使用とLMPのコントロールチャンネル管理[RFC4204]とCEとPEと、プロバイダーネットワークの中のRSVP-TEの欠点取り扱い([RFC3473]と[RFC5063])を許します。
8. Security Considerations
8. セキュリティ問題
Security considerations are described in [RFC4847], and this section describes how these considerations are addressed in the L1VPN Basic Mode.
セキュリティ問題は[RFC4847]で説明されます、そして、このセクションはこれらの問題がL1VPN Basic Modeでどう扱われるかを説明します。
Additional discussion of GMPLS security can be found in [GMPLS-SEC].
[GMPLS-SEC]でGMPLSセキュリティの追加議論を見つけることができます。
8.1. Topology Confidentiality
8.1. トポロジー秘密性
As specified in [RFC5251], a provider's topology confidentiality is preserved by the Basic Mode. Since there is no routing exchange between PE and CE, the customer network can gather no information about the provider network. Further, as described in Section 4 of [RFC4208], a PE may filter the information present in a Record Route Object (RRO) that is signaled from the provider network to the customer network. In addition, as described in Section 5 of [RFC4208] and Section 4.4 of [RFC5251], when a Notify message is sent to a CE, it is possible to hide the provider internal address. This is accomplished by a PE updating the Notify Node Address with its own address when the PE receives a NOTIFY_REQUEST object from the CE.
[RFC5251]で指定されるように、プロバイダーのトポロジー秘密性はBasic Modeによって保存されます。 PEとCEの間には、ルーティング交換が全くないので、顧客ネットワークはプロバイダーネットワークの情報を全く集めることができません。 さらに、[RFC4208]のセクション4で説明されるように、PEはプロバイダーネットワークから顧客ネットワークまで合図されるRecord Route Object(RRO)の現在の情報をフィルターにかけるかもしれません。 NotifyメッセージをCEに送るとき、さらに、プロバイダーの内部のアドレスを隠すのは[RFC4208]のセクション5と[RFC5251]のセクション4.4で説明されるように可能です。 これはPEがCEからNOTIFY_REQUESTオブジェクトを受けるときそれ自身のアドレスでNotify Node AddressをアップデートするPEによって達成されます。
Even in the case of pre-computed and/or pre-signaled PE-to-PE segments, provider topology confidentiality may be preserved through the use of path key IDs [CONF-SEG].
PEからPEへのあらかじめ計算されたそして/または、あらかじめ合図されたセグメントの場合ではさえ、プロバイダートポロジー秘密性は経路の主要なID[CONF-SEG]の使用で保存されるかもしれません。
Takeda Informational [Page 12] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[12ページ]のRFC5253
The customer's topology confidentiality cannot be completely hidden from the provider network. At the least, the provider network will know about the addresses and locations of CEs. Other customer topology information will remain hidden from the provider in the Basic Mode, although care may be needed to protect the customer control channel as described in Section 8.4.
完全に顧客のトポロジー秘密性をプロバイダーネットワークから隠すことができるというわけではありません。 少なくとも、プロバイダーネットワークはCEsのアドレスと位置に関して知るでしょう。 プロバイダー隠されたままで、他の顧客トポロジー情報はBasic Modeに残るでしょう、注意がセクション8.4で説明されるように顧客制御チャンネルを保護するのに必要であるかもしれませんが。
The provider network is responsible for maintaining confidentiality of topology information between customers and across L1VPNs. Since there is no distribution of routing information from PE to CE in the Basic Mode, there is no mechanism by which the provider could accidentally, or deliberately but automatically, distribute this information.
プロバイダーネットワークは顧客の間と、そして、L1VPNsの向こう側にトポロジー情報の秘密性を維持するのに責任があります。 ルーティング情報のPEからCEまでの分配が全くBasic Modeにないので、プロバイダーが偶然、または故意にそうすることができたメカニズムが全くありませんが、自動的に、この情報を分配してください。
8.2. External Control of the Provider Network
8.2. プロバイダーネットワークの外部のコントロール
The provider network is protected from direct control from within customer networks through policy and through filtering of signaling messages.
プロバイダーネットワークは顧客ネットワークから方針を通したシグナリングメッセージのフィルタリングを通した直轄から保護されます。
There is a service-based policy installed at each PE that directs how a PE should react to a L1VPN connection request received from any CE. Each CE is configured at the PE (or through a policy server) for its membership of a L1VPN, and so CEs cannot dynamically bind to a PE or join a L1VPN. With this configuration comes the policy that tells the PE how to react to a L1VPN connection request (for example, whether to allow dynamic establishment of PE-to-PE connections). Thus, the provider network is protected against spurious L1VPN connection requests and can charge for all L1VPN connections according to the service agreement with the customers. Hence, the provider network is substantially protected against denial-of-service (DoS) attacks.
PEがどうどんなCEからも受け取られたL1VPN接続要求に反応するはずであるかを指示する各PEにインストールされたサービスベースの方針があります。 各CEがL1VPNの会員資格のためにPE(または方針サーバを通して)で構成されるので、CEsはダイナミックにPEに付くことができませんし、L1VPNを接合できません。 この構成と共に、L1VPN接続要求に反応する方法をPEに教える方針が来ている、(例えば、PEからPEとの接続のダイナミックな設立を許容するかどうか、) したがって、プロバイダーネットワークは、偽りのL1VPN接続要求に対して保護されて、顧客とのサービス契約通りにすべてのL1VPN接続に課金できます。 したがって、プロバイダーネットワークはサービスの否定(DoS)攻撃に対して実質的に保護されます。
At the same time, if a Path message from a CE contains an Explicit Route Object (ERO) specifying the route within provider network, it is rejected by the PE. Thus, the customer network has no control over the resources in the provider network.
同時に、CEからのPathメッセージがプロバイダーネットワークの中でルートを指定しながらExplicit Route Object(ERO)を含んでいるなら、それはPEによって拒絶されます。 したがって、顧客ネットワークはプロバイダーネットワークでリソースを管理しません。
8.3. Data Plane Security
8.3. データ飛行機セキュリティ
As described in [RFC4847], at Layer 1, data plane information is normally assumed to be secure once connections are established since the optical signals themselves are normally considered to be hard to intercept or modify, and it is considered difficult to insert data into an optical stream. The very use of an optical signal may be considered to provide confidentiality and integrity to the payload data. Furthermore, as indicated in [RFC4847], L1VPN connections are
[RFC4847]で説明されるLayer1では、妨害するか、または光学信号自体が変更しにくいと通常考えられるので接続がいったん確立されると通常、データ飛行機情報が安全であると思われて、それは光学ストリームにデータを挿入するのが難しいと考えられます。 光学信号のまさしくその使用が秘密性と保全をペイロードデータに提供すると考えられるかもしれません。 その上、[RFC4847]にみられるように、L1VPN接続はそうです。
Takeda Informational [Page 13] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[13ページ]のRFC5253
each dedicated to a specific L1VPN by which an additional element of security for the payload data is provided.
ペイロードデータのためのセキュリティの追加要素が提供される特定のL1VPNに捧げられたそれぞれ。
Misconnection remains a security vulnerability for user data. If a L1VPN connection were to be misconnected to the wrong destination, user data would be delivered to the wrong consumers. In order to protect against mis-delivery, each L1VPN connection is restricted to use only within a single L1VPN. That is, a L1VPN connection does not connect CEs that are in different L1VPNs. In order to realize this, the identity of CEs is assured as part of the service contract. And upon receipt of a request for connection setup, the provider network assures that the connection is requested between CEs belonging to the same L1VPN. This is achieved as described in Section 5.3.
付け違いは利用者データのためのセキュリティの脆弱性のままで残っています。 L1VPN接続が間違った目的地に付け違いされることになっているなら、利用者データは間違った消費者に提供されるでしょうに。 誤配送から守って、それぞれのL1VPN接続は、中だけで独身のL1VPNを使用するために制限されます。 すなわち、L1VPN接続は異なったL1VPNsにあるCEsを接続しません。 これがわかるために、CEsのアイデンティティは役務契約の一部として保証されます。 そして、接続設定を求める要求を受け取り次第、プロバイダーネットワークは、接続が同じL1VPNに属しながらCEsの間で要求されていることを保証します。 これはセクション5.3で説明されるように達成されます。
Furthermore, users with greater sensitivity to the security of their payload data should apply appropriate security measures within their own network layer. For example, a customer exchanging IP traffic over a L1VPN connection may choose to use IPsec to secure that traffic (i.e., to operate IPsec on the CE-to-CE exchange of IP traffic).
その上、彼らのペイロードデータのセキュリティへの、より大きい感度をもっているユーザはそれら自身のネットワーク層の中で適切な安全策を適用するべきです。 例えば、L1VPN接続の上とIPトラフィックを交換する顧客は、そのトラフィック(すなわち、CEからCEへのIPトラフィックの交換のときにIPsecを操作する)を保証するのにIPsecを使用するのを選ぶかもしれません。
8.4 Control Plane Security
8.4 コントロール飛行機セキュリティ
There are two aspects for control plane security.
コントロール飛行機セキュリティのための2つの局面があります。
First, the entity connected over a CE-to-PE control channel must be identified. This is done when a new CE is added as part of the service contract and the necessary control channel is established. This identification can use authentication procedures available in RSVP-TE [RFC3209]. That is, control plane entities are identified within the core protocols used for signaling, but are not authenticated unless the authentication procedures of [RFC3209] are used.
まず最初に、CEからPEへの制御チャンネルの上に接された実体を特定しなければなりません。 役務契約の一部と必要な制御チャンネルを確立するとき新しいCEを加えるとき、これをします。 この識別はRSVP-TE[RFC3209]で利用可能な認証手順を用いることができます。 すなわち、コントロール飛行機実体は、シグナリングに使用されるコアプロトコルの中で特定されますが、[RFC3209]の認証手順が使用されていない場合、認証されません。
Second, it must be possible to secure communication over a CE-to-PE control channel. If a communication channel between the customer and the provider (control channel, management interface) is physically separate per customer, the communication channel could be considered as secure. However, when the communication channel is physically shared among customers, security mechanisms need to be available and should be enforced. RSVP-TE [RFC3209] provides for tamper-protection of signaling message exchanges through the optional Integrity object. IPsec tunnels can be used to carry the control plane messages to further ensure the integrity of the signaling messages.
2番目に、CEからPEへの制御チャンネルの上にコミュニケーションを保証するのは可能でなければなりません。 顧客とプロバイダー(制御チャンネル、管理は連結する)の間の通信チャネルが顧客単位で肉体的に別々であるなら、通信チャネルは安全であるとみなされるかもしれません。 しかしながら、通信チャネルが顧客の中で物理的に共有されるとき、セキュリティー対策は、利用可能であることが必要であり、励行されるべきです。 RSVP-TE[RFC3209]は任意のIntegrityオブジェクトを通したシグナリング交換処理のタンパー保護に備えます。 さらにシグナリングメッセージの保全を確実にするコントロール飛行機メッセージを伝えるのにIPsecトンネルを使用できます。
Note that even in the case of physically separate communication channels, customers may wish to apply security mechanisms, such as
肉体的に別々の通信チャネルの場合ではさえ、顧客がセキュリティー対策を適用したがっているかもしれないことに注意してください。
Takeda Informational [Page 14] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[14ページ]のRFC5253
IPsec, to assure higher security, and such mechanisms must be available.
IPsec、より高いセキュリティ、およびそのようなものにメカニズムを保証するのは利用可能であるに違いありません。
Furthermore, the provider network needs mechanisms to detect DoS attacks and to protect against them reactively and proactively. In the Basic Mode, this relies on management systems. For example, management systems collect and analyze statistics on signaling requests from CEs, and protect against malicious behaviors where necessary.
その上、プロバイダーネットワークは、DoS攻撃を検出して、それらから反動的に守って、予測するためにメカニズムを必要とします。 Basic Modeでは、これはマネージメントシステムを当てにします。例えば、マネージメントシステムは、CEsからのシグナリング要求における統計を集めて、分析して、必要であるところで悪意のある態度から守ります。
Lastly, it should be noted that customer control plane traffic carried over the provider network between CEs needs to be protected. Such protection is normally the responsibility of the customer network and can use the security mechanisms of the customer signaling and routing protocols (for example, RSVP-TE [RFC3209]) or may use IPsec tunnels between CEs. CE-to-CE control plane security may form part of the data plane protection where the control plane traffic is carried in-band in the L1VPN connection. Where the CE-to-CE control plane connectivity is provided as an explicit part of the L1VPN service by the provider, control plane security should form part of the service agreement between the provider and customer.
最後に、CEsの間のプロバイダーネットワークの上まで運ばれた顧客コントロール飛行機通行が、保護される必要に注意されるべきです。 そのような保護は、通常顧客ネットワークの責任であり、顧客シグナリングとルーティング・プロトコル(例えば、RSVP-TE[RFC3209])のセキュリティー対策を使用できるか、またはCEsの間のIPsecトンネルを使用するかもしれません。 CEからCEへのコントロール飛行機セキュリティはコントロール飛行機通行がL1VPN接続でバンドで運ばれるデータ飛行機保護の一部を形成するかもしれません。 L1VPNサービスの明白な部分としてプロバイダーでCEからCEへのコントロール飛行機接続性を提供するところでは、コントロール飛行機セキュリティはプロバイダーと顧客とのサービス契約の一部を形成するべきです。
9. Manageability Considerations
9. 管理可能性問題
Manageability considerations are described in [RFC4847]. In the L1VPN Basic Mode, we rely on management systems for various aspects of the different service functions, such as fault management, configuration and policy management, accounting management, performance management, and security management (as described in Section 8).
管理可能性問題は[RFC4847]で説明されます。 L1VPN Basic Modeでは、私たちは異なったサービス機能の種々相のマネージメントシステムを当てにします、障害管理や、構成や、政策管理や、会計管理や、パフォーマンス管理や、セキュリティ管理などのように(セクション8で説明されるように)。
In order to support various management functionalities, MIB modules need to be supported. In particular, the GMPLS TE MIB (GMPLS-TE-STD- MIB) [RFC4802] can be used for GMPLS-based traffic engineering configuration and management, while the TE Link MIB (TE-LINK-STD-MIB) [RFC4220] can be used for configuration and management of TE links.
様々な管理の機能性をサポートするために、MIBモジュールは、サポートされる必要があります。 特に、GMPLSベースの交通工学構成と管理に、GMPLS TE MIB(GMPLS-TE-STD- MIB)[RFC4802]を使用できます、TEリンクの構成と管理に、TE Link MIB(TE-LINK-STD-MIB)[RFC4220]を使用できますが。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
label switching Architecture", RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathanとA.とR.Callon、「Multiprotocolラベル切り換えArchitecture」、RFC3031 2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
Takeda Informational [Page 15] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[15ページ]のRFC5253
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3471] エドバーガー、L.、RFC3471、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は機能的な記述を示す」1月2003日
[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)拡大」、RFC3473、2003年1月。
[RFC4026] Anderssion, L. and Madsen, T., "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
[RFC4026] AnderssionとL.とマドセン、T.、「プロバイダーの食糧を供給された仮想私設網(VPN)用語」、RFC4026、2005年3月。
[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)をラベルします」、RFC4202、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] ツバメ、G.、ドレイク、J.、Ishimatsu、H.、およびY.Rekhter、「一般化されたMultiprotocolはユーザネットワーク・インターフェース(UNI)と切り換え(GMPLS)をラベルします」。 「オーバレイモデルの資源予約プロトコル交通工学(RSVP-Te)サポート」、RFC4208、2005年10月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1
Virtual Private Networks", RFC 4847, April 2007.
[RFC4847] 竹田、T.、エド、「仮想の兵士がネットワークでつなぐ層1のためのフレームワークと要件」、RFC4847、4月2007日
[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セグメント回復」、RFC4873は2007がそうするかもしれません。
[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、「層-1VPNsのためのBGPベースの自動発見」、RFC5195、2008年6月。
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D.,
Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC
5251, July 2008.
[RFC5251]Fedyk、D.(エド)、Rekhter、Y.(エド)、Papadimitriou、D.、Rabbat、R.、およびL.バーガー、「1つの層のVPNの基本のモード」、RFC5251(2008年7月)。
[RFC5252] Bryskin, I. and Berger, L., "OSPF-Based Layer 1 VPN Auto-
Discovery", RFC 5252, July 2008.
[RFC5252] BryskinとI.とバーガー、L.、「OSPFベースの層1のVPN自動発見」、RFC5252、2008年7月。
10.2. Informative References
10.2. 有益な参照
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4204] ラング、J.、エド、「リンク管理プロトコル(LMP)」、RFC4204、10月2005日
[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)を階層構造とラベルします」、RFC4206、2005年10月。
Takeda Informational [Page 16] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[16ページ]のRFC5253
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering
Link Management Information Base", RFC 4220, November
2005.
[RFC4220] ドュバックとM.とナドー、T.とJ.ラング、「交通工学リンク管理情報ベース」、RFC4220、2005年11月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4655] ファレル、A.、Vasseur、J.-P.、およびJ.灰、「経路の計算の要素の(PCE)ベースのアーキテクチャ」、RFC4655、2006年8月。
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic
Engineering Management Information Base", RFC 4802,
February 2007.
[RFC4802]ナドー(T.(エド)、およびA.ファレル(エド))は、「Multiprotocolラベルの切り換え(GMPLS)トラフィック技術管理部会を一般化しました」、RFC4802、2007年2月。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions
to GMPLS Resource Reservation Protocol (RSVP) Graceful
Restart", RFC 5063, October 2007.
[RFC5063]Satyanarayana、A.(エド)、およびR.ラーマン(エド)、「GMPLS資源予約への拡大は(RSVP)優雅な再開について議定書の中で述べます」、RFC5063、2007年10月。
[BGP-TE] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "Traffic
Engineering Attribute", Work in Progress, January 2008.
H.とFedyk、D.とY.Rekhter、「交通工学属性」という[BGP-Te]オールド-Brahimは進歩、2008年1月に働いています。
[CONF-SEG] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Key-Based Mechanism", Work in
Progress, May 2008.
[CONF-SEG]ブラッドフォード、R.(エド)、Vasseur(JP)、および「キーベースのメカニズムを使用することで相互ドメイン経路計算におけるトポロジー秘密性を保存する」A.ファレルが進行中(2008年5月)で働いています。
[GMPLS-SEC] Fang, L., Ed., " Security Framework for MPLS and GMPLS
Networks", Work in Progress, February 2008.
[GMPLS-SEC] 牙、L.、エド、2月2008、「MPLSのためのセキュリティフレームワークとGMPLSネットワーク」は進行中で働いています。
11. Acknowledgments
11. 承認
The authors would like to thank Ichiro Inoue for valuable comments. In addition, the authors would like to thank Marco Carugi and Takumi Ohba for valuable comments in the early development of this document.
作者は貴重なコメントについて井上一郎に感謝したがっています。 さらに、作者はこのドキュメントの初期発生における貴重なコメントについてマルコCarugiとTakumiオオバに感謝したがっています。
Thanks to Tim Polk and Mark Townsley for comments during IESG review.
おかげに、IESGの間のコメントのためのティム・ポークとマークTownsleyは論評します。
Takeda Informational [Page 17] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[17ページ]のRFC5253
Authors' Addresses
作者のアドレス
Tomonori Takeda (editor) NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 7434 EMail: takeda.tomonori@lab.ntt.co.jp
Tomonori竹田(エディタ)NTTネットワーク・サービスシステム研究所、日本東京180-8585が電話をする3 9-11テロのNTT社の美土里町武蔵野市: +81 422 59 7434はメールされます: takeda.tomonori@lab.ntt.co.jp
Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 4201573 EMail: dbrungard@att.com
デボラBrungard AT&T Rm。 D1-3C22--200秒間ローレルAve。 ミドルタウン、ニュージャージー 07748、米国は以下に電話をします。 +1 732 4201573 メール: dbrungard@att.com
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
エードリアンのファレルの古い犬のコンサルティング電話: +44 (0) 1978 860944はメールされます: adrian@olddog.co.uk
Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 EMail: hbrahim@nortel.com
ハミドオールド-Brahimノーテルは私書箱3511駅のCオタワをK1Y 4H7カナダ電話にネットワークでつなぎます: +1(613) 765 3418はメールされます: hbrahim@nortel.com
Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel-lucent.be
ディミトリのPapadimitriouのアルカテル透明なフランシスWellensplein1、B-2018アントウェルペン(ベルギー)電話: +32 3 2408491 メール: dimitri.papadimitriou@alcatel-lucent.be
Takeda Informational [Page 18] RFC 5253 AS for L1VPN Basic Mode July 2008
モード2008年7月に基本的なL1VPNのような竹田の情報[18ページ]のRFC5253
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Takeda Informational [Page 19]
竹田Informationalです。[19ページ]
一覧
スポンサーリンク
