RFC4951 日本語訳
4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP)"failover". V. Jain, Ed.. August 2007. (Format: TXT=53659 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Jain, Ed. Request for Comments: 4951 Riverstone Networks Category: Standards Track August 2007
ワーキンググループのV.ジャイナ教徒、エドをネットワークでつないでください。コメントのために以下を要求してください。 4951 リバーストンはカテゴリをネットワークでつなぎます: 標準化過程2007年8月
Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"
層2のトンネリングプロトコル(L2TP)「フェイルオーバー」のためのフェイルオーバー拡大
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints. Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection. When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity.
層2のTunnelingプロトコル(L2TP)はアクティブな終点の間の共有された状態がある接続指向のプロトコルです。 この何らかの共有された状態が、操作に重大ですが、現実に不安定であるかもしれません、L2TP Control Connectionで使用されるパケット一連番号などのように。 コントロール接続の半面の失敗が起こるとき、新しいコントロール接続は、年取った接続に関して情報交換することによって、年取った接続に作成されて、関連づけられます。 そのようなメカニズムはいくつかの映された接続州があるアクティブなフェイルオーバーのために交換として意図するのではなく、それらのすぐに利用可能に持っているのが特に難しいパラメタのための援助として意図します。 本書では定義されたL2TPへのプロトコル拡大が州の回復を容易にすることを意図します、追加弾性をL2TPネットワークに提供して、リモートシステムの層の2の接続性を改良して。
Jain, et al. Standards Track [Page 1] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Abbreviations ..............................................5
1.3. Specification of Requirements ..............................5
2. Overview ........................................................5
3. Failover Protocol ...............................................7
3.1. Failover Capability Negotiation ............................7
3.2. Failover Recovery Procedure ................................7
3.2.1. Recovery Tunnel Establishment .......................8
3.2.2. Control Channel Reset ..............................10
3.2.3. Data Channel Reset .................................10
3.3. Session State Synchronization .............................11
4. New Control Messages ...........................................12
4.1. Failover Session Query ....................................13
4.2. Failover Session Response .................................13
5. New Attribute Value Pairs ......................................14
5.1. Failover Capability AVP ...................................14
5.2. Tunnel Recovery AVP .......................................15
5.3. Suggested Control Sequence AVP ............................16
5.4. Failover Session State AVP ................................17
6. Configuration Parameters .......................................18
7. IANA Considerations ............................................19
8. Security Considerations ........................................19
9. Acknowledgements ...............................................19
10. Contributors ..................................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................20
Appendix A ........................................................21
Appendix B ........................................................23
Appendix C ........................................................24
1. 序論…3 1.1. 用語…4 1.2. 略語…5 1.3. 要件の仕様…5 2. 概観…5 3. フェイルオーバープロトコル…7 3.1. フェイルオーバー能力交渉…7 3.2. フェイルオーバーリカバリ手順…7 3.2.1. 回復トンネル設立…8 3.2.2. チャンネルリセットを制御してください…10 3.2.3. データはリセットを向けます…10 3.3. セッション州の同期…11 4. 新しいコントロールメッセージ…12 4.1. フェイルオーバーセッション質問…13 4.2. フェイルオーバーセッション応答…13 5. 新しい属性値ペア…14 5.1. フェイルオーバー能力AVP…14 5.2. 回復AVPにトンネルを堀ってください…15 5.3. 制御配列AVPは勧めました…16 5.4. フェイルオーバーセッション州のAVP…17 6. 構成パラメタ…18 7. IANA問題…19 8. セキュリティ問題…19 9. 承認…19 10. 貢献者…20 11. 参照…20 11.1. 標準の参照…20 11.2. 有益な参照…20 付録A…21 付録B…23 付録C…24
Jain, et al. Standards Track [Page 2] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[2ページ]。
1. Introduction
1. 序論
The goal of this document is to aid the overall resiliency of an L2TP endpoint by introducing extensions to RFC 2661 [L2TPv2] and RFC 3931 [L2TPv3] that will minimize the recovery time of the L2TP layer after a failover, while minimizing the impact on its performance. Therefore, it is assumed that the endpoint's overall architecture is also supportive in the resiliency effort.
このドキュメントの目標はフェイルオーバーの後に性能への影響を最小にしている間にL2TP層の回復時間を最小にするRFC2661[L2TPv2]とRFC3931[L2TPv3]に拡大を紹介することによってL2TP終点の総合的な弾性を支援することです。 したがって、また、終点の総合的な構造も弾性の努力で支持していると思われます。
To ensure proper operation of an L2TP endpoint after a failover, the associated information of the control connection and sessions between them must be correct and consistent. This includes both the configured and dynamic information. The configured information is assumed to be correct and consistent after a failover, otherwise the tunnels and sessions would not have been setup in the first place.
フェイルオーバーの後にL2TP終点の適切な操作を確実にするために、それらの間のコントロール接続とセッションの関連情報は、正しくて、一貫していなければなりません。 これは構成されてダイナミックな情報を含んでいます。 フェイルオーバーの後に正しくて、構成された情報を一貫させていると思われます。さもなければ、第一に、トンネルとセッションはセットアップでないでしょう。
The dynamic information, which is also referred to as stateful information, changes with the processing of the tunnel's control and data packets. Currently, the only such information that is essential to the tunnel's operation is its sequence numbers. For the tunnel control channel, the inconsistencies in its sequence numbers can result in the termination of the entire tunnel. For tunnel sessions, the inconsistency in its sequence numbers, when used, can cause significant data loss, which gives the perception of a "service loss" to the end user.
動的情報(また、stateful情報と呼ばれる)はトンネルのコントロールとデータ・パケットの処理を交換します。 現在、唯一のトンネルの操作に不可欠のそのような情報がその一連番号です。 トンネル制御チャンネルのために、一連番号における矛盾は全体のトンネルの終了をもたらすことができます。 トンネルセッションのために、使用されると、一連番号における矛盾が有意義な資料の損失をもたらすことができます。(損失は、「サービス損失」の認知をエンドユーザに与えます)。
Thus, an optimal resilient architecture that aims to minimize "service loss" after a failover, must make provisions for the tunnel's essential stateful information, i.e., its sequence numbers. Currently, there are two options available: the first option is to ensure that the backup endpoint is completely synchronized with the active endpoint, with respect to the control and data sessions sequence numbers. The other option is to reestablish all the tunnels and their sessions after a failover. The drawback of the first option is that it adds significant performance and complexity impact to the endpoint's architecture, especially as tunnel and session aggregation increases. The drawback of the second option is that it increases the "service loss" time, especially as the architecture scales.
その結果、フェイルオーバーの後に「サービス損失」を最小にすることを目指して、トンネルの不可欠のstateful情報(すなわち、一連番号)に備えなければならない最適の弾力がある構造。 現在、利用可能な2つのオプションがあります: 第1の選択はバックアップ終点がアクティブな終点に完全に連動するのを保証することです、コントロールとデータセッション一連番号に関して。 別の選択肢はフェイルオーバーの後にすべてのトンネルと彼らのセッションを回復させることです。第1の選択の欠点は重要な性能と複雑さが終点の構造に影響を与えると言い足すということです、特にトンネルとセッション集合が増えるように。 2番目のオプションの欠点は特に構造が比例するように「サービス損失」時間を増加させるということです。
To alleviate the above-mentioned drawbacks of the current options, this document introduces a mechanism to bring the dynamic stateful information of a tunnel to a correct and consistent state after a failure. The proposed mechanism defines the recovery of tunnels and sessions that were in an established state prior to the failure.
現在のオプションの上記の欠点を軽減するなら、このドキュメントは、失敗の後にトンネルのダイナミックなstateful情報を正しくて一貫した状態にもたらすためにメカニズムを紹介します。 提案されたメカニズムは失敗の前に、設立された状態にあったトンネルとセッションの回復を定義します。
Jain, et al. Standards Track [Page 3] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[3ページ]。
1.1. Terminology
1.1. 用語
Endpoint: L2TP control connection endpoint, i.e., either LAC or LNS (also known as LCCE in [L2TPv3]).
終点: L2TPは接続終点、すなわち、LACかLNS(また、LCCEとして、[L2TPv3]では、知られている)のどちらかを制御します。
Active Endpoint: An endpoint that is currently providing service.
アクティブな終点: 現在サービスを提供している終点。
Backup Endpoint: A redundant endpoint standing by for the active endpoint that has its database of active tunnels and sessions in sync with its active endpoint.
終点のバックアップをとってください: アクティブな終点と共に同時性におけるアクティブなトンネルとセッションに関するデータベースを持っているアクティブな終点にそばにいる余分な終点。
Failed Endpoint: The endpoint that was the active endpoint at the time of the failure.
終点に失敗します: 失敗時点でアクティブな終点であった終点。
Recovery Endpoint: The endpoint that initiates the failover protocol to recover from the failure of an active endpoint.
回復終点: アクティブな終点の失敗から回復するためにフェイルオーバープロトコルを開始する終点。
Remote Endpoint: The endpoint that peers with active endpoint before failure and with recovery endpoint after failure.
遠く離れた終点: 失敗の後に失敗の前のアクティブな終点と回復終点でじっと見る終点。
Failover: The action of a backup endpoint taking over the service of an active endpoint. This could be due to administrative action or failure of the active endpoint.
フェイルオーバー: アクティブな終点のサービスを引き継ぐバックアップ終点の動作。 これはアクティブな終点の管理動作か失敗のためであるかもしれません。
Old Tunnel: A control connection that existed before failure and is subjected to recovery upon failover.
古いトンネル: 失敗の前に存在して、フェイルオーバーで回復にかけられるコントロール接続。
Recovery Tunnel: A new control connection established only to recover an old tunnel.
回復トンネル: 確立された古いトンネルを回収する新しいコントロール接続。
Recovered Tunnel: After an old tunnel's control connection and sessions are restored using the mechanism described in this document, it is referred to as a Recovered Tunnel.
回復しているトンネル: 古いトンネルのコントロール接続とセッションが本書では説明されたメカニズムを使用することで復元された後に、それはRecovered Tunnelと呼ばれます。
Control Channel Failure: Failure of the component responsible for establishing/maintaining tunnels and sessions at an endpoint.
チャンネルの故障を制御してください: 終点でトンネルとセッションを確立するか、または維持するのに原因となるコンポーネントの失敗。
Data Channel Failure: Failure of the component responsible for forwarding the L2TP encapsulated data.
データは失敗を向けます: L2TPを進めるのに原因となるコンポーネントの失敗はデータを要約しました。
Jain, et al. Standards Track [Page 4] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[4ページ]。
1.2. Abbreviations
1.2. 略語
LAC L2TP Access Concentrator LNS L2TP Network Server LCCE L2TP Control Connection Endpoint AVP Attribute Value Pair SCCRQ Start-Control-Connection-Request SCCRP Start-Control-Connection-Reply ZLB Zero Length Body Message
ラックL2TPアクセス集中装置LNS L2TPネットワークサーバLCCE L2TPコントロール接続終点AVP属性値組SCCRQスタートコントロール接続要求SCCRPスタートコントロール接続回答ZLBは長さのボディーメッセージのゼロに合っています。
1.3. Specification of Requirements
1.3. 要件の仕様
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. Overview
2. 概観
The following diagram depicts the redundancy architecture and pertaining entities used to describe the failover protocol:
冗長構造は以下のダイヤグラムは表現されます、そして、実体を関係させると、フェイルオーバープロトコルは以前はよく説明されていました:
+--------------+
| L2TP active |
+----------+ ----| endpoint (A) |
| L2TP | / +--------------+
| endpoint |----------------------/
| (R) | \ +--------------+
+----------+ \ | L2TP backup |
----| endpoint (B) |
+--------------+
+--------------+ | L2TPアクティブです。| +----------+ ----| 終点(A)| | L2TP| / +--------------+ | 終点|----------------------/ | (R) | \ +--------------+ +----------+ \ | L2TPバックアップ| ----| 終点(B)| +--------------+
Active and backup endpoints may reside on the same device, however, they are not required to be that way. On other hand, some devices may not have a standby module altogether, in which case the failed endpoint, after reset, can become the recovery endpoint to recover from its prior failure.
アクティブ、そして、バックアップ終点は同じ装置で住んでいるかもしれなくて、しかしながら、それらはその道であることが必要ではありません。 他の手の上では、いくつかの装置は全体で予備モジュールを持っていないかもしれません、その場合、リセットされた後に失敗した終点が先の失敗から回復する回復終点になることができます。
Therefore, in the above diagram, upon A's (active endpoint's) failure:
したがって、Aのところ(アクティブな終点のもの)で上記では、失敗を図解してください:
- Endpoint A would be called the failed endpoint.
- 終点Aは失敗した終点と呼ばれるでしょう。
- If B is present, then it would become the recovery endpoint and
also an active endpoint.
- Bが存在しているなら、それは回復終点とアクティブな終点にもなるでしょう。
- If B is not present, then A could become the recovery endpoint
after it restarts, provided it saved the information about
active tunnels/sessions in some persistent storage.
- Bが存在していないなら、再開した後にAは回復終点になるかもしれません、いくらかのしつこい格納における活発なおよそトンネル/セッション情報を保存したなら。
Jain, et al. Standards Track [Page 5] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[5ページ]。
- R does not initiate the failover protocol; rather it waits for a
failure indication from recovery endpoint.
- Rはフェイルオーバープロトコルを開始しません。 むしろそれは回復終点から失敗指示を待っています。
This document assumes that the actual detection of a failure in the backup endpoint is done in an implementation-specific way. It also assumes that failure detection by the backup endpoint is faster than the L2TP control channel timeout between the active and remote endpoints. Typically, active and backup endpoints reside on the same physical device, allowing fast and reliable failure detection without the need to communicate between these endpoints over the network.
このドキュメントは、バックアップ終点での失敗の実際の検出が実現特有の方法で完了していると仮定します。 また、それは、バックアップ終点のそばでの失敗検出がアクティブで遠く離れた終点の間のL2TPコントロールチャンネルタイムアウトより速いと仮定します。 通常、アクティブ、そして、バックアップ終点は同じフィジカル・デバイスで住んでいます、これらの終点の間でネットワークの上に交信する必要性なしで速くて信頼できる失敗検出を許して。
Similarly, an active endpoint that acts also as a backup endpoint can easily start the recovery once it has rebooted. However, when the active and backup endpoints reside in separate devices, there is a need for communication between them in order to detect failures. As a solution for such situations, additional failure detection protocols, e.g., [BFD-MULTIHOP], may be needed.
同様に、いったんリブートすると、また、バックアップ終点として機能するアクティブな終点は容易に回復を始めることができます。 しかしながら、アクティブ、そして、バックアップ終点が別々の装置に住んでいるとき、それらのコミュニケーションの必要が、失敗を検出するためにあります。 そのような状況の解決策として、追加失敗検出プロトコル例えば、[BFD-MULTIHOP]が必要であるかもしれません。
A device could have three kinds of failures:
装置には、3種類の失敗があるかもしれません:
i) Control Channel Failure
i) コントロールチャンネルの故障
ii) Data Channel Failure
ii) データ・チャンネルの故障
iii) Control and Data Channel Failure
iii) コントロールとデータ・チャンネルの故障
The protocol described in this document specifies the recovery in conditions i) and iii). It is perceived that not much (stateful information) could be recovered via a control protocol exchange in case of ii).
本書では説明されたプロトコルは状態i)とiii)で回復を指定します。 ii)の場合の制御プロトコル交換で多く(stateful情報)を回復できるというわけではないだろうと知覚されます。
The failover protocol consists of three phases:
フェイルオーバープロトコルは三相から成ります:
1) Failover Capability Negotiation: An active endpoint and a remote
endpoint exchange failover capabilities and attributes to be used
during the recovery process.
1) フェイルオーバー能力交渉: アクティブな終点と遠く離れた終点は、回復の過程の間、使用されるためにフェイルオーバー能力と属性を交換します。
2) Failover Recovery: A recovery endpoint establishes a new L2TP
control connection (called recovery tunnel) for every old tunnel
that it wishes to recover. The recovery tunnel serves three
purposes:
2) フェイルオーバー回復: 回復終点はそれが回収したがっているあらゆる古いトンネルに新しいL2TPコントロール接続を確立します(回復トンネルと呼ばれます)。回復トンネルは3つの目的に役立ちます:
- It identifies the old tunnel that is being recovered.
- それは回収されている古いトンネルを特定します。
- It provides a means of authentication and a three-way handshake
to ensure both ends agree on the failover for the specified old
tunnel.
- それは認証と3方向ハンドシェイクが、両端が指定された古いトンネルにフェイルオーバーに同意するのを保証する手段を提供します。
Jain, et al. Standards Track [Page 6] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[6ページ]。
- It could exchange the Ns and Nr values to be used in the
recovered tunnel.
- それは、回復しているトンネルで使用されるためにNsとNr値を交換するかもしれません。
Upon establishing the recovery tunnel, two endpoints reset the
control and data channel(s) on the recovered tunnel using the
procedures described in Section 3.2.2 and Section 3.2.3,
respectively. The recovery tunnel could be torn down after that,
and sessions that were established resume traffic.
回復トンネルを確立して、2つの終点が、回復しているトンネルの上にセクション3.2.2とセクション3.2.3でそれぞれ説明された手順を用いることでコントロールとデータ・チャンネルをリセットしました。 その後に回復トンネルを取りこわすことができました、そして、確立されたセッションは交通を再開します。
3) Session State Synchronization: The session state synchronization
process occurs on the recovered or the old tunnel and allows the
two endpoints to agree on the state of the various sessions in the
tunnel after failover. The inconsistency, which could arise due
to the failure, is handled in the following manner: first, the two
endpoints silently clear the sessions that were not in the
established state. Then, they utilize Failover Session Query
(FSQ) and Failover Session Response (FSR) on the recovered tunnel
to obtain the state of sessions as known to the peer endpoint and
clear the sessions accordingly.
3) セッション州の同期: フェイルオーバー矛盾(失敗のため起こることができた)が以下の方法で扱われた後に、セッション州の同期の過程は、回復か古いトンネルの上に起こって、2つの終点がトンネルでの様々なセッションの状態に同意するのを許容します: まず最初に、2つの終点が静かに設立された状態になかったセッションをクリアします。 そして、彼らは、同輩終点に知られているようにセッションの状態を得て、それに従って、セッションをクリアするのに、回復しているトンネルの上のFailover Session Query(FSQ)とFailover Session Response(FSR)を利用します。
3. Failover Protocol
3. フェイルオーバープロトコル
The protocol consists of three steps describing specifications during the life of a control connection - before and after failover.
プロトコルはフェイルオーバーの前後にコントロール接続の人生の間に仕様を説明する3ステップから成ります。
3.1. Failover Capability Negotiation
3.1. フェイルオーバー能力交渉
The active and remote endpoints exchange the Failover Capability attribute-value pair (AVP) in Start-Control-Connection-Request (SCCRQ) and Start-Control-Connection-Reply (SCCRP) during control connection establishment as a part of the normal (before failover) operation. The Failover Capability AVP, defined in Section 5.1, allows an endpoint to specify if it is control and/or data channel failover capable and the time allowed for the recovery for the tunnel.
アクティブで遠く離れた終点はコントロールコネクション確立の間、通常(フェイルオーバーの前の)の操作の一部としてStartコントロール接続要求(SCCRQ)とStartコントロール接続回答(SCCRP)でFailover Capability属性値組(AVP)を交換します。 それがコントロール、そして/または、できるデータ・チャンネルフェイルオーバーと日限であるかどうかセクション5.1で定義されたFailover Capability AVPはトンネルとして回復に終点を指定させます。
3.2. Failover Recovery Procedure
3.2. フェイルオーバーリカバリ手順
The Failover Recovery Procedure described in this section is performed only if there was a control channel failure. The selection of the tunnels to be recovered is implementation specific.
コントロールチャンネルの故障があった場合にだけ、このセクションで説明されたFailover Recovery Procedureは実行されます。 回復するべきトンネルの品揃えは実現特有です。
The Failover Recovery Procedure consists of following three steps, which are described in detail in the subsections below:
Failover Recovery Procedureは以下の小区分で詳細に説明される3つの方法に従うのから成ります:
- Recovery tunnel establishment
- 回復トンネル設立
- Control channel reset
- コントロールチャンネルリセット
Jain, et al. Standards Track [Page 7] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[7ページ]。
- Data channel reset
- データ・チャンネルリセット
3.2.1. Recovery Tunnel Establishment
3.2.1. 回復トンネル設立
The recovery endpoint establishes a new control connection, called recovery tunnel, for every old tunnel it wishes to recover. The purpose of the recovery tunnel is solely to recover the corresponding old tunnel. There is a one to one relationship between recovery tunnel and recovered/old tunnel
回復終点は回復トンネルと呼ばれる新しいコントロール接続をそれが回収したがっているあらゆる古いトンネルに確立します。回復トンネルの目的は唯一対応する古いトンネルを回収することです。 回復トンネルと回復しているか古いトンネルの間には、1〜1つの関係があります。
Recovery tunnel establishment considerations:
回復トンネル設立問題:
- An LCCE MUST follow the procedures described in [L2TPv2] or
[L2TPv3] to establish the recovery tunnel.
- LCCE MUSTは回復トンネルを証明するために[L2TPv2]か[L2TPv3]で説明された手順に従います。
- The recovery tunnel MUST use the same L2TP version (and
establishment procedures) that was used for the old tunnel.
- 回復トンネルは古いトンネルに使用されたのと同じL2TPバージョン(そして、設立手順)を使用しなければなりません。
- The SCCRQ for Recovery tunnel MUST include the Tunnel Recovery
AVP, defined in Section 5.2, to identify the old tunnel that is
being recovered.
- Recoveryがトンネルを堀るので、SCCRQは回収されている古いトンネルを特定するためにセクション5.2で定義されたTunnel Recovery AVPを含まなければなりません。
- The recovery tunnel MUST NOT include the Failover Capability AVP
in its SCCRQ or SCCRP messages.
- 回復トンネルはSCCRQかSCCRPメッセージにFailover Capability AVPを含んではいけません。
- An endpoint SHOULD NOT send any message other than the following
on the recovery tunnel: SCCRQ, SCCRP, SCCCN, StopCCN, HELLO,
ZLB, and ACK ([L2TPv3] only).
- SHOULD NOTが回復トンネルの以下を除いたどんなメッセージも送る終点: SCCRQ、SCCRP、SCCCN、StopCCN、HELLO、ZLB、およびACK([L2TPv3]専用)。
- An endpoint MUST NOT use any old Tunnel ID for the recovery
tunnel. The old tunnels MUST be valid until the recovery
process concludes.
- 終点は回復トンネルにどんな古いTunnel IDも使用してはいけません。 回復の過程が終わるまで、古いトンネルは有効であるに違いありません。
- An endpoint MUST use the Tie Breaker AVP (Section 4.4.3
[L2TPv2]) or Control Connection Tie Breaker AVP (Section 5.4.3
[L2TPv3]) in the setup of the recovery tunnel to ensure that
only a single recovery tunnel (when both endpoints have
simultaneous failover) is established to recover an old tunnel.
The tunnel that wins the tie is used to decide the suggested Ns
and Nr values on the recovered tunnel. Therefore, the endpoint
that loses the tie, should reset the Ns and Nr values (Section
3.2.2) as if it were a remote endpoint. Appendix B illustrates
the double failover scenario.
- 終点は、単一の回復トンネル(両方の終点に同時のフェイルオーバーがあるとき)だけが古いトンネルを回収するために確立されるのを保証するのに、回復トンネルのセットアップでTie Breaker AVP(セクション4.4.3[L2TPv2])かControl Connection Tie Breaker AVP(セクション5.4.3[L2TPv3])を使用しなければなりません。 繋がりを得るトンネルは、回復しているトンネルの上で提案されたNsとNr値について決めるのに使用されます。 したがって、繋がりを失って、まるでそれが遠く離れた終点であるかのようにNsとNr値(セクション3.2.2)をリセットするべきである終点。 付録Bは二重フェイルオーバーシナリオを例証します。
- Tie Breaker AVP processing: The scope of a tie breaker AVP's
action for recovery and non recovery tunnels must be
independent, and is defined as follows:
- Breaker AVP処理を結んでください: 回復と非回復トンネルのためのタイブレークAVPの動作の範囲は、独立していなければならなくて、以下の通り定義されます:
Jain, et al. Standards Track [Page 8] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[8ページ]。
o When Tie Breaker AVP is used in a non recovery tunnel, the
scope of the tie breaker AVP's action MUST only be within non
recovery tunnels. Therefore, losing a tie against a non
recovery tunnel MUST NOT result in termination of any
recovery tunnel.
o Tie Breaker AVPが非回復トンネルで使用されるとき、非回復トンネルの中にタイブレークAVPの動作の範囲があるだけであるに違いありません。 したがって、非回復トンネルに対して繋がりを失うと、どんな回復トンネルの終了ももたらされてはいけません。
o When a Tie Breaker AVP is used in a recovery tunnel, the
scope of tie breaker AVP's action is further restricted to
the recovery tunnel(s) for a single tunnel to be recovered.
Thus, an implementation MUST apply the tie breaker received
in a recovery tunnel only to those tunnels that are a)
recovery tunnels, and b) associated with the same tunnel to
be recovered. It MUST NOT impact the operation of non-
recovery tunnels and recovery tunnels associated with other
old tunnels to be recovered.
o Tie Breaker AVPが回復トンネルで使用されるとき、タイブレークAVPの動作の範囲は、単一のトンネルが回収されるためにさらに回復トンネルに制限されます。 したがって、実現は回復されるためにa)回復トンネルであるそれらのトンネル、および同じトンネルに関連しているb)だけへの回復トンネルで受けられたタイブレークを適用しなければなりません。 それは、回復されるために非回復しているトンネルと他の古いトンネルに関連している回復トンネルの操作に影響を与えてはいけません。
Upon getting an SCCRQ with a Tunnel Recovery AVP, an endpoint validates the Recover Tunnel ID and the Recover Remote Tunnel ID and responds with an SCCRP. It MUST terminate the recovery tunnel if:
Tunnel Recovery AVPと共にSCCRQを手に入れると、終点は、Recover Tunnel IDとRecover Remote Tunnel IDを有効にして、SCCRPと共に応じます。 それが回復トンネルを終えなければならない、:
- The Recover Tunnel ID or the Recover Remote Tunnel ID is
unknown.
- Recover Tunnel IDかRecover Remote Tunnel IDが未知です。
- The active or remote endpoint (prior to failover) had not
indicated that it was failover capable.
- アクティブであるか遠く離れた終点(フェイルオーバーの前の)は、それがフェイルオーバーできるのを示していませんでした。
- The L2TP version of recovery tunnel is different from the
version used in the old tunnel.
- 回復トンネルのL2TPバージョンは古いトンネルで使用されるバージョンと異なっています。
If the remote endpoint accepts the SCCRQ, it SHOULD include the Suggested Control Sequence AVP, defined in Section 5.3, in the SCCRP message.
遠く離れた終点はSCCRQを受け入れて、それはSuggested Control Sequence AVPであって、セクション5.3で定義されたSHOULDインクルードです、SCCRPメッセージで。
Authentication considerations:
認証問題:
- To authenticate a peer endpoint during recovery tunnel
establishment, an endpoint MUST follow the procedure described
in either [L2TPv2] Section 5.1.1 or [L2TPv3] Section 4.3. It
MUST use the same secret that was used to authenticate the old
tunnel.
- 回復トンネル設立の間、同輩終点を認証するために、終点は[L2TPv2]セクション5.1.1か[L2TPv3]セクション4.3のどちらかで説明された手順に従わなければなりません。 それは古いトンネルを認証するのに使用されたのと同じ秘密を使用しなければなりません。
- Not being able to authenticate could be a reason to terminate
the recovery tunnel.
- 認証するできないのは、回復トンネルを終える理由であるかもしれません。
- For L2TPv3 tunnels, a recovery tunnel MUST use the Control
Message authentication (i.e., exchange the nonce values), as
described in [L2TPv3] Section 4.3, if the old tunnel was
configured to do control message authentication. An L2TPv3
- L2TPv3トンネルのために、回復トンネルはControl Message認証を使用しなければなりません(すなわち、一回だけの値を交換してください)、[L2TPv3]セクション4.3で説明されるように、古いトンネルがコントロール通報認証をするために構成されたなら。 L2TPv3
Jain, et al. Standards Track [Page 9] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[9ページ]。
recovered tunnel MUST reset its nonce values (both endpoints) to
the nonce values exchanged in the recovery tunnel.
回復しているトンネルは一回だけの値(両方の終点)を回復トンネルで交換された一回だけの値にリセットしなければなりません。
For any reason, if the recovery endpoint could not establish the recovery tunnel, then it MUST silently clear the old tunnel and sessions within, concluding that the recovery process has failed.
いずれに関してはも、回復終点が回復トンネル(回復の過程が失敗したと結論を下して、それが静かに古いトンネルとセッションをきれいにしなければならないその時)を確立できないなら、推論してください。
Any control packet received on the recovered tunnel before control channel reset (Section 3.2.2) MUST be silently discarded.
静かに、コントロールチャンネルリセット(セクション3.2.2)を捨てなければならない前にどんなコントロールパケットも回復しているトンネルの上で受信されました。
3.2.2. Control Channel Reset
3.2.2. コントロールチャンネルリセット
Control channel reset allows new control messages to be sent and received over the recovered tunnel.
コントロールチャンネルリセットは回復しているトンネルの上に送られた、受け取られるべき新しいコントロールメッセージを許容します。
Control channel reset procedure:
チャンネルリセット手順を制御してください:
- An endpoint SHOULD flush the transmit/receive windows and reset
the control channel sequence numbers (i.e., Ns and Nr values) on
the recovered tunnel. The control channel on the recovery
endpoint is reset upon getting a valid SCCRP on the recovery
tunnel, whereas the control channel on the remote endpoint is
reset upon getting a valid SCCCN on the recovery tunnel. If the
recovery endpoint did not receive the Suggested Control Sequence
(SCS) AVP in the SCCRP then it MUST reset the Ns and Nr values
to zero. If the remote endpoint opted to not send the SCS AVP
then it MUST reset the Ns and Nr values to zero. Either
endpoint can tear down the recovery tunnel after the control
channel reset procedure is complete.
- 終点SHOULD水洗、窓を送信するか、または受けてください、そして、回復しているトンネルのコントロールチャンネル一連番号(すなわち、NsとNr値)をリセットしてください。 回復トンネルに有効なSCCRPを乗せるとき、回復終点の制御チャンネルはリセットされますが、回復トンネルに有効なSCCCNを乗せるとき、遠く離れた終点の制御チャンネルはリセットされます。 回復終点がSCCRPでSuggested Control Sequence(SCS)AVPを受けなかったなら、それはNsとNr値をゼロにリセットしなければなりません。 遠く離れた終点がSCS AVPを送らないように選ばれたなら、それはNsとNr値をゼロにリセットしなければなりません。 コントロールチャンネルリセット手順が完全になった後にどちらの終点も回復トンネルを取りこわすことができます。
- An endpoint MUST prevent the establishment of new sessions until
it has cleared (or marked for clearance) the sessions that were
not in an established state, i.e., until after Step I, Section
3.3 is complete.
- それが設立された状態になかったセッションをクリアするまで(または、クリアランスにマークされます)、終点は新しいセッションの設立を防がなければなりません、すなわち、セクション3.3がStep Iの後に完全になるまで。
3.2.3. Data Channel Reset
3.2.3. データ・チャンネルリセット
A data channel reset procedure is applicable only for the sessions using sequence numbers. For L2TPv3 data channel, the terms Nr and Ns in this document are used to mean "expected sequence number" and "sequence number", respectively.
データ・チャンネルリセット手順はセッションのためだけに一連番号を使用するのにおいて適切です。 L2TPv3データ・チャンネルにとって、用語のNrとNsは、それぞれ「予想された一連番号」と「一連番号」を意味するのに本書では使用されます。
Data channel reset procedure:
データはリセット手順を向けます:
- The recovery endpoint sets the Ns value to zero.
- 回復終点はNs値をゼロに設定します。
- The remote endpoint (recovery endpoint's peer) continues to use
the Ns values it was using previously.
- 遠く離れた終点(回復終点の同輩)は、それが以前に使用していたNs値を使用し続けています。
Jain, et al. Standards Track [Page 10] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[10ページ]。
- To reset Nr values during failover, if an endpoint receives 'n'
out of order but in sequence packets, then it MUST set the Nr
value based on the Ns value of the incoming packets, as
suggested in Appendix C of [L2TPv3]. The value of 'n' SHOULD be
configurable.
- '終点がフェイルオーバーの間のリセットNr値受信される、'、故障、連続してパケットだけ、次に、入って来るパケットのNs値に基づくNr値を設定しなければなりません、[L2TPv3]のAppendix Cに示されるように。 '値、'SHOULD、構成可能であってください。
- If one of the endpoints does not exhibit the capability
(indicated in 'D' bit in the Failover Capability AVP) to reset
the Nr value, then data channels using sequence numbers are
considered non recoverable. Those sessions SHOULD be torn down
by the recovery endpoint by sending a Call-Disconnect-Notify
(CDN).
- 終点の1つがNr値をリセットする能力(Failover Capability AVPで噛み付かれた'D'では、示される)を示さないなら、一連番号を使用しているデータ・チャンネルは非回復可能であると考えられます。 それらのセッションSHOULD、Call分離に通知している(CDN)を送る回復終点で、取りこわしてください。
- For data-channel-only failure, two endpoints MAY use the session
state query/response mechanism on the control channel to
synchronize the state of sessions as described in Section 3.3
below.
- データチャンネルだけの故障によって、2つの終点が以下のセクション3.3で説明されるようにセッションの状態を同期させるのに制御チャンネルの上にセッション州の質問/反応機構を使用するかもしれません。
3.3. Session State Synchronization
3.3. セッション州の同期
If a control channel failure happens when a session was being established or torn down, then it is possible for an endpoint to consider a session in an established state while its peer considers the same session non existent. Two such situations occur when failure on an endpoint occurs immediately after sending:
セッションを確立したか、または取りこわしていたとき、コントロールチャンネルの故障が起こるなら、同輩は、同じセッションが非目下であると考えますが、終点に、設立された状態でセッションを考えるのは可能です。 終点での失敗が発信直後起こると、そのような2つの状況が起こります:
- A CDN message that never made it to the peer.
- CDNメッセージは同輩に決して行きませんでした。
- An ICCN message that never made it to the peer.
- ICCNメッセージは同輩に決して行きませんでした。
The following mechanism MUST be used to identify and clear the sessions that exists on an endpoint, but not on its peer:
以下のメカニズムを、終点に存在するセッションを特定して、クリアするのに使用されますが、同輩の上で使用してはいけません:
Step I: For control channel failure, after the recovery tunnel is established, the sessions that were not in an established state MUST be silently cleared (i.e., without sending a CDN message) by each endpoint.
ステップI: コントロールチャンネルの故障において、回復トンネルが確立された後に各終点で設立された状態になかったセッションを静かにクリアしなければなりません(すなわち、CDNメッセージを送らないで)。
Step II: Both endpoints MAY identify the sessions that might have been in inconsistent states, perhaps based on data channel inactivity. FSQ and FSR messages have been introduced to synchronize session state at any given point during the life of a session between two endpoints. These messages are used when one endpoint determines or suspects in an implementation specific manner that its session state could be inconsistent with that of its peer's.
ステップII: 両方の終点は恐らくデータ・チャンネル不活発に基づいて矛盾した州にあったかもしれないセッションを特定するかもしれません。 2つの終点の間のセッションの人生の間の時点を考えて、FSQとFSRメッセージは、いずれでもセッション状態を同期させるように紹介されました。 1つの終点が、セッション状態が同輩のものに矛盾しているかもしれないと実現の特定の方法で決定するか、または疑うとき、これらのメッセージは使用されています。
Step III: An endpoint sends a Failover Session Query (FSQ) message to query the state of sessions as known to its peer. An FSQ message
ステップIII: 終点は同輩にとって知られているようにセッションの状態について質問するFailover Session Query(FSQ)メッセージを送ります。 FSQメッセージ
Jain, et al. Standards Track [Page 11] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[11ページ]。
contains one Failover Session State (FSS) AVP, defined in Section 5.4, for each session it wishes to query. Multiple FSS AVPs could be included in one FSQ message. An FSQ message MUST include at least one FSS AVP. An endpoint MAY send another FSQ message before getting a response for its previous FSQs.
それが質問したがっている各セッションのためにセクション5.4で定義された1Failover Sessionの州(FSS)AVPを含んでいます。 1つのFSQメッセージに複数のFSS AVPsを含むことができました。 FSQメッセージは少なくとも1FSS AVPを含まなければなりません。 終点は前のFSQsのために返事をもらう前に、別のFSQメッセージを送るかもしれません。
An inconsistency about a session's existence during failover could result in an endpoint selecting the same Session ID for a new session. In such a situation, it would send an ICRQ for an already established session. Therefore, before all sessions are synchronized using an FSQ/FSR mechanism, if endpoint receives an ICRQ for a session in an established state, then it MUST respond to such an ICRQ with a CDN. The CDN message must set Assigned/Local Session ID AVP ([L2TPv2] Section 4.4.4, [L2TPv3] Section 5.4.4) to its local Session ID and clear the session that it considered established. Use of a least recently used Session ID for the new sessions could help reduce this symptom during failover.
フェイルオーバーの間のセッションの存在に関する矛盾は新しいセッションのために同じSession IDを選択する終点をもたらすかもしれません。 そのような状況で、それは既に確立したセッションのためにICRQを送るでしょう。 したがって、終点がセッションのために設立された状態でICRQを受けるなら、すべてのセッションがFSQ/FSRメカニズムを使用することで同時にする前にそれはCDNと共にそのようなICRQに応じなければなりません。 CDNメッセージは、Assigned/地方のSession ID AVP([L2TPv2]セクション4.4.4、[L2TPv3]セクション5.4.4)を地方のSession IDに設定して、それが確立していると考えたセッションをクリアしなければなりません。 最も最近でない中古のSession IDの新しいセッションの使用は、フェイルオーバーの間、この兆候を減少させるのを助けるかもしれません。
When an endpoint receives an FSQ message, it MUST ensure that for each FSS AVP in the FSQ message, it includes an FSS AVP in the Failover Session Response (FSR) message. An endpoint could respond to multiple FSQs using one FSR message, or it could respond one FSQ with multiple FSRs. FSSs are not required to be responded in the same order in which they were received. For each FSS AVP received in FSQ messages, an endpoint MUST validate the Remote Session ID and determine if it is paired with the Session ID specified in the message. If an FSS AVP is not valid (i.e., session is non-existing or it is paired with different remote Session ID), then the Session ID field in the FSS AVP in the FSR MUST be set to zero. When session is discovered to be pairing with mismatching Session ID, the local session MUST not be cleared, but rather marked stale, to be queried later using an FSQ message. Appendix C presents an example dialogue between two endpoints with mismatching Session IDs.
終点がFSQメッセージを受け取るとき、それは、FSQメッセージの各FSS AVPに関して、Failover Session Response(FSR)メッセージにFSS AVPを含んでいるのを確実にしなければなりません。 終点が1つのFSRメッセージを使用する複数のFSQsに応じることができましたか、またはそれは複数のFSRsと1FSQを反応させるかもしれません。 FSSsは彼らが受け取られた同次で反応する必要はありません。 FSQメッセージに受け取られた各FSS AVPに関しては、終点は、Remote Session IDを有効にして、それがメッセージで指定されるSession IDと対にされるかどうか決定しなければなりません。 FSS AVPが有効でないなら(すなわち、セッションは非存在であるかそれは異なった遠く離れたSession IDと対にされます)、Session IDはFSR MUSTで中でFSS AVPをさばきます。ゼロに、用意ができています。 セッションがSession IDにミスマッチすることへの組み合わせであると発見されるとき、後でFSQメッセージを使用することで質問されるために聞き古したであるむしろマークされる以外に、地方のセッションをクリアしてはいけません。 付録CはSession IDにミスマッチするのに2つの終点の間の例の対話を提示します。
When responding to an FSQ with an FSR message, the Remote Session ID in the FSS AVP of the FSR message is always set to the received value of the Session ID in the FSS AVP of the FSQ message.
FSRメッセージでFSQに応じるとき、FSRメッセージのFSS AVPのRemote Session IDはいつもFSQメッセージのFSS AVPのSession IDの容認された値に設定されます。
When an endpoint receives an FSR message, for each FSS AVP it MUST use the Remote Session ID field to identify the local session and silently (without sending a CDN) clear the session if the Session ID in the AVP was zero. Otherwise, it MUST consider the session to be in an established state and recovered.
終点がFSRメッセージを受け取るとき、各FSS AVPに関して、それは、AVPのSession IDがゼロであったなら地方のセッションを特定して、静かにセッションをクリアすること(CDNを送らないで)にRemote Session ID分野を使用しなければなりません。 さもなければ、それは、セッションが設立された状態にあって、回復されると考えなければなりません。
4. New Control Messages
4. 新しいコントロールメッセージ
This document introduces two new messages that could be sent over an established/recovered control connection.
このドキュメントは確立したか回復しているコントロール接続の上に送ることができた2つの新しいメッセージを紹介します。
Jain, et al. Standards Track [Page 12] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[12ページ]。
4.1. Failover Session Query
4.1. フェイルオーバーセッション質問
The Failover Session Query (FSQ) control message is used by an endpoint during the recovery process to query the state of various sessions. It triggers a response from the peer, which contains the requested state of various sessions.
Failover Session Query(FSQ)コントロールメッセージは回復の過程の間、終点によって使用されて、様々なセッションの状態について質問します。 それは同輩から応答の引き金となります。(その同輩は、様々なセッションの要求された状態を含みます)。
This control message is encoded as follows:
このコントロールメッセージは以下の通りコード化されます:
Vendor ID = 0 (IETF)
Attribute Type = 21
0(IETF)業者ID=属性タイプ=21
The following AVPs MUST be present in the FSQ control message:
以下のAVPsはFSQコントロールメッセージに存在していなければなりません:
Message Type
Failover Session State
メッセージタイプフェイルオーバーセッション状態
The following AVPs MAY be present in the FSQ control message:
以下のAVPsはFSQコントロールメッセージに存在しているかもしれません:
Random Vector
Message digest ([L2TPv3] tunnels only)
無作為のVector Messageダイジェスト([L2TPv3]トンネル専用)
Other AVPs MUST NOT be sent in this control message and SHOULD be ignored on receipt.
他のAVPsはそうであるはずがありません。領収書の上でこのコントロールメッセージとSHOULDが無視されるのを送りました。
The M-bit on the Message Type AVP for this control message MUST be set to 0.
このコントロールメッセージのためのMessage Type AVPのM-ビットを0に設定しなければなりません。
4.2. Failover Session Response
4.2. フェイルオーバーセッション応答
The Failover Session Response (FSR) control message is used by an endpoint during the recovery process to respond with the local state of various sessions. It is sent as a response to an FSQ message. An endpoint MAY choose to respond to an FSQ message with multiple FSR messages.
Failover Session Response(FSR)コントロールメッセージは回復の過程の間、終点によって使用されて、様々なセッションの地方の状態と共に応じます。 FSQメッセージへの応答としてそれを送ります。 終点は、複数のFSRメッセージでFSQメッセージに応じるのを選ぶかもしれません。
This control message is encoded as follows:
このコントロールメッセージは以下の通りコード化されます:
Vendor ID = 0 (IETF)
Attribute Type = 22
0(IETF)業者ID=属性タイプ=22
The following AVPs MUST be present in the FSR control message:
以下のAVPsはFSRコントロールメッセージに存在していなければなりません:
Message Type
Failover Session State
メッセージタイプフェイルオーバーセッション状態
Jain, et al. Standards Track [Page 13] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[13ページ]。
The following AVPs MAY be present in the FSR control message:
以下のAVPsはFSRコントロールメッセージに存在しているかもしれません:
Random Vector
Message digest ([L2TPv3] tunnels only)
無作為のVector Messageダイジェスト([L2TPv3]トンネル専用)
Other AVPs MUST NOT be sent in this control message and SHOULD be ignored on receipt.
他のAVPsはそうであるはずがありません。領収書の上でこのコントロールメッセージとSHOULDが無視されるのを送りました。
The M-bit on the Message Type AVP for this control message MUST be set to 0.
このコントロールメッセージのためのMessage Type AVPのM-ビットを0に設定しなければなりません。
5. New Attribute Value Pairs
5. 新しい属性値ペア
The following sections contain a list of new L2TP AVPs defined in this document.
以下のセクションは本書では定義された新しいL2TP AVPsのリストを含みます。
5.1. Failover Capability AVP
5.1. フェイルオーバー能力AVP
The Failover Capability AVP, Attribute Type 76, indicates the capabilities of an endpoint required for the recovery process. The AVP format is defined as follows:
Failover Capability AVP(Attribute Type76)は、終点の能力が回復の過程に必要であることを示します。 AVP書式は以下の通り定義されます:
Failover Capability AVP
フェイルオーバー能力AVP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 76 | Reserved |D|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| rsvd| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ76| 予約されます。|D|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 回復Time(ミリセカンドによる)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is not mandatory (the M-bit MUST be set to 0).
AVP MAY、隠されてください(H-ビットは0か1にセットしました)。 AVPは義務的ではありません(M-ビットを0に設定しなければなりません)。
The C bit governs the failover capability for the control channel. When the C bit is set, it indicates that the endpoint can recover from a control channel failure using the procedure described in Section 3.2.2.
Cビットは制御チャンネルのためにフェイルオーバー能力を治めます。 Cビットが設定されるとき、それは、終点がコントロールチャンネルの故障からセクション3.2.2で説明された手順を用いることで回復できるのを示します。
When the C bit is not set, it indicates that the endpoint cannot recover from a control channel failover. In this case, the D bit MUST be set. Note that a control channel failover in this case would be fatal for the tunnel and all associated data channels.
Cビットが設定されないとき、それは、終点がコントロールチャンネルフェイルオーバーから回復できないのを示します。この場合、Dビットを設定しなければなりません。 トンネルとすべての関連データチャンネルに、この場合、コントロールチャンネルフェイルオーバーが致命的であることに注意してください。
Jain, et al. Standards Track [Page 14] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[14ページ]。
The D bit governs the failover capability for data channels that use sequence numbers. Data channels that do not use sequence numbers do not need help to recover from a data channel failure.
Dビットは一連番号を使用するデータ・チャンネルのためにフェイルオーバー能力を治めます。 一連番号を使用しないデータ・チャンネルは、データ・チャンネルの故障から回復するために助けを必要としません。
When the D bit is set, it indicates that the endpoint is capable of resetting Nr value of data channels using the procedure described in Section 3.2.3 Data Channel reset procedure.
Dビットが設定されるとき、それは、終点がセクション3.2.3Data Channelリセット手順で説明された手順を用いることでデータ・チャンネルのNr値をリセットできるのを示します。
When the D bit is not set, it indicates that the endpoint cannot recover data channels that use sequence numbers. In the case of a failure, such data channels would be lost.
Dビットが設定されないとき、それは、終点が一連番号を使用するデータ・チャンネルを回収できないのを示します。 失敗の場合では、そのようなデータ・チャンネルはなくされるでしょう。
The Failover Capability AVP MUST NOT be sent with C bit and D bit cleared.
CビットとDビットがきれいにされている状態で、Failover Capability AVPを送ってはいけません。
The Recovery Time, applicable only when the C bit is set, is the time in milliseconds an endpoint asks its peer to wait before assuming the recovery process has failed. This timer starts when an endpoint's control channel timeout ([L2TPv2] Section 5.8, [L2TPv3] Section 4.2) is started, and is not stopped (before expiry) until an endpoint successfully authenticates its peer during recovery. A value of zero does not mean that failover will not occur, it means no additional time is requested from the peer. The timer is also stopped if a control channel message is acknowledged by the peer in the situation when there was no failover, but the loss of the control channel message was a temporary phenomenon.
Cビットが設定される場合にだけ適切なRecovery Timeは終点が失敗したように回復が過程であると仮定する前に待つ同輩に頼むミリセカンドで表現される時間です。 終点のコントロールチャンネルタイムアウト([L2TPv2]セクション5.8、[L2TPv3]セクション4.2)が始められて、終点が回復の間、首尾よく同輩を認証するまで止められないとき(満期の前に)、このタイマは始動します。 ゼロの値は、フェイルオーバーが起こらないことを意味しないで、それは、どんな追加時間も同輩から要求されないことを意味します。 また、フェイルオーバーが全くなかったとき、コントロールチャンネルメッセージが状況における同輩によって承認されるなら、タイマは止められますが、コントロールチャンネルメッセージの損失は一時的現象でした。
This AVP MUST NOT be included in any control message other than SCCRQ and SCCRP messages.
このAVP MUST NOT、SCCRQ以外のどんなコントロールメッセージとSCCRPメッセージでも含められてください。
5.2. Tunnel Recovery AVP
5.2. トンネル回復AVP
The Tunnel Recovery AVP, Attribute Type 77, indicates that a sender would like to recover the tunnel identified in this AVP due to a failure. The AVP format is defined as follows:
Tunnel Recovery AVP(Attribute Type77)は、送付者が失敗のためこのAVPで特定されたトンネルを回収したがっているのを示します。 AVP書式は以下の通り定義されます:
Jain, et al. Standards Track [Page 15] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[15ページ]。
Tunnel Recovery AVP for L2TPv3 tunnels:
L2TPv3のためのトンネルRecovery AVPはトンネルを堀ります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 77 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recover Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recover Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| rsvd| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ77| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel IDを回復してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遠く離れたTunnel IDを回復してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tunnel Recovery AVP for L2TPv2 tunnels:
L2TPv2のためのトンネルRecovery AVPはトンネルを堀ります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 77 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Recover Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Recover Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| rsvd| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ77| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| Tunnel IDを回復してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 遠く離れたTunnel IDを回復してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MUST not be hidden (the H-bit is set to 0). The AVP is mandatory (the M-bit is set to 1).
このAVP MUST、隠されないでください(H-ビットは0に設定されます)。 AVPは義務的です(M-ビットは1に設定されます)。
The Recover Tunnel ID encodes the local Tunnel ID that an endpoint wants recovered. The Recover Remote Tunnel ID encodes the remote Tunnel ID corresponding to the old tunnel.
Recover Tunnel IDは終点が回復する必要がある地方のTunnel IDをコード化します。 Recover Remote Tunnel IDは古いトンネルに対応する遠く離れたTunnel IDをコード化します。
This AVP MUST NOT be included in any control message other than the SCCRQ message when establishing a Recovery Tunnel.
このAVP MUST NOT、Recovery Tunnelを設立するときにはSCCRQメッセージ以外のあらゆるコントロールメッセージで含められてください。
5.3. Suggested Control Sequence AVP
5.3. 提案された制御配列AVP
The Suggested Control Sequence (SCS) AVP, Attribute Type 78, specifies the Ns and Nr values to for the recovered tunnel. This AVP is included in an SCCRP message of a recovery tunnel by remote endpoint. The AVP format is defined as follows:
Suggested Control Sequence(SCS)AVP(Attribute Type78)はNsとNr値を回復しているトンネルに指定します。 このAVPは回復トンネルに関するSCCRPメッセージに遠く離れた終点によって含まれています。 AVP書式は以下の通り定義されます:
Jain, et al. Standards Track [Page 16] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[16ページ]。
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| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 78 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Ns | Suggested Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| rsvd| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ78| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 提案されたナノ秒| 提案されたNr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is not mandatory (the M-bit is set to 0).
このAVP MAY、隠されてください(H-ビットは0か1にセットしました)。 AVPは義務的ではありません(M-ビットは0に設定されます)。
This is an optional AVP, suggesting Ns and Nr values to be used by the recovery endpoint. If this AVP is present in an SCCRP message during recovery tunnel establishment, the recovery endpoint MUST set the Ns and Nr values of the recovered tunnel to the respective suggested values. When this AVP is not sent in an SCCRP or not present in an incoming SCCRP, the Ns and Nr values for the recovered tunnel are set to zero. Use of this AVP helps avoid the interference in the recovered tunnel's control channel with old control packets.
回復終点によって使用されるためにNsとNr値を示して、これは任意のAVPです。 このAVPが回復トンネル設立の間、SCCRPメッセージに存在しているなら、回復終点は回復しているトンネルのNsとNr値をそれぞれの提案された値に設定しなければなりません。 このAVPがいつでないかがプレゼントではなく、入って来るSCCRPのSCCRP、Ns、および合わせてください回復しているトンネルへの値が設定されるゼロNrを送りました。 このAVPの使用は、古いコントロールパケットで回復しているトンネルの制御チャンネルへの干渉を避けるのを助けます。
This AVP MUST NOT be included in any control message other than the SCCRP message when establishing a Recovery Tunnel.
このAVP MUST NOT、Recovery Tunnelを設立するときにはSCCRPメッセージ以外のあらゆるコントロールメッセージで含められてください。
5.4. Failover Session State AVP
5.4. フェイルオーバーセッション州のAVP
The Failover Session State (FSS) AVP, Attribute Type 79, is used to query the state of a session from the peer end to clear the sessions that otherwise would remain in an undefined state after failover. The AVP format is defined as follows:
Failover Session州(FSS)AVP(Attribute Type79)はそうでなければフェイルオーバーAVP書式が以下の通り定義された後に未定義の州に残っているセッションをクリアするために同輩終わりからのセッションの状態について質問するのに使用されます:
FSS AVP format for L2TPv3 sessions:
FSS AVPはL2TPv3のためにセッションをフォーマットします:
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| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 79 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| rsvd| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ79| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッションID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遠く離れたSession ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jain, et al. Standards Track [Page 17] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[17ページ]。
FSS AVP format for L2TPv2 sessions:
FSS AVPはL2TPv2のためにセッションをフォーマットします:
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| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 79 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| rsvd| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ79| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| セッションID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 遠く離れたSession ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is mandatory (the M-bit is set to 1).
このAVP MAY、隠されてください(H-ビットは0か1にセットしました)。 AVPは義務的です(M-ビットは1に設定されます)。
The Session ID identifies the local Session ID that the sender had assigned, for which it would like to query the state on its peer. A Remote Session Id is the remote Session ID for the same session.
Session IDはそれがどれに関して状態について質問したがっているように送付者が同輩に選任した地方のSession IDを特定します。 Remote Session Idは同じセッションのための遠く離れたSession IDです。
An FSS AVP MUST NOT be used in any message other than FSQ and FSR messages.
FSS AVP MUST NOT、FSQ以外のどんなメッセージとFSRメッセージでも使用されてください。
6. Configuration Parameters
6. 設定パラメータ
An L2TP endpoint MAY expose the following configuration parameters to be specified for control connections:
L2TP終点はコントロール接続に指定されるために以下の設定パラメータを露出するかもしれません:
- Control Channel Failover Capability: Failover Capability AVP
(Section 5.1), C bit.
- チャンネルフェイルオーバー能力を制御してください: フェイルオーバーCapability AVP(セクション5.1)、Cに噛み付きました。
- Data Channel Failover Capability: Failover Capability AVP
(Section 5.1), D bit.
- データはフェイルオーバー能力を向けます: フェイルオーバーCapability AVP(セクション5.1)、Dに噛み付きました。
- Recovery Time: Failover Capability AVP (Section 5.1).
- 回復時間: フェイルオーバー能力AVP(セクション5.1)。
The L2TP MIB defined in [L2TPv2-MIB] and [L2TPv3-MIB], defines a number of objects that may be used for monitoring the status L2TP nodes, but is seldom used for configuration purposes. It is expected that the above mentioned parameters will be configured by using a Command Line Interface (CLI) or other proprietary mechanism.
L2TP MIBは中で[L2TPv2-MIB]と[L2TPv3-MIB]を定義しますが、状態L2TPノードをモニターするのに使用されるかもしれない多くの物を定義しますが、構成目的にめったに使用されません。 上記のパラメタがCommand線Interface(CLI)か他の独占メカニズムを使用することによって構成されると予想されます。
Asynchronous notifications for failover and recovery events may be sent by L2TP nodes to network management applications, but the specification of the protocol and format to be used for these notifications is out of the scope of this document.
L2TPノードでフェイルオーバーのための非同期な通知と回復出来事をネットワークマネージメントアプリケーションに送るかもしれませんが、このドキュメントの範囲の外にこれらの通知に使用されるべきプロトコルと形式の仕様があります。
Jain, et al. Standards Track [Page 18] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[18ページ]。
7. IANA Considerations
7. IANA問題
This document defines the following values assigned by IANA.
このドキュメントはIANAによって割り当てられた以下の値を定義します。
- Four Control Message Attribute Value Pairs (Section 10.1 [L2TPv3]):
- 4はメッセージ属性値ペア(セクション10.1[L2TPv3])を制御します:
Failover Capability : 76
Tunnel Recovery : 77
Suggested Control Sequence : 78
Failover Session State : 79
フェイルオーバー能力: 76 回復にトンネルを堀ってください: 77は制御配列を示しました: 78 フェイルオーバーセッション州: 79
- Two Message Type (Attribute Type 0) Values (Section 10.2 [L2TPv3]):
- 2メッセージタイプ(属性タイプ0)は(セクション10.2[L2TPv3])を評価します:
Failover Session Query : 21
Failover Session Response : 22
フェイルオーバーセッション質問: 21 フェイルオーバーセッション応答: 22
8. Security Considerations
8. セキュリティ問題
A spoofed failover request (SCCRQ with Tunnel Recovery AVP) on behalf of an endpoint might cause a control channel termination if authentication measures mentioned in Section 3.2.1 are not used.
認証測定が、セクション3.2で.1が使用されていないと言及するなら、終点を代表しただまされたフェイルオーバー要求(Tunnel Recovery AVPとSCCRQ)はコントロールチャンネル終了を引き起こすでしょうに。
Even if the authentication measures (as described in Section 3.2.1) were used, it is still possible to learn an identity of an operational tunnel from an endpoint by issuing it spoofed failover requests that fail the authentication procedure. The probability of succeeding with a spoofed failover request is 1 in (2^16 - 1) for [L2TPv2] and 1 in (2^32 - 1) for [L2TPv3]. The discovered identity of an operational tunnel could then be misused to send control messages for a possible hindrance to the control connection. Typically, control messages that are outside the endpoint's receive window are discarded. However, if Suggested Control Sequence AVP (Section 5.3) is not used during the actual failover process, the sequence numbers might be reset to zero, thereby making the receive window predictable. To improve security under such circumstances, an endpoint may be configured with the possible set of recovery endpoints that could recover a tunnel, and use of Suggested Control Sequence AVP when recovering a tunnel.
認証測定(セクション3.2.1で説明されるように)が使用されたとしても、終点から認証手順に失敗するだまされたフェイルオーバー要求をそれに出すことによって操作上のトンネルのアイデンティティを学ぶのはまだ可能です。 だまされたフェイルオーバー要求で成功するという確率は、[L2TPv2]のための(2^16--1)における1と(2^32--1)で[L2TPv3]のための1です。 そして、可能な妨害へのコントロールメッセージをコントロール接続に送るために操作上のトンネルの発見されたアイデンティティを誤用できました。 外では、終点のものが窓を受けるということであるコントロールメッセージが通常、捨てられます。 しかしながら、Suggested Control Sequence AVP(セクション5.3)が実際のフェイルオーバーの過程の間、使用されないなら、一連番号がその結果、ゼロ、作成にリセットされるかもしれない、予測できる窓を受けてください。 セキュリティをこれでは向上させるために、終点はトンネルを回収できた可能なセットの回復終点、およびトンネルを回収するときのSuggested Control Sequence AVPの使用によって構成されるかもしれません。
9. Acknowledgements
9. 承認
Leo Huber provided suggestions to help define the failover concept. Mark Townsley, Carlos Pignataro, and Ignacio Goyret reviewed the document and provided valuable suggestions.
ヒューバーがフェイルオーバー概念を定義するのを助けるために提案を提供したレオ。 マークTownsley、カルロスPignataro、およびイグナシオGoyretはドキュメントを再検討して、貴重な提案を提供しました。
Jain, et al. Standards Track [Page 19] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[19ページ]。
10. Contributors
10. 貢献者
Paul Howard Juniper Networks Vipin Jain Riverstone Networks Sam Henderson Cisco Systems Keyur Parikh Harris Corporations
ポール・ハワード杜松ネットワークのVipinのジャイナ教のリバーストンはサムヘンダーソンシスコシステムズKeyurパリークハリス社をネットワークでつなぎます。
11. References
11. 参照
11.1. Normative References
11.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月。
[L2TPv2] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
Zorn, G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[L2TPv2]Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
March 2005.
[L2TPv3] ラウ、J.、Townsley、M.、およびI.Goyret、「2トンネリングプロトコルを層にしてください--バージョン3(L2TPv3)」、RFC3931、3月2005日
11.2. Informative References
11.2. 有益な参照
[L2TPv2-MIB] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two
Tunneling Protocol "L2TP" Management Information
Base", RFC 3371, August 2002.
[L2TPv2-MIB] 洞窟、E.、カルフーン、P.、およびR.ウィーラー、「層Twoのトンネリングプロトコル"L2TP"管理情報ベース」、RFC3371、2002年8月。
[L2TPv3-MIB] Nadeau, T. and K. Koushik, "Layer Two Tunneling
Protocol (version 3) Management Information Base",
Work in Progress, August 2006.
[L2TPv3-MIB] 「層Twoのトンネリングプロトコル(バージョン3)管理情報ベース」というナドー、T.、およびK.Koushikは進歩、2006年8月に働いています。
[BFD-MULTIHOP] Katz, D. and D. Ward, "BFD for Multihop Paths", Work
in Progress, March 2007.
「マルチホップ経路へのBFD」という[BFD-マルチホップ]のキャッツ、D.、およびD.区は進歩、2007年3月に働いています。
Jain, et al. Standards Track [Page 20] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[20ページ]。
Appendix A
付録A
Description below outlines the failover protocol operation for an example tunnel. The failover protocol does not preclude an endpoint from recovering multiple tunnels in parallel. It also allows an endpoint to send multiple FSQs, each including multiple FSS AVPs, to recover quickly.
以下の記述は例のトンネルのためのフェイルオーバープロトコル操作について概説します。 フェイルオーバープロトコルは、平行な複数のトンネルを回収するので、終点を排除しません。 また、それで、終点はすぐに回復するためにそれぞれ複数のFSS AVPsを含む複数のFSQsを送ることができます。
Failover Capability Negotiation (Section 3.1):
フェイルオーバー能力交渉(セクション3.1):
Endpoint Peer
(assigned tid = x, failover capable)
SCCRQ --------------------------------------> validate SCCRQ
終点Peer(tid=x、できるフェイルオーバーを割り当てる)SCCRQ-------------------------------------->はSCCRQを有効にします。
(assigned tid = y, failover capable)
validate <-------------------------------------- send SCCRP
SCCRP, etc.
(tid=y、できるフェイルオーバーを割り当てます) <を有効にしてください。-------------------------------------- SCCRP SCCRPなどを送ってください。
.... <after tunnel gets created, sessions are established> ....
.... トンネルの後の<は作成されて、セッションは確立した>です…
< This Node fails >
<はこのNodeやり損ない>です。
The Recovery endpoint establishes the recovery tunnel (Section 3.2.1). Initiate recovery tunnel establishment for the old tunnel 'x':
Recovery終点は回復トンネル(セクション3.2.1)を確立します。 古いトンネル'x'のための回復トンネル設立を開始してください:
Recovery Endpoint Peer
回復終点同輩
(assigned tid = z, Recovery AVP)
SCCRQ -----------------------------------> Detects failover
(recover tid = x, recover remote tid = y) validate SCCRQ
(z、tid=Recovery AVPを割り当てます) SCCRQ----------------------------------->が検出する、フェイルオーバー(tidに=xを回復してください、そして、リモートtid=yを回復する)はSCCRQを有効にします。
(Suggested Control Sequence AVP, Suggested Ns/Nr = 3/100)
validate <----------------------------------- send SCCRP
SCCRP (recover tid = y, recover remote tid = x)
reset Ns = 3, Nr = 100
on the recovered tunnel
(Control Sequence AVP、Suggested Ns/Nr=3/100を示します) <を有効にしてください。----------------------------------- SCCRP SCCRP(tid=yを回復してください、そして、リモートtid=xを回復する)にリセットNs=3を送ってください、回復しているトンネルの上のNr=100
SCCCN -----------------------------------> validate and reset
Ns = 100, Nr = 3 on
the recovered tunnel
SCCCN----------------------------------->は回復しているトンネルの上に100、Ns=Nr=3を有効にして、リセットします。
Jain, et al. Standards Track [Page 21] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[21ページ]。
Terminate the recovery tunnel
回復トンネルを終えてください。
tid = 'z' StopCCN --------------------------------------> Cleanup 'w'
tidは'z'StopCCNと等しいです。-------------------------------------->クリーンアップ'w'
Session states are synchronized both endpoints may send FSQs and cleanup stale sessions (Section 3.3)
セッション州は連動して、両方の終点が聞き古したセッションをFSQsとクリーンアップに送るかもしれないということです。(セクション3.3)
(FSS AVP for sessions s1, s2, s3..)
send FSQ -------------------------------------> compute the state
of sessions in FSQ
(セッションs1、s2、s3のためのFSS AVP)はFSQを送ります。------------------------------------->はFSQでセッションの状態を計算します。
(FSS AVP for sessions s1, s2, s3...)
deletes <-------------------------------------- send FSR
stale sessions, if any
(セッションs1、s2、s3のための…FSS AVP)は<を削除します。-------------------------------------- もしあれば聞き古したセッションをFSRに送ってください。
(FSS AVP for sessions s7, s8, s9...)
compute <-------------------------------------- send FSQ
the sate of
sessions in FSQ
(セッションs7、s8、s9のための…FSS AVP)は<を計算します。-------------------------------------- FSQを送ってください、十分満足させるFSQのセッションを。
(FSS AVP for sessions s7, s8, s9...)
send FSR --------------------------------------> delete stale
sessions, if any
(セッションs7、s8、s9のための…FSS AVP)はFSRを送ります。-------------------------------------->はもしあれば聞き古したセッションを削除します。
Jain, et al. Standards Track [Page 22] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[22ページ]。
Appendix B
付録B
This section shows an example dialogue to illustrate double failure recovery. The notable difference, as described in Section 3.2.1, in the procedure from single failover scenario is the use of a tie breaker by one of the recovery endpoints to use the recovery tunnel established by its peer (also a recovery endpoint) as a recovery tunnel.
このセクションは、二重失敗回復を例証するために例の対話を示しています。 注目に値する違い、ただ一つのフェイルオーバーからのセクション3.2.1で説明される手順では、シナリオは回復トンネルと同輩(回復終点も)によって書き立てられた回復トンネルを使用する回復終点の1つのそばのタイブレークの使用です。
Recovery endpoint Recovery endpoint
回復終点Recovery終点
(assume old tid = A) (assume old tid = B)
(古いtidが=a)であると仮定してください。(古いtidが=Bであると仮定します)
Recovery AVP = (A, B)
SCCRQ -----------------------+
(with tie (recovery tunnel 'C') |
breaker |
AVP) |
Recovery AVP = (B, A) |
+- valid <--------------------------- Send SCCRQ
| SCCRQ (recovery tunnel 'D') | (with tie breaker AVP)
| This endpoint |
| loses tie; |
| Discards tunnel 'C' +--> Valid SCCRQ
| This endpoint wins tie;
| Discards SCCRQ
|
| (may include SCS AVP)
+->Send SCCRP -------------------------> Validate SCCRP
Reset 'B';
Set Ns, Nr values --+
|
|
|
Validate SCCN <---------------------- Send SCCN -------+
Reset 'A';
Set Ns, Nr values
回復AVPはSCCRQと等しいです(A、B)。-----------------------+(繋がり(回復トンネル'C')| ブレーカー| AVPと)| 回復AVPが等しい、(B、a)| + 有効な<。--------------------------- SCCRQを送ってください。| SCCRQ(回復トンネル'D')| (タイブレークAVPと) | この終点| | 繋がりを失います。 | | 破棄は'C'+にトンネルを堀ります--、>Valid SCCRQ| この終点は繋がりを得ます。 | SCCRQを捨てます。| | (SCS AVPを含むかもしれません) +->が発信しているSCCRP------------------------->はSCCRPリセット'B'を有効にします。 セットNs、Nr値--+| | | SCCN<を有効にしてください。---------------------- SCCNを送ってください。-------+ リセット'A'。 Ns、Nr値を設定してください。
FSQs and FSRs for the old tunnel (A, B) are exchanged on the recovered tunnel by both endpoints.
両方の終点は回復しているトンネルで古いトンネル(A、B)へのFSQsとFSRsを交換します。
Jain, et al. Standards Track [Page 23] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[23ページ]。
Appendix C
付録C
Session ID mismatch could not be a result of failure on one of the endpoints. However, failover session recovery procedure could exacerbate the situation, resulting into a permanent mismatch in Session IDs between two endpoints. The dialogue below outlines the behavior described in Section 3.3, Step III to handle such situations gracefully.
セッションIDミスマッチは終点の1つでの失敗の結果であることができませんでした。 しかしながら、フェイルオーバーセッションリカバリ手順は状況、2つの終点の間のSession IDにおける永久的なミスマッチへの結果になることを悪化させるかもしれません。 振舞いが優雅にそのような状況を扱うためにセクション3.3、Step IIIで説明したアウトラインの下における対話。
Recovery endpoint Remote endpoint
回復終点Remote終点
(assume a mismatch) (assume a mismatch) Sid = A, Remote Sid = B Sid = B, Remote Sid = C Sid = C, Remote Sid = D
(ミスマッチを仮定します) (ミスマッチを仮定します)シド=A、RemoteシドはBシド=Bと等しいです、C Remoteシド=シド=C、Remoteシド=D
FSS AVP (A, B)
send FSQ -------------------------> No (B, A) pair exist;
rather (B, C) exist.
If it clears B then peer doesn't
know if C is stale on other end.
FSS AVP(A、B)はFSQを送ります。------------------------->ノー(B、A)組は存在しています。 むしろ、(B、C)は存在しています。 Bをクリアするなら、同輩は、Cが他の終わりで聞き古したであるかどうか知りません。
Instead if it marks B stale
and queries the session state
via FSQ, C would be cleared on
the other end.
代わりに、Bが聞き古したであるマークして、FSQを通してセッション状態について質問するなら、Cはもう一方の端でクリアされるでしょう。
FSS AVP (0, A)
Clears A <-------------------------- send FSR
FSS AVP、(0、a)は<をきれいにします。-------------------------- FSRを送ってください。
... some time later ...
… その後…
FSS AVP (B, C)
No (C,B) <-------------------------- send FSQ
Mark C Stale
FSS AVP(B、C)ノー(C、B)<。-------------------------- FSQマークC Staleを送ってください。
FSS AVP (0, B)
Send FSR --------------------------> Clears B
FSS AVP(0、B)はFSRを送ります。-------------------------->はBをクリアします。
Jain, et al. Standards Track [Page 24] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[24ページ]。
Author Information
作者情報
Vipin Jain Riverstone Networks 5200 Great America Parkway Santa Clara, CA 95054 EMail: vipinietf@yahoo.com
Vipinのジャイナ教のリバーストンはサンタクララ、カリフォルニア 95054がメールする5200グレート・アメリカ公園道路をネットワークでつなぎます: vipinietf@yahoo.com
Paul W. Howard Juniper Networks 10 Technology Park Drive Westford, MA 01886 EMail: phoward@juniper.net
Driveウェストフォード、技術Park MA 01886がメールするポールW.ハワード杜松ネットワーク10: phoward@juniper.net
Sam Henderson Cisco Systems 7025 Kit Creek Rd. PO Box 14987 Research Triangle Park, NC 27709 EMail: samh@cisco.com
サムヘンダーソンシスコシステムズ7025キットCreek通り 私書箱14987リサーチトライアングル公園、NC27709メール: samh@cisco.com
Keyur Parikh Harris Corporation 4393 Digitalway Mason, OH 45040 EMail: kparikh@harris.com
Keyurパリークハリス社4393のDigitalwayメイスン、OH 45040はメールされます: kparikh@harris.com
Jain, et al. Standards Track [Page 25] RFC 4951 FAILOVER August 2007
ジャイナ教徒、他 規格はフェイルオーバー2007年8月にRFC4951を追跡します[25ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Jain, et al. Standards Track [Page 26]
ジャイナ教徒、他 標準化過程[26ページ]
一覧
スポンサーリンク
