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).




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
1. Introduction
1. はじめに

[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.


1.1. Specification of Requirements
1.1. 要件の仕様

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]に記載されているように解釈されます。

2. Network Reference Model

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.


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


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.


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.


3. Forwarder Identifier

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.


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.


4. Protocol Components
4.1. Control Messages
4.1. 制御メッセージ

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)

4.2. Existing AVPs for L2VPN
4.2. L2VPNのための既存のAVP

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.


Router ID


The Router ID sent in SCCRQ and SCCRP during control connection setup establishes the unique identity of each 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.


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.


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.


L2-Specific Sublayer


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.


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.


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で送信されます。

4.3. New AVPs for L2VPN
4.3. L2VPNのための新しいのAVP

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.


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


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.


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.


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.


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.


4.4. AVP Interoperability
4.4. AVPの相互運用性

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ビットを設定すると、相互運用性を損なうことになります。

5. Signaling Procedures
5.1. Overview
5.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.


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.


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.


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:


- 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


24 - Attempt to connect to non-existent forwarder 25 - Attempt to connect to unauthorized forwarder

24 - 存在しないフォワーダ25に接続しようとした - 不正フォワーダへの接続を試み

5.2. Pseudowire Tie Detection
5.2. スードワイヤタイ検出

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.


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.


If the AGI is present, it is first prepended to the TAII and SAII values before the tie detection occurs.


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.


5.3. Generic Algorithm
5.3. 一般的なアルゴリズム

The following uses a generic algorithm to illustrate the protocol interactions when constructing an L2VPN using L2TP signaling.


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.


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.


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,
         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.


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.


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.


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.


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.


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.


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
6. IANA Considerations
6. IANAの考慮事項

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:


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:


23 - Mismatching interface MTU 24 - Attempt to connect to non-existent forwarder 25 - Attempt to connect to unauthorized forwarder

23 - 不整合インタフェースMTU 24 - 存在しないフォワーダ25に接続しようとする - 試みは、不正フォワーダに接続します

7. Security Considerations

This specification does not introduce any additional security considerations beyond those discussed in [RFC3931] and [L2VPNFW].

この仕様は[L2VPNFW] [RFC3931]とで説明したものを超えて追加のセキュリティ上の考慮事項を導入しません。

8. Acknowledgement

The author would like to thank Mark Townsley and Carlos Pignataro for their valuable input.


9. References
9.1. Normative References
9.1. 引用規格

[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月。

9.2. Informative References
9.2. 参考文献

[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



Full Copyright Statement


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に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎と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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).