[要約] RFC 4667は、L2TPのためのLayer 2 Virtual Private Network (L2VPN)の拡張に関するものです。その目的は、L2TPを使用してL2VPNを提供するためのプロトコル仕様を定義することです。
Network Working Group W. Luo
Request for Comments: 4667 Cisco Systems, Inc.
Category: Standards Track September 2006
Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)
レイヤー2仮想プライベートネットワーク（L2VPN）レイヤー2トンネリングプロトコル（L2TP）の拡張機能
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering L2TP Access Concentrators (LACs), which is a basic form of Layer 2 Virtual Private Network (L2VPN). This document defines the protocol extensions for L2TP to set up different types of L2VPNs in a unified fashion.
レイヤー2トンネルプロトコル（L2TP）は、L2TPセッションをセットアップおよび管理して、さまざまなL2プロトコルをトンネルするための標準的な方法を提供します。L2TPでサポートされている参照モデルの1つは、L2TPセッションを使用して、レイヤー2仮想プライベートネットワーク（L2VPN）の基本的な形式であるピアリングL2TPアクセス濃縮器（LAC）に取り付けられた2つのレイヤー2回路を接続することを説明しています。このドキュメントでは、L2TPのプロトコル拡張機能を定義して、異なるタイプのL2VPNSを統一された方法でセットアップします。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Network Reference Model .........................................2
3. Forwarder Identifier ............................................3
4. Protocol Components .............................................4
4.1. Control Messages ...........................................4
4.2. Existing AVPs for L2VPN ....................................4
4.3. New AVPs for L2VPN .........................................5
4.4. AVP Interoperability .......................................7
5. Signaling Procedures ............................................7
5.1. Overview ...................................................7
5.2. Pseudowire Tie Detection ...................................8
5.3. Generic Algorithm ..........................................9
6. IANA Considerations ............................................12
7. Security Considerations ........................................12
8. Acknowledgement ................................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
[RFC3931] defines a dynamic tunneling mechanism to carry multiple Layer 2 protocols besides Point-to-Point Protocol (PPP), the only protocol supported in [RFC2661], over a packet-based network. The baseline protocol supports various types of applications, which have been highlighted in the different Layer 2 Tunneling Protocol (L2TP) reference models in [RFC3931]. An L2TP Access Concentrator (LAC) is an L2TP Control Connection Endpoint (LCCE) that cross-connects attachment circuits and L2TP sessions. Layer 2 Virtual Private Network (L2VPN) applications are typically in the scope of the LAC-LAC reference model.
[RFC3931]は、パケットベースのネットワークを介して[RFC2661]でサポートされている唯一のプロトコルであるポイントツーポイントプロトコル（PPP）に加えて、複数のレイヤー2プロトコルを運ぶ動的トンネルメカニズムを定義します。ベースラインプロトコルは、[RFC3931]の異なるレイヤー2トンネルプロトコル（L2TP）参照モデルで強調されているさまざまなタイプのアプリケーションをサポートしています。L2TPアクセス濃縮器（LAC）は、アタッチメント回路とL2TPセッションをクロス接続するL2TP制御接続エンドポイント（LCCE）です。レイヤー2仮想プライベートネットワーク（L2VPN）アプリケーションは、通常、LAC-LAC参照モデルの範囲にあります。
This document discusses the commonalities and differences among L2VPN applications with respect to using L2TPv3 as the signaling protocol. In this document, the acronym "L2TP" refers to L2TPv3 or L2TP in general.
このドキュメントでは、L2TPV3をシグナリングプロトコルとして使用することに関して、L2VPNアプリケーション間の共通性と違いについて説明します。このドキュメントでは、頭字語「L2TP」は一般的にL2TPV3またはL2TPを指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
In the LAC-LAC reference model, a LAC serves as a cross-connect between attachment circuits and L2TP sessions. Each L2TP session acts as an emulated circuit, also known as pseudowire. A pseudowire is used to bind two "forwarders" together. For different L2VPN applications, different types of forwarders are defined.
LAC-LACリファレンスモデルでは、ラックはアタッチメント回路とL2TPセッションの間のクロスコネクトとして機能します。各L2TPセッションは、Pseudowireとしても知られるエミュレート回路として機能します。プソイドワイヤは、2つの「フォワーダー」を結合するために使用されます。さまざまなL2VPNアプリケーションでは、さまざまなタイプのフォワーダーが定義されています。
In the L2VPN framework [L2VPNFW], a LAC is a Provider Edge (PE) device. LAC and PE are interchangeable terms in the context of this document. Remote systems in the LAC-LAC reference model are Customer Edge (CE) devices.
L2VPNフレームワーク[L2VPNFW]では、LACはプロバイダーエッジ（PE）デバイスです。LACとPEは、このドキュメントのコンテキストでは交換可能な用語です。LAC-LACリファレンスモデルのリモートシステムは、顧客エッジ（CE）デバイスです。
+----+ L2 +----+ +----+ L2 +----+
| CE |------| PE |....[core network]....| PE |------| CE |
+----+ +----+ +----+ +----+
|<- emulated service ->|
|<----------------- L2 service -------------->|
L2VPN Network Reference Model
L2VPNネットワーク参照モデル
In a simple cross-connect application, an attachment circuit is a forwarder directly bound to a pseudowire. It is a one-to-one mapping. Traffic received from the attachment circuit on a local PE is forwarded to the remote PE through the pseudowire. When the remote PE receives traffic from the pseudowire, it forwards the traffic to the corresponding attachment circuit on its end. The forwarding decision is based on the attachment circuit or pseudowire demultiplexing identifier.
単純なクロス接続アプリケーションでは、アタッチメント回路は擬似ワイヤに直接結合した転送者です。1対1のマッピングです。ローカルPEのアタッチメント回路から受け取ったトラフィックは、擬似ワイヤを介してリモートPEに転送されます。リモートPEが擬似ワイヤからトラフィックを受信すると、端が対応するアタッチメント回路にトラフィックを転送します。転送の決定は、アタッチメント回路または擬似化型識別子識別子に基づいています。
With Virtual Private LAN Service (VPLS), a Virtual Switching Instance (VSI) is a forwarder connected to one or more attachment circuits and pseudowires. A single pseudowire is used to connect a pair of VSIs on two peering PEs. Traffic received from an attachment circuit or a pseudowire is first forwarded to the corresponding VSI based on the attachment circuit or pseudowire demultiplexing identifier. The VSI performs additional lookup to determine where to further forward the traffic.
仮想プライベートLANサービス（VPLS）を使用すると、仮想スイッチングインスタンス（VSI）は、1つ以上のアタッチメントサーキットと擬似動物に接続された転送者です。単一の擬似ワイヤを使用して、2つのピアリングPEでVSIのペアを接続します。アタッチメント回路または擬似具体から受け取ったトラフィックは、最初にアタッチメント回路または擬似化型剥離識別子に基づいて、対応するVSIに転送されます。VSIは追加の検索を実行して、トラフィックをさらに進める場所を決定します。
With Virtual Private Wire Service (VPWS), attachment circuits are grouped into "colored pools". Each pool is a forwarder and is connected through a network of point-to-point cross-connects. The data forwarding perspective is identical to the cross-connect application. However, constructing colored pools involves more complicated signaling procedures.
仮想プライベートワイヤサービス（VPWS）により、アタッチメントサーキットは「カラープール」にグループ化されます。各プールはフォワーダーであり、ポイントツーポイントクロスコネクトのネットワークを介して接続されています。データ転送の観点は、クロスコネクトアプリケーションと同じです。ただし、色付きのプールの構築には、より複雑なシグナル伝達手順が含まれます。
A forwarder identifier is assigned to each forwarder on a given PE and is unique in the context of the PE. It is defined as the concatenation of an Attachment Group Identifier (AGI) and an Attachment Individual Identifier (AII), denoted as <AGI, AII>. The AGI is used to group a set of forwarders together for signaling purposes. An AII is used to distinguish forwarders within a group. AII can be unique on a per-platform or per-group basis.
フォワーダー識別子は、特定のPEで各フォワーダーに割り当てられ、PEのコンテキストで一意です。これは、アタッチメントグループ識別子（AGI）およびアタッチメント個体識別子（AII）の連結として定義され、<agi、aii>として示されます。AGIは、シグナリングの目的で転送者のセットをグループ化するために使用されます。AIIは、グループ内のフォワーダーを区別するために使用されます。AIIは、プラットフォームごとまたはグループごとに一意にすることができます。
As far as the signaling procedures are concerned, a forwarder identifier is an arbitrary string of bytes. It is up to implementations to decide the values for AGI and AII.
信号手順に関する限り、フォワーダー識別子は任意のバイト文字列です。AGIとAIIの値を決定するのは実装次第です。
When connecting two forwarders together, both MUST have the same AGI as part of their forwarder identifiers. The AII of the source forwarder is known as the Source AII (SAII), and the AII of the target forwarder is known as the Target AII (TAII). Therefore, the source forwarder and target forwarder can be denoted as <AGI, SAII> and <AGI, TAII>, respectively.
2つのフォワーダーを接続するときは、両方ともフォワーダー識別子の一部と同じAGIを持っている必要があります。ソースフォワーダーのAIIはソースAII（SAII）として知られており、ターゲットフォワーダーのAIIはターゲットAII（TAII）として知られています。したがって、ソースフォワーダーとターゲット転送業者は、それぞれ<agi、saii>および<agi、taii>として示すことができます。
L2TP defines two sets of session management procedures: incoming call and outgoing call. Even though it is entirely possible to use the outgoing call procedures for signaling L2VPNs, the incoming call procedures have some advantages in terms of the relevance of the semantics. [PWE3L2TP] gives more details on why the incoming call procedures are more appropriate for setting up pseudowires.
L2TPは、2セットのセッション管理手順を定義します。着信コールと発信コールです。L2VPNを信号するために発信コール手順を使用することは完全に可能ですが、着信コール手順には、セマンティクスの関連性に関していくつかの利点があります。[PWE3L2TP]は、擬似動物のセットアップに着信コール手順がより適切である理由の詳細を示しています。
The signaling procedures for L2VPNs described in the following sections are based on the Control Connection Management and the Incoming Call procedures, defined in Sections 3.3 and 3.4.1 of [RFC3931], respectively. L2TP control message types are defined in Section 3.1 of [RFC3931]. This document references the following L2TP control messages:
次のセクションで説明したL2VPNのシグナル伝達手順は、それぞれ[RFC3931]のセクション3.3および3.4.1で定義されている制御接続管理と着信コール手順に基づいています。L2TPコントロールメッセージタイプは、[RFC3931]のセクション3.1で定義されています。このドキュメントは、次のL2TP制御メッセージを参照しています。
Start-Control-Connection-Request (SCCRQ) Start-Control-Connection-Reply (SCCRP) Incoming-Call-Request (ICRQ) Incoming-Call-Reply (ICRP) Incoming-Call-Connected (ICCN) Set-Link-Info (SLI)
Start-Control-Connection-Request（SCCRQ）Start-Control-Connection-Reply（SCCRP）comping-call-Request（ICRQ）受信コール繰り返し（ICRP）受信コール接続（ICCN）Set-Link-Info（sli）
The following Attribute Value Pairs (AVPs), defined in Sections 5.4.3, 5.4.4, and 5.4.5 of [RFC3931], are used for signaling L2VPNs.
[RFC3931]のセクション5.4.3、5.4.4、および5.4.5で定義されている次の属性値ペア（AVPS）は、L2VPNのシグナルに使用されます。
Router ID
ルーターID
The Router ID sent in SCCRQ and SCCRP during control connection setup establishes the unique identity of each PE.
制御接続のセットアップ中にSCCRQとSCCRPで送信されたルーターIDは、各PEの一意のアイデンティティを確立します。
Pseudowire Capabilities List
Pseudowire機能リスト
The Pseudowire Capabilities List sent in the SCCRQ and SCCRP indicates the pseudowire types supported by the sending PE. It merely serves as an advertisement to the receiving PE. Its content should not affect the control connection setup.
SCCRQおよびSCCRPで送信された擬似能力リストは、送信PEによってサポートされている擬似ワイヤタイプを示しています。それは単に受信PEの広告として機能するだけです。そのコンテンツは、制御接続のセットアップに影響しないはずです。
Before a local PE initiates a session of a particular pseudowire type to a remote PE, it MUST examine whether the remote PE has advertised this pseudowire type in this AVP and SHOULD NOT attempt to initiate the session if the intended pseudowire type is not supported by the remote PE.
ローカルPEが特定の擬似型タイプのセッションをリモートPEに開始する前に、リモートPEがこのAVPでこの擬似ワイヤタイプを宣伝したかどうかを調べる必要があり、意図した擬万タイプがサポートされていない場合はセッションを開始しようとしないでください。リモートPE。
Pseudowire Type
擬似型タイプ
The Pseudowire Type sent in ICRQ signals the intended pseudowire type to the receiving PE. The receiving PE checks it against its local pseudowire capabilities list. If it finds a match, it responds with an ICRP without a Pseudowire Type AVP, which implicitly acknowledges its acceptance of the intended pseudowire. If it does not find a match, it MUST respond with a Call-Disconnect-Notify (CDN), with an "unsupported pseudowire type" result code.
ICRQで送信された擬似型タイプは、受信PEに意図した擬似型タイプを信号します。受信PEは、地元の擬似能力リストに対してそれをチェックします。一致が見つかった場合、それは擬似型タイプのAVPなしでICRPで応答します。一致が見つからない場合は、「サポートされていない擬似型」結果コードを使用して、call-disconnect-notify（cdn）で応答する必要があります。
L2-Specific Sublayer
L2固有のサブレーヤー
The L2-Specific Sublayer can be sent in ICRQ, ICRP, and ICCN. If the receiving PE supports the specified L2-Specific Sublayer, it MUST include the identified L2-Specific Sublayer in its data packets sent to the sending PE. Otherwise, it MUST reject the connection by sending a CDN to the sending PE.
L2特異的崇高は、ICRQ、ICRP、およびICCNで送信できます。受信PEが指定されたL2固有の崇高をサポートする場合、送信PEに送信されたデータパケットに特定されたL2固有のサブレーヤーを含める必要があります。それ以外の場合は、送信PEにCDNを送信することにより、接続を拒否する必要があります。
Circuit Status
回路ステータス
The Circuit Status is sent in both ICRQ and ICRP to inform the receiving PE about the circuit status on the sending PE. It can also be sent in ICCN and SLI to update the status.
回路ステータスは、ICRQとICRPの両方で送信され、受信PEに送信PEの回路ステータスについて通知します。また、ICCNとSLIで送信して、ステータスを更新することもできます。
Remote End Identifier
リモートエンド識別子
The TAII value is encoded in the Remote End ID AVP and sent in ICRQ along with the optional AGI to instruct the receiving PE to bind the proposed pseudowire to the forwarder that matches the specified forwarder identifier.
TAII値はリモートエンドID AVPでエンコードされ、ICRQでオプションのAGIとともに送信され、受信PEに指定された擬似ワイヤーを指定されたフォワーダー識別子と一致するフォワーダーに結合するよう指示します。
Attachment Group Identifier
アタッチメントグループ識別子
The AGI AVP, Attribute Type 89, is an identifier used to associate a forwarder to a logical group. The AGI AVP is used in conjunction with the Local End ID AVP and Remote End ID AVP, which encode the SAII and TAII, respectively, to identify a specific forwarder. When the AGI AVP is omitted in the control messages or contains a zero-length value, the forwarders are considered to use the default AGI. Note that there is only one designated default AGI value for all forwarders.
AGI AVP属性タイプ89は、フォワーダーを論理グループに関連付けるために使用される識別子です。AGI AVPは、Local End ID AVPおよびリモートエンドID AVPと組み合わせて使用され、それぞれSAIIとTAIIをエンコードして特定のフォワーダーを特定します。AGI AVPがコントロールメッセージで省略されているか、ゼロの長さの値が含まれている場合、フォワーダーはデフォルトのAGIを使用すると見なされます。すべてのフォワーダーに指定されたデフォルトAGI値は1つだけであることに注意してください。
The Attribute Value field for this AVP has the following format:
このAVPの属性値フィールドには、次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 89 | AGI (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AGI field is a variable-length field. This AVP MAY be present in ICRQ.
AGIフィールドは可変長さフィールドです。このAVPはICRQに存在する場合があります。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The hiding of AVP attribute values is defined in Section 5.3 of [RFC3931]. The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 octets plus the length of the AGI field.
このAVPは隠されている可能性があります（Hビットは0または1です）。AVP属性値の非表示は、[RFC3931]のセクション5.3で定義されています。このAVPのMビットは0に設定する必要があります。このAVPの長さ（隠す前）は、6オクテットとAGIフィールドの長さです。
Local End ID
ローカルエンドID
The Local End ID AVP, Attribute Type 90, encodes the SAII value. The SAII may also be used in conjunction with the TAII to detect pseudowire ties. When it is omitted in the control messages, it is assumed that it has the same value as the TAII.
ローカルエンドID AVP属性タイプ90は、SAII値をエンコードします。SAIIは、TAIIと組み合わせて使用して、擬似ワイヤーのネクタイを検出することもできます。制御メッセージで省略されている場合、TAIIと同じ値があると想定されます。
The Attribute Value field for this AVP has the following format:
このAVPの属性値フィールドには、次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 90 | SAII (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SAII field is a variable-length field. This AVP MAY be present in ICRQ.
SAIIフィールドは可変長さのフィールドです。このAVPはICRQに存在する場合があります。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 octets plus the length of the SAII field.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは0に設定する必要があります。このAVPの長さ（隠す前）は、6オクテットとSAIIフィールドの長さです。
Interface Maximum Transmission Unit
インターフェイス最大送信ユニット
The Interface Maximum Transmission Unit (MTU) AVP, Attribute Type 91, indicates the MTU in octets of a packet that can be sent out from the CE-facing interface. The MTU values of a given pseudowire, if advertised in both directions, MUST be identical. If they do not match, the pseudowire SHOULD NOT be established. When this AVP is omitted in the control messages in either direction, it is assumed that the remote PE has the same interface MTU as the local PE for the pseudowire being signaled.
インターフェイス最大伝送ユニット（MTU）AVP属性タイプ91は、CEに向かうインターフェイスから送信できるパケットのオクテットのMTUを示します。特定の擬似ワイヤのMTU値は、両方向に宣伝されている場合、同一でなければなりません。それらが一致しない場合、擬似ワイヤーを確立すべきではありません。このAVPがどちらの方向のコントロールメッセージで省略されている場合、リモートPEには、擬似ワイヤが通知されるためのローカルPEと同じインターフェイスMTUがあると想定されています。
The Attribute Value field for this AVP has the following format:
このAVPの属性値フィールドには、次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 91 | Interface MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Interface MTU field is a 2-octet integer value. This AVP MAY be present in ICRQ and ICRP. When a PE receives an Interface MTU AVP with an MTU value different from its own, it MAY respond with a CDN with a new result code indicating the disconnect cause.
インターフェイスMTUフィールドは、2オクテットの整数値です。このAVPは、ICRQおよびICRPに存在する場合があります。PEが独自とは異なるMTU値を持つインターフェイスMTU AVPを受信すると、切断の原因を示す新しい結果コードを持つCDNで応答する場合があります。
23 - Mismatching interface MTU
23-インターフェイスMTUの不一致
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8 octets.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは0に設定する必要があります。このAVPの長さ（隠す前）は8オクテットです。
To ensure interoperability, the mandatory (M) bit settings of the existing AVPs used in L2VPN applications should be the same as those specified in [RFC3931]. The generic M-bit processing is described in Section 5.2 of [RFC3931]. Setting the M-bit of the new AVPs to 1 will impair interoperability.
相互運用性を確保するために、L2VPNアプリケーションで使用される既存のAVPの必須（M）ビット設定は、[RFC3931]で指定されたものと同じでなければなりません。一般的なMビット処理は、[RFC3931]のセクション5.2で説明されています。新しいAVPのMビットを1に設定すると、相互運用性が損なわれます。
Assume that a PE assigns a forwarder identifier to one of its local forwarders and that it knows it needs to set up a pseudowire to a remote forwarder on a remote PE that has a certain Forwarder ID. This knowledge can be obtained either through manual configuration or some auto-discovery procedure.
PEが地元のフォワーダーのいずれかにフォワーダー識別子を割り当て、特定のフォワーダーIDを持つリモートPE上のリモートPEに擬似ワイヤーをセットアップする必要があることを知っていると仮定します。この知識は、手動構成または自動発見手順のいずれかを通じて取得できます。
Before establishing the intended pseudowire, each pair of peering PEs exchanges control connection messages to establish a control connection. Each advertises its supported pseudowire types, as defined in [PWE3IANA], in the Pseudowire Capabilities List AVP.
意図された擬似ワイヤを確立する前に、ピアリングPEを交換する各ペアは、制御接続メッセージを制御するためのコントロール接続を確立します。[PWE3IANA]で定義されているように、それぞれがサポートされている擬似ワイヤタイプを宣伝しています。
After the control connection is established, the local PE examines whether the remote PE supports the pseudowire type it intends to set up. Only if the remote PE supports the intended pseudowire type should it initiate a pseudowire connection request.
制御接続が確立された後、ローカルPEは、リモートPEがセットアップしようとする擬似ワイヤータイプをサポートするかどうかを調べます。リモートPEが意図した擬似型タイプをサポートしている場合にのみ、擬似ワイヤ接続要求を開始した場合。
When the local PE receives an ICRQ for a pseudowire connection, it examines the forwarder identifiers encoded in the AGI, SAII, and TAII in order to determine the following:
ローカルPEが擬似ワイヤ接続のためにICRQを受信すると、以下を決定するために、AGI、SAII、およびTAIIでエンコードされた転送業者識別子を調べます。
- Whether it has a local forwarder with the forwarder identifier value specified in the ICRQ.
- ICRQで指定されたフォワーダー識別子値を備えたローカル転送者がいるかどうか。
- Whether the remote forwarder with the forwarder identifier specified in the ICRQ is allowed to connect with this local forwarder.
- ICRQで指定されたフォワーダー識別子を持つリモートフォワーダーがこのローカル転送者と接続できるかどうか。
If both conditions are met, it sends an ICRP to the remote PE to accept the connection request. If either of the two conditions fails, it sends a CDN to the remote PE to reject the connection request.
両方の条件が満たされている場合、接続要求を受け入れるためにICRPをリモートPEに送信します。2つの条件のいずれかが失敗した場合、CDNをリモートPEに送信して接続要求を拒否します。
The local PE can optionally include a result code in the CDN to indicate the disconnect cause. The possible result codes are
ローカルPEは、オプションでCDNに結果コードを含めることができ、切断の原因を示すことができます。考えられる結果コードは次のとおりです
24 - Attempt to connect to non-existent forwarder 25 - Attempt to connect to unauthorized forwarder
24-存在しないフォワーダーに接続しようとする25-不正な転送者に接続しようとする
Conceivably in the network reference models, as either PE may initiate a pseudowire to another PE at any time, the PEs could end up initiating a pseudowire to each other simultaneously. In order to avoid setting up duplicated pseudowires between two forwarders, each PE must be able to independently detect such a pseudowire tie. The following procedures need to be followed to detect a tie:
おそらくネットワークリファレンスモデルでは、どちらのPEが擬似ワイヤを別のPEに開始する可能性があるため、PESは同時に相互に擬似ワイヤを開始することになります。2つのフォワーダーの間に重複した擬似動物のセットアップを避けるために、各PEはそのような擬似ワイヤーのネクタイを独立して検出できる必要があります。ネクタイを検出するには、次の手順に従う必要があります。
If both TAII and SAII are present in the ICRQ, the receiving PE compares the TAII and SAII against the SAII and TAII previously sent to the sending PE. If the received TAII matches the sent SAII and the received SAII matches the sent TAII, a tie is detected.
TAIIとSAIIの両方がICRQに存在する場合、受信PEは以前に送信PEに送られたSAIIとTAIIとTAIIとSAIIを比較します。受信したTAIIが送信されたSAIIと一致し、受信したSAIIが送信されたTAIIと一致する場合、ネクタイが検出されます。
If only the TAII is present in the ICRQ, the SAII is assumed to have the same value as the TAII. The receiving PE compares the received TAII with the SAII that it previously sent to the sending PE. If the SAII in that ICRQ is also omitted, then the value encoded in the sent TAII is used for comparison. If they match, a tie is detected.
TAIIのみがICRQに存在する場合、SAIIはTAIIと同じ値を持っていると想定されています。受信PEは、受信したTAIIを以前に送信PEに送信したSAIIと比較します。そのICRQのSAIIも省略されている場合、送信されたTAIIでエンコードされた値が比較に使用されます。それらが一致する場合、ネクタイが検出されます。
If the AGI is present, it is first prepended to the TAII and SAII values before the tie detection occurs.
AGIが存在する場合、タイ検出が発生する前に、最初にTAII値とSAII値に加えられます。
Once a tie is discovered, the PE uses the standard L2TP tie breaking procedure, as described in Section 5.4.4 of [RFC3931], to disconnect the duplicated pseudowire.
ネクタイが発見されると、[RFC3931]のセクション5.4.4で説明されているように、PEは標準のL2TPタイ壊し手順を使用して、重複した擬似ワイヤを切断します。
The following uses a generic algorithm to illustrate the protocol interactions when constructing an L2VPN using L2TP signaling.
以下は、一般的なアルゴリズムを使用して、L2TPシグナル伝達を使用してL2VPNを構築する際のプロトコル相互作用を説明します。
Each PE first forms a list, SOURCE_FORWARDERS, consisting of all local forwarders of a given VPN. Then it puts all local forwarders that need to be interconnected and all remote forwarders of the same VPN into another list, TARGET_FORWARDERS. The formation of the network topology depends on the content in the SOURCE_FORWARDERS and TARGET_FORWARDERS lists. These two lists can be constructed by manual configuration or some auto-discovery procedure.
各PEは、最初に、特定のVPNのすべてのローカルフォワーダーで構成されるリストsource_forwardersを形成します。次に、相互接続する必要があるすべてのローカルフォワーダーと、同じVPNのすべてのリモートフォワーダーを別のリスト、Target_Forwardersに配置します。ネットワークトポロジの形成は、source_forwardersおよびtarget_forwardersリストのコンテンツに依存します。これらの2つのリストは、手動構成または自動発見手順によって構築できます。
The algorithm is used to set up a full mesh of interconnections between SOURCE_FORWARDERS and TARGET_FORWARDERS. An L2VPN is formed when the algorithm is finished in every participating PE of this L2VPN.
このアルゴリズムは、source_forwardersとtarget_forwardersの間の相互接続の完全なメッシュをセットアップするために使用されます。L2VPNは、このL2VPNのすべての参加PEでアルゴリズムが終了したときに形成されます。
1. Pick the next forwarder, from SOURCE_FORWARDERS. If no forwarder is available for processing, the processing is complete.
1. source_forwardersから次のフォワーダーを選択します。転送者が処理に利用できない場合、処理が完了します。
2. Pick the next forwarder, from TARGET_FORWARDERS. If no forwarder is available for processing, go back to step 1.
2. Target_forwardersから次のフォワーダーを選択します。転送者が処理できない場合は、ステップ1に戻ります。
3. If the two forwarders are associated with different Router IDs, a pseudowire must be established between them. Proceed to step 6.
3. 2つのフォワーダーが異なるルーターIDに関連付けられている場合、それらの間に擬似ワイヤーを確立する必要があります。ステップ6に進みます。
4. Compare the <AGI, AII> values of the two forwarders. If they match, the source and target forwarders are the same, so no more action is necessary. Go back to step 2.
4. 2つのフォワーダーの<agi、aii>値を比較します。それらが一致する場合、ソースとターゲットのフォワーダーは同じであるため、これ以上のアクションは必要ありません。ステップ2に戻ります。
5. As the source and target forwarders both reside on the local PE, no pseudowire is needed. The PE simply creates a local cross-connect between the two forwarders. Go back to step 2.
5. ソースとターゲットのフォワーダーは両方とも地元のPEに存在するため、擬似ワイヤは必要ありません。PEは、2つのフォワーダー間にローカルクロスコネクトを作成するだけです。ステップ2に戻ります。
6. As the source and target forwarders reside on different PEs,
6. ソースとターゲットのフォワーダーが異なるPEに存在するように、
a pseudowire must be established between them. The PE first examines whether the source forwarder has already established a pseudowire to the target forwarder. If so, go back to step 2.
それらの間に擬似ワイヤを確立する必要があります。PEは、最初に、ソースフォワーダーが既にターゲットフォワーダーに擬似ワイヤを確立しているかどうかを調べます。その場合は、ステップ2に戻ります。
7. If no pseudowire is already established between the source and target forwarders, the local PE obtains the address of the remote PE and establishes a control connection to the remote PE if one does not already exist.
7. ソースフォワーダーとターゲットフォワーダーの間に擬似具体がすでに確立されていない場合、ローカルPEはリモートPEのアドレスを取得し、まだ存在しない場合はリモートPEへの制御接続を確立します。
8. The local PE sends an ICRQ to the remote PE. The AGI, TAII, and SAII values are encoded in the AGI AVP, the Remote End ID AVP, and the Local End ID AVP, respectively.
8. ローカルPEは、ICRQをリモートPEに送信します。AGI、TAII、およびSAII値は、それぞれAGI AVP、リモートエンドID AVP、およびローカルエンドID AVPでエンコードされています。
9. If the local PE receives a response corresponding to the ICRQ it just sent, proceed to step 10. Otherwise, if the local PE receives an ICRQ from the same remote PE, proceed to step 11.
9. ローカルPEが送信したばかりのICRQに対応する応答を受け取った場合、ステップ10に進みます。そうしないと、ローカルPEが同じリモートPEからICRQを受信した場合、ステップ11に進みます。
10. The local PE receives a response from the remote PE. If it is a CDN, go back to step 2. If it's an ICRP, the local PE binds the source forwarder to the pseudowire and sends an ICCN to the remote PE. Go back to step 2.
10. ローカルPEは、リモートPEから応答を受け取ります。CDNの場合は、ステップ2に戻ります。ICRPである場合、ローカルPEはソース転送業者を擬似ワイヤーにバインドし、ICCNをリモートPEに送信します。ステップ2に戻ります。
11. If the local PE receives an ICRQ from the same remote PE, it needs to perform session tie detection, as described in Section 5.2. If a session tie is detected, the PE performs tie breaking.
11. ローカルPEが同じリモートPEからICRQを受信する場合、セクション5.2で説明されているように、セッションタイ検出を実行する必要があります。セッションタイが検出された場合、PEはタイブレイクを実行します。
12. If the local PE loses the tie breaker, it sends a CDN with the result code that indicates that the disconnection is due to losing the tie breaker. Proceed to step 14.
12. ローカルPEがタイブレーカーを紛失した場合、結果コードを含むCDNを送信します。これは、切断がタイブレーカーを失ったことによるものであることを示します。ステップ14に進みます。
13. If the local PE wins the tie breaker, it ignores the remote PE's ICRQ, but acknowledges receipt of the control message and continues waiting for the response from the remote PE. Go to step 10.
13. ローカルPEがタイブレーカーに勝った場合、リモートPEのICRQを無視しますが、コントロールメッセージの受信を認め、リモートPEからの応答を待ち続けます。ステップ10に進みます。
14. The local PE determines whether it should accept the connection request, as described in Section 5.1. If it accepts the ICRQ, it sends an ICRP to the remote PE.
14. ローカルPEは、セクション5.1で説明されているように、接続要求を受け入れるべきかどうかを決定します。ICRQを受け入れると、ICRPをリモートPEに送信します。
15. The local PE receives a response from the remote PE. If it is a CDN, go back to step 2. If it is an ICCN, the local PE binds the source forwarder to the pseudowire, go back to step 2.
15. ローカルPEは、リモートPEから応答を受け取ります。CDNの場合は、ステップ2に戻ります。ICCNである場合、ローカルPEがソースフォワーダーを擬似ワイヤーにバインドします。ステップ2に戻ります。
The following diagram illustrates the above procedure:
次の図は、上記の手順を示しています。
---------> Pick Next
| Source Forwarder
| |
| |
| v N
| Found Source Forwarder? ----------> End
| |
| Y |
| v
| Pick Next <--------------------------------
| Target Forwarder |
| | |
| | |
| N v |
-------- Found Target Forwarder? |
| |
Y | |
v Y Y |
Same Router ID? ------> Same Forwarder ID? ------|
| | |
N | N | |
| v |
| Create Local -------|
v Cross-connect |
Pseudowire Already Y |
Established Between -------------------------------|
Source and Target? |
| |
N | |
v |
Local Initiates Pseudowire |
Connection Request to Remote |
| |
| |
v |
-------> Local Wait for Message |
| ----- from Remote -------------- |
| | | |
| | | |
| v v |
| Local Receives Pseudowire Local Receives Pseudowire |
| Connection Request Connection Response |
| from Remote from Remote |
| | | |
| | | |
| v v N |
| Perform Pseudowire Connection Accepted? --------|
| Tie Detection | |
| | Y | |
| | v |
| | Local Binds Source ---------|
| | Forwarder to Pseudowire |
| | |
| v N N |
| Tie Detected? -----> Accept Remote -----> Reject ------|
| | Connection Request? Remote Request |
| Y | ^ | |
| v | | Y |
| Perform Tie Breaking | ------> Local Binds ----
| | | Source Forwarder
| | | to Pseudowire
| v N |
| Won Tie Breaking? ------> Disconnect
| | Local Connection
| Y |
| v
------ Ignore Remote
Connection Request
The IANA registry procedure in this document follows that in Section 10 of [RFC3931]. The IANA has assigned the following new values for existing registries managed by IANA.
このドキュメントのIANAレジストリの手順は、[RFC3931]のセクション10では次のとおりです。IANAは、IANAが管理する既存のレジストリに次の新しい値を割り当てました。
This document defines three new L2TP control message Attribute Value Pairs (AVPs) that have been assigned by the IANA. These are described in Section 4.3 and are summarized below:
このドキュメントでは、IANAによって割り当てられた3つの新しいL2TPコントロールメッセージ属性値ペア（AVP）を定義します。これらはセクション4.3で説明されており、以下に要約されています。
89 - Attachment Group Identifier 90 - Local End Identifier 91 - Interface Maximum Transmission Unit
89-アタッチメントグループ識別子90-ローカルエンド識別子91-インターフェイス最大伝送ユニット
Sections 4.3 and 5.1 define three new result codes for the CDN message that have been assigned by the IANA:
セクション4.3および5.1は、IANAによって割り当てられたCDNメッセージの3つの新しい結果コードを定義します。
23 - Mismatching interface MTU 24 - Attempt to connect to non-existent forwarder 25 - Attempt to connect to unauthorized forwarder
23-インターフェイスMTU 24-存在しないフォワーダーへの接続を試みる25-不正な転送者への接続を試みる
This specification does not introduce any additional security considerations beyond those discussed in [RFC3931] and [L2VPNFW].
この仕様では、[RFC3931]および[L2VPNFW]で議論されているもの以外の追加のセキュリティ上の考慮事項は導入されません。
The author would like to thank Mark Townsley and Carlos Pignataro for their valuable input.
著者は、Mark TownsleyとCarlos Pignataroの貴重な意見に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、J.、Townsley、M。、およびI. Goyret、「レイヤー2つのトンネルプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[PWE3IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[PWE3IANA] Martini、L。、「Pseudowire to Edge Emulation（PWE3）へのIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[L2VPNFW] Andersson L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[L2VPNFW] Andersson L.、ed。and E. Rosen、ed。、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、RFC 4664、2006年9月。
[PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", Work in Progress.
[PWE3L2TP] W. Townsley、「Pseudowires and L2Tpv3」は、進行中の作業。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "Layer Two Tunneling Protocol" L2TP ""、RFC 2661、1999年8月。
Author's Address
著者の連絡先
Wei Luo Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Wei Luo Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
EMail: luo@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。