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)
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).
著作権（C）インターネット協会（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）はトンネルにL2プロトコルの様々なL2TPセッションをセットアップし、管理するための標準的な方法を提供します。 L2TPによってサポートされる参照モデルの一つは、レイヤ2仮想プライベートネットワーク（L2VPN）の基本的な形態であるL2TPアクセス・コンセントレータ（のLAC）のピアリングの対に取り付けられた2つのレイヤ2つの回路を接続するためのL2TPセッションの使用を記載しています。この文書は、統一された方法でのL2VPNの異なる種類を設定するL2TPのためのプロトコル拡張を定義します。
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]はポイントツーポイントプロトコル（PPP）、[RFC2661]でサポートされる唯一のプロトコル、パケットベースのネットワーク上のほかに複数のレイヤ2つのプロトコルを実行するために動的トンネリングメカニズムを定義します。ベースラインプロトコルは、[RFC3931]に異なるレイヤ2トンネリングプロトコル（L2TP）参照モデルで強調されているアプリケーション、様々なタイプをサポートします。 L2TPアクセス・コンセントレータ（LAC）はL2TPコントロール接続エンドポイント（LCCE）クロスコネクト接続回線とL2TPセッションということです。レイヤ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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
接続回線とL2TPセッションの間にクロスコネクトとしてLAC-LAC参照モデルにおいて、LACは役立ちます。各L2TPセッションはまた、疑似回線として知られているエミュレート回路として作用します。スードワイヤは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つ以上の接続回線と疑似回線に接続されているフォワーダです。単一の疑似回線は、二つのピアリングの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のためのシグナリング手順は、それぞれ、制御接続管理着信手順に基づいて、セクション3.3と[RFC3931]の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)
[スタートコントロール接続要求（SCCRQ）を起動コントロール接続返信（SCCRP）着信-要求（ICRQ）着信-返信（ICRP）着信接続（ICCN）を設定し、リンク情報を（ 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.
次の属性値セクション5.4.3、5.4.4で定義された対（のAVP）、及び[RFC3931]の5.4.5は、の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
スードワイヤ機能一覧
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への特定のpseudowireタイプのセッションを開始する前に、リモート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で応答します。それが一致するものが見つからない場合は、「サポートされていない、疑似回線種別」結果コードで、コールの切断は、通知（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特有のSublayerをサポートしている場合、それは、送信PEに送られるそのデータパケット内の識別されたL2特有のSublayerを含まなければなりません。それ以外の場合は、送信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.
サーキットの状態は、送信PE上の回路の状態についての受信PEを知らせるためにICRQとICRPの両方に送信されます。また、ステータスを更新するために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で符号化され、指定されたフォワーダ識別子と一致フォワーダに提案された疑似回線を結合するために受信PEを指示する任意AGIと共にICRQで送信されます。
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は、特定のフォワーダを識別するために、それぞれ、SAIIとTAIIをコードローカルエンドID AVPとリモートエンドID AVP、と組み合わせて使用されます。 AGI AVPは、制御メッセージでは省略またはゼロ長の値が含まれている場合、フォワーダは、デフォルトのAGIを使用すると考えられます。すべてのフォワーダーに対して1つだけ指定されたデフォルトAGI値があることに注意してください。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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ビットはこのAVPの0（隠れることの前）の長さに設定すべきは、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のためのAttribute Value分野には、以下の形式になっています。
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ビットはこのAVPの0（隠れることの前）の長さに設定すべきは、6つのオクテットプラスSAIIフィールドの長さです。
Interface Maximum Transmission Unit
インターフェイスの最大伝送ユニット
The Interface Maximum Transmission Unit (MTU) AVP, Attribute Type
インターフェイスの最大伝送単位（MTU）AVP、属性タイプ
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.
91は、CE-対向インターフェースから送出することができるパケットのオクテットでMTUを示しています。所与の疑似回線のMTU値は、両方向でアドバタイズ場合は、同じでなければなりません。それらが一致しない場合は、スードワイヤが確立されるべきではありません。このAVPは、いずれかの方向に制御メッセージで省略された場合、リモートPEが通知される疑似回線のローカルPEと同じインタフェースMTUを有していることが想定されます。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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に記載されています。 1に新しいのAVPのMビットを設定すると、相互運用性を損なうことになります。
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上のリモートフォワーダに疑似回線を設定する必要が知っていると仮定する。この知識は、手動設定または一部の自動発見手順のいずれかを介して取得することができます。
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の交換をピアリングの各ペアは、制御接続を確立するために接続メッセージを制御します。それぞれ、スードワイヤ機能リストAVPで、[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.
両方の条件が満たされている場合は、接続要求を受け入れるようにリモートPEにICRPを送ります。 2つの条件のいずれかが失敗した場合は、接続要求を拒否するようにリモートPEにCDNを送ります。
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への疑似回線を開始することができるいずれかと考えられるネットワーク参照モデルにおいて、PEは同時に互いに疑似回線を開始してしまう可能性があり。 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
唯一TAIIはICRQに存在する場合、SAIIはTAIIと同じ値を有するものとします。受信PEは、それが以前に送信PEに送信することをSAIIと受信TAIIを比較します。もし
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.
その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を形成します。そして、それは別のリスト、TARGET_FORWARDERSに相互に接続する必要があるすべてのローカルフォワーダと同じVPNのすべてのリモートフォワーダを置きます。ネットワークトポロジの形成がSOURCE_FORWARDERSとTARGET_FORWARDERSリストの内容に依存します。これら二つのリストには、手動設定または一部の自動発見手順により構築することができます。
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のすべての参加PEで終了したときL2VPNが形成されています。
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に戻ります。
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.
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のアドレスを取得し、1つが存在しない場合、リモート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は、リモートPEにICRQを送ります。 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.
ローカルPEは、それがちょうど送信ICRQに対応する応答を受信9と、ローカルPEは、同じリモートPEからICRQを受信した場合に、そうでなければ10に進み、ステップ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であれば、それはICRPだ場合は、ローカルPEは、疑似回線にソースフォワーダを結合し、リモートPEにICCNを送信し、ステップ2に戻ります。ステップ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を受け入れる場合、それはリモートPEにICRPを送ります。
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である場合、それはICCNである場合、ローカルPEは、疑似回線にソースフォワーダを結合するステップ2に戻って、ステップ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].
この仕様は[L2VPNFW] [RFC3931]とで説明したものを超えて追加のセキュリティ上の考慮事項を導入しません。
The author would like to thank Mark Townsley and Carlos Pignataro for their valuable input.
著者は彼らの貴重な入力のためのマークTownsleyとカルロスPignataroに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]ラウ、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]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーション（PWE3）への擬似回線EdgeのIANAの割り当て"。
[L2VPNFW] Andersson L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[L2VPNFW]アンデL.、エド。およびE.ローゼン、エド。、RFC 4664 "レイヤ2個の仮想プライベートネットワーク（のL2VPN）のためのフレームワーク"、2006年9月。
[PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", Work in Progress.
[PWE3L2TP] W. Townsley、 "スードワイヤと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.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
Author's Address
著者のアドレス
Wei Luo Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
魏羅シスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
EMail: luo@cisco.com
メールアドレス：luo@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。