RFC4667 日本語訳
4667 Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2Tunneling Protocol (L2TP). W. Luo. September 2006. (Format: TXT=33166 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Luo Request for Comments: 4667 Cisco Systems, Inc. Category: Standards Track September 2006
コメントを求めるワーキンググループW.羅要求をネットワークでつないでください: 4667年のシスコシステムズInc.カテゴリ: 標準化過程2006年9月
Layer 2 Virtual Private Network (L2VPN) Extensions
for Layer 2 Tunneling Protocol (L2TP)
層2のトンネリングプロトコルのための層2の仮想私設網(L2VPN)拡大(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
Layer2Tunnelingプロトコル(L2TP)はさまざまなL2プロトコルにトンネルを堀るためにL2TPセッションをセットアップして、管理するための標準方法を提供します。 L2TPによってサポートされた規範モデルのひとりは、Layer2Virtual兵士のNetwork(L2VPN)の基本的なフォームである1組のじっと見るL2TP Access Concentrators(LACs)に取り付けられた2Layer2回路をつなげるためにL2TPセッションの使用について説明します。 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
1. 序論…2 1.1. 要件の仕様…2 2. 規範モデルをネットワークでつないでください…2 3. 混載業者Identifier…3 4. コンポーネントについて議定書の中で述べてください…4 4.1. メッセージを制御してください…4 4.2. L2VPNのための既存のAVPs…4 4.3. L2VPNのための新しいAVPs…5 4.4. AVP相互運用性…7 5. シグナリング手順…7 5.1. 概要…7 5.2. Pseudowireは検出を結びます…8 5.3. ジェネリックアルゴリズム…9 6. IANA問題…12
Luo Standards Track [Page 1] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[1ページ]。
7. Security Considerations ........................................12
8. Acknowledgement ................................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
7. セキュリティ問題…12 8. 承認…13 9. 参照…13 9.1. 標準の参照…13 9.2. 有益な参照…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]はPointからポイントへのプロトコル(PPP)、[RFC2661]でサポートされた唯一のプロトコル以外に複数のLayer2プロトコルを運ぶためにダイナミックなトンネリングメカニズムを定義します、パケットを拠点とするネットワークの上で。 基線プロトコルは様々なタイプのアプリケーションをサポートします。(アプリケーションは[RFC3931]の異なったLayer2Tunnelingプロトコル(L2TP)規範モデルで強調されました)。 L2TP Access Concentrator(LAC)はその十字接続付属回路とL2TPセッションのL2TP Control Connection Endpoint(LCCE)です。 層2のVirtual兵士のNetwork(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.
このドキュメントはL2VPNアプリケーションの中でシグナリングが議定書を作るのでL2TPv3を使用することに関して共通点と違いについて議論します。 本書では、頭文字語"L2TP"はL2TPv3か一般に、L2TPを示します。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Network Reference Model
2. ネットワーク規範モデル
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規範モデルでは、LACは十字接続として付属回路とL2TPセッションの間で機能します。 それぞれのL2TPセッションはまた、pseudowireとして知られている見習われた回路として機能します。 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はProvider Edge(PE)デバイスです。 LACとPEはこのドキュメントの文脈の交換可能な用語です。 LAC-LAC規範モデルのリモートシステムはCustomer Edge(CE)デバイスです。
Luo Standards Track [Page 2] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[2ページ]。
+----+ L2 +----+ +----+ L2 +----+ | CE |------| PE |....[core network]....| PE |------| CE | +----+ +----+ +----+ +----+
+----+ L2+----+ +----+ L2+----+ | Ce|------| PE|....[コアネットワーク]…| PE|------| Ce| +----+ +----+ +----+ +----+
|<- emulated service ->|
|<----------------- L2 service -------------->|
| <によって見習われたサービス、->| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- L2サービス-------------->|
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.
簡単な十字接続アプリケーションでは、付属回路は混載業者が直接pseudowireに付いたということです。 それは1〜1つのマッピングです。 pseudowireを通して地方のPEの上の付属回路から受け取られたトラフィックをリモートPEに送ります。 リモートPEがpseudowireからトラフィックを受けるとき、それは終わりの対応する付属回路にトラフィックを送ります。 推進決定は付属回路かpseudowire逆多重化識別子に基づいています。
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.
Virtual兵士のLAN Service(VPLS)と共に、Virtual Switching Instance(VSI)は1付属回路とpseudowiresに関連している混載業者です。 単一のpseudowireは、1組のVSIsを2じっと見るPEsに接続するのに使用されます。 最初に、付属回路かpseudowire逆多重化識別子に基づく対応するVSIに付属回路かpseudowireから受け取られたトラフィックを送ります。 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.
Virtual兵士のWire Service(VPWS)と共に、付属回路は「有色のプール」に分類されます。 各プールは、混載業者であり、二地点間十字接続のネットワークを通して接続されます。 データ推進見解は十字接続アプリケーションと同じです。 しかしながら、有色のプールを建築すると、より複雑なシグナリング手順はかかわります。
3. Forwarder Identifier
3. 混載業者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として指示されたAttachment Group Identifier(AGI)とAttachment Individual Identifier(AII)の連結と定義されます、AII>。 AGIは、シグナリング目的のために1セットの混載業者を分類するのに使用されます。 AIIは、グループの中で混載業者を区別するのに使用されます。 AIIはプラットホームかグループあたり1個のベースでユニークである場合があります。
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のために値について決めるのは実装まで達しています。
Luo Standards Track [Page 3] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[3ページ]。
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はSource AII(SAII)として知られています、そして、目標混載業者のAIIはTarget AII(TAII)として知られています。 したがって、<阿木、SAII>と<阿木、TAII>としてそれぞれソース混載業者と目標混載業者を指示できます。
4. Protocol Components
4. プロトコルコンポーネント
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セットのセッション管理手順を定義します: かかってきた電話と発信電話。 シグナリングL2VPNsに発信電話手順を用いるのが完全に可能ですが、かかってきた電話手順に、意味論の関連性に関していくつかの利点があります。 [PWE3L2TP]はpseudowiresをセットアップするには、かかってきた電話手順が、より適切である理由に関するその他の詳細を与えます。
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:
以下のセクションで説明されたL2VPNsのためのシグナリング手順は.1セクション3.3と3.4[RFC3931]でそれぞれ定義されたControl Connection ManagementとIncoming Call手順に基づいています。 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のための既存のAVPs
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で定義された以下のAttribute Valueペア(AVPs)、.4、シグナリングL2VPNsにおいて、5.4に、.5[RFC3931]が使用されています。
Router ID
ルータID
The Router ID sent in SCCRQ and SCCRP during control connection
setup establishes the unique identity of each PE.
コントロール接続設定の間のSCCRQとSCCRPで送られたRouter 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.
Pseudowire Capabilities ListはSCCRQを送りました、そして、SCCRPは発信しているPEによってサポートされたpseudowireタイプを示します。 それは広告として単に受信PEに機能します。 内容はコントロール接続設定に影響するべきではありません。
Luo Standards Track [Page 4] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[4ページ]。
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が特定のpseudowireタイプのセッションをリモートPEに開始する前に、リモートPEがこのAVPのこのpseudowireタイプの広告を出したかどうか調べなければなりません、そして、意図しているpseudowireタイプがリモートPEによってサポートされないなら、SHOULD NOTはセッションを開始するのを試みます。
Pseudowire Type
Pseudowireはタイプします。
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.
Pseudowire TypeはICRQ信号で意図しているpseudowireタイプを受信PEに送りました。 受信PEはローカルのpseudowire能力リストに対してそれをチェックします。 マッチを見つけるなら、それはICRPと共にPseudowire Type AVPなしで応じます。(それとなく、Pseudowire Type AVPは意図しているpseudowireの承認を承諾します)。 マッチを見つけないなら、それは分離して通知している(CDN)Call、「サポートされないpseudowireタイプ」結果コードで応じなければなりません。
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.
ICRQ、ICRP、およびICCNでL2特有のSublayerを送ることができます。 受信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に知らせるためにICRQとICRPの両方で発信しているPEにCircuit Statusを送ります。 また、状態をアップデートするために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.
指定された混載業者識別子に合っている混載業者に提案されたpseudowireを縛るよう受信PEに命令するために任意のAGIと共にTAII値をRemote End ID AVPでコード化して、ICRQで送ります。
4.3. New AVPs for L2VPN
4.3. L2VPNのための新しいAVPs
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
AGI AVP(Attribute Type89)は論理的なグループに混載業者を関連づけるのに使用される識別子です。 AGI AVPはLocal End ID AVPとRemote End ID AVPに関連して使用されます。ID AVPは、特定の混載業者を特定するためにそれぞれSAIIとTAIIをコード化します。 AGI AVPがコントロールメッセージで省略されるか、または使用する値、混載業者が考えられるゼロ・レングスを含んでいる場合
Luo Standards Track [Page 5] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[5ページ]。
the default AGI. Note that there is only one designated default
AGI value for all forwarders.
デフォルトAGI。 すべての混載業者のためにデフォルト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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 89 | AGI(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AGI field is a variable-length field. This AVP MAY be present
in ICRQ.
AGI分野は可変長の分野です。 このAVP MAY、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 MAY、隠されてください(Hビットは、0か1であるかもしれません)。 AVP属性値の隠れることは[RFC3931]のセクション5.3で定義されます。 MはこのAVP SHOULDのために噛み付きました。0に設定されます。 このAVPのLength(隠れることの前の)はAGI分野の6つの八重奏と長さです。
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.
Local End ID AVP(Attribute Type90)はSAII値をコード化します。 また、SAIIは、TAIIに関連してpseudowire結びつきを検出するのに使用されるかもしれません。 それがコントロールメッセージで省略されるとき、それには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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 90 | SAII(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SAII field is a variable-length field. This AVP MAY be
present in ICRQ.
SAII分野は可変長の分野です。 このAVP MAY、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 MAY、隠されてください(Hビットは、0か1であるかもしれません)。 MはこのAVP SHOULDのために噛み付きました。0に設定されます。 このAVPのLength(隠れることの前の)はSAII分野の6つの八重奏と長さです。
Interface Maximum Transmission Unit
マキシマム・トランスミッション・ユニットを連結してください。
The Interface Maximum Transmission Unit (MTU) AVP, Attribute Type
インタフェースマキシマム・トランスミッション・ユニット(MTU)AVP、属性タイプ
Luo Standards Track [Page 6] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[6ページ]。
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を示します。 両方の方向に広告を出すなら、与えられたpseudowireのMTU値は同じであるに違いありません。 それらであるなら、マッチ、pseudowire SHOULDは設立されませんか? このAVPがどちらかの方向によるコントロールメッセージで省略されるとき、リモートPEには合図されるpseudowireのための地方の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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 91 | インタフェース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.
Interface MTU分野は2八重奏の整数値です。 このAVP MAY、ICRQとICRPに存在してください。 PEがそれ自身のものと異なったMTU値でInterface 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 MAY、隠されてください(Hビットは、0か1であるかもしれません)。 MはこのAVP SHOULDのために噛み付きました。0に設定されます。 このAVPのLength(隠れることの前の)は8つの八重奏です。
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.
相互運用性を確実にするために、既存のAVPsの設定がL2VPNアプリケーションで使用した義務的な(M)ビットはものが[RFC3931]で指定したのと同じであるべきです。 ジェネリックM-ビット処理は[RFC3931]のセクション5.2で説明されます。 新しいAVPsのM-ビットを1に設定すると、相互運用性は損なわれるでしょう。
5. Signaling Procedures
5. シグナリング手順
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.
PEが地元の混載業者のひとりに混載業者識別子を割り当てて、あるForwarder IDを持っているリモートPEでリモート混載業者にpseudowireをセットアップするのが必要であることを知っていると仮定してください。 手動の構成か何らかの自動発見手順でこの知識を得ることができます。
Before establishing the intended pseudowire, each pair of peering PEs
意図しているpseudowire、各組のじっと見ているPEsを設立する前に
Luo Standards Track [Page 7] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[7ページ]。
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.
交換はコントロール接続を確立する接続メッセージを制御します。 それぞれが[PWE3IANA]、Pseudowire Capabilities List AVPで定義されるようにサポートしているpseudowireタイプの広告を出します。
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が、pseudowireがそれがセットアップするつもりであるタイプであるとサポートするかどうか調べます。 リモートPEが意図しているpseudowireをサポートする場合にだけ、pseudowire接続要求を開始するなら、タイプしてください。
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がpseudowire接続のためにICRQを受けるとき、以下を決定するために阿木、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に接する試み)は、権限のない混載業者に接するのを試みます。
5.2. Pseudowire Tie Detection
5.2. Pseudowire繋がりの検出
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にpseudowireを開始するとき、PEsは同時に、結局、互いにpseudowireを開始するかもしれません。 2人の混載業者の間でコピーされたpseudowiresをセットアップするのを避けるために、それぞれのPEは独自にそのようなpseudowire繋がりを検出できなければなりません。 以下の手順は、繋がりを検出するために続かれる必要があります:
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を比べます。 the
Luo Standards Track [Page 8] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[8ページ]。
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値にprependedされた1番目です。
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.
繋がりがいったん発見されると、PEは標準のL2TP繋がりの壊れている手順を用います、コピーされたpseudowireから切断するために.4セクション5.4[RFC3931]で説明されるように。
5.3. Generic Algorithm
5.3. ジェネリックアルゴリズム
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.
与えられたVPNのすべての地元の混載業者から成って、各PEは最初に、リスト、SOURCE_FORWARDERSを形成します。 そして、それは別のリスト(TARGET_FORWARDERS)の中へのすべてのインタコネクトされる必要がある地元の混載業者と同じVPNのすべてのリモート混載業者を置きます。 ネットワーク形態の構成は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のあらゆる参加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人の混載業者が異なったRouter IDに関連しているなら、それらの間にpseudowireを設立しなければなりません。 ステップ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. <AGI、2人の混載業者の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にともに住んでいて、pseudowireは全く必要ではありません。 PEは2人の混載業者の間で単に地方の十字接続を作成します。 ステップ2に戻ってください。
6. As the source and target forwarders reside on different PEs,
6. ソースと目標として、混載業者は異なったPEsに住んでいます。
Luo Standards Track [Page 9] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[9ページ]。
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.
それらの間にpseudowireを設立しなければなりません。 PEは、最初に、ソース混載業者が既に目標混載業者にpseudowireを設立したかどうか調べます。 そうだとすれば、ステップ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. 1つが既に存在していなくて、またpseudowireが全くソースと目標混載業者の間に既に設立されないなら、地方の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はリモートPEにICRQを送ります。 阿木、TAII、およびSAII値はAGI AVP、Remote End ID AVP、およびLocal End 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はソース混載業者をpseudowireに縛って、リモートPEにICCNを送ります。 ステップ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であるなら、ステップ2に戻ってください。 それがICCNであるなら、地方のPEはソース混載業者をpseudowireに縛って、ステップ2に戻ってください。
The following diagram illustrates the above procedure:
以下のダイヤグラムは上の手順を例証します:
Luo Standards Track [Page 10] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[10ページ]。
---------> 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 | |
--------->選択次| ソース混載業者| | | | | Nに対して| ソース混載業者を設立しますか? ---------->エンド| | | Y| | v| 次の<を選んでください。-------------------------------- | Target混載業者| | | | | | | | N v| -------- Target混載業者を設立しますか? | | | Y| | Y Yに対して| 同じRouter ID? ------>の同じ混載業者ID? ------| | | | N| N| | | v| | ローカルを創造してください。-------| vはCross接続します。| 既に、YをPseudowireします。| 確立-------------------------------| ソースと目標? | | | N| | v| 地方の開始Pseudowire| リモートへの接続要求| | | | | v| -------メッセージのための>の地方の待ち| | ----- かけ離れる-------------- | | | | | | | | | | vに対して| | ローカルが受信する、PseudowireローカルはPseudowireを受け取ります。| | 接続要求接続応答| | かけ離れるのとかけ離れる| | | | | | | | | | v Nに対して| | 接続が受け入れたPseudowireを実行しますか? --------| | 繋がりの検出| |
Luo Standards Track [Page 11] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[11ページ]。
| | 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
| | Y| | | | v| | | ローカルのひものソース---------| | | Pseudowireへの混載業者| | | | | N Nに対して| | 検出された繋がり? ----->はリモートな状態で受け入れます。----->廃棄物------| | | 接続要求? リモート要求| | Y| ^ | | | v| | Y| | 繋がりの壊すことを実行してください。| ------>の地方のひも---- | | | ソース混載業者| | | Pseudowireに| Nに対して| | 勝たれた繋がりの壊すこと? ------>分離| | 市内接続| Y| | v------ リモート接続要求を無視してください。
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:
このドキュメントはIANAによって割り当てられた3つの新しいL2TPコントロールメッセージAttribute Valueペア(AVPs)を定義します。 これらは、セクション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はCDNメッセージのためのIANAによって割り当てられた3つの新しい結果コードを定義します:
23 - Mismatching interface MTU
24 - Attempt to connect to non-existent forwarder
25 - Attempt to connect to unauthorized forwarder
23(インタフェースMTU24にミスマッチする)は、実在しない混載業者25に接するのを試みます--権限のない混載業者に接するのを試みてください。
7. Security Considerations
7. セキュリティ問題
This specification does not introduce any additional security considerations beyond those discussed in [RFC3931] and [L2VPNFW].
この仕様は[RFC3931]と[L2VPNFW]で議論したものを超えてどんな追加担保問題も紹介しません。
Luo Standards Track [Page 12] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[12ページ]。
8. Acknowledgement
8. 承認
The author would like to thank Mark Townsley and Carlos Pignataro for their valuable input.
作者は彼らの貴重な入力についてマークTownsleyとカルロスPignataroに感謝したがっています。
9. References
9. 参照
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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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)」、RFC3931、3月2005日
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.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進む」BCP116、RFC4446、2006年4月。
[L2VPNFW] Andersson L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, September
2006.
エド[L2VPNFW]アンデションL.、E.ローゼン、エド、「層2の仮想私設網(L2VPNs)のためのフレームワーク」、RFC4664、9月2006日
[PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", Work in Progress.
[PWE3L2TP]W.Townsleyと「進行中のPseudowiresと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.はあしらいます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
Author's Address
作者のアドレス
Wei Luo Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ウェイ羅シスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア 95134
EMail: luo@cisco.com
メール: luo@cisco.com
Luo Standards Track [Page 13] RFC 4667 L2VPN Extensions for L2TP September 2006
羅Standardsは2006年9月にL2TPのためにRFC4667L2VPN拡張子を追跡します[13ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Luo Standards Track [Page 14]
羅標準化過程[14ページ]
一覧
スポンサーリンク
