[要約] RFC 4811は、OSPFのOut-of-Band Link State Database（LSDB）の再同期に関する仕様です。このRFCの目的は、ネットワークの障害が発生した場合に、LSDBの再同期を効率的に行うための手法を提供することです。
Network Working Group L. Nguyen
Request for Comments: 4811 A. Roy
Category: Informational Cisco Systems
A. Zinin
Alcatel-Lucent
March 2007
OSPF Out-of-Band Link State Database (LSDB) Resynchronization
OSPF Out-Band Link State Database（LSDB）再同期
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.
OSPFは、IPネットワークで使用されるリンク状態内領域内ルーティングプロトコルです。OSPFのリンク状態データベース（LSDB）同期は、2つの方法で達成されます。最初のLSDB同期は、OSPFルーターがネットワークに接続されたばかりの場合と、初期手順が完了した後にトポロジの存在下で連続LSDB同期を保証する非同期洪水を保証します。。OSPFルーターがLSDBを再同期する必要がある場合があります。ただし、OSPF標準では、ネットワークのトポロジビューを実際に変更することなく、ルーターがそれを行うことはできません。
This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard.
このメモは、このような帯域外LSDB同期の形式を実行するベンダー固有のメカニズムについて説明しています。このドキュメントで説明されているメカニズムは、RFC 3623に記載されているように、Graceful OSPF再起動の前に提案されました。少なくとも1つの主要なベンダーによって実装/サポートされており、現在フィールドに展開されています。このドキュメントの目的は、公共の使用のためのこのメカニズムの詳細をキャプチャすることです。このメカニズムはIETF標準ではありません。
Table of Contents
目次
1. Introduction ....................................................2
2. Proposed Solution ...............................................2
2.1. The LR-Bit .................................................3
2.2. OSPF Neighbor Data Structure ...............................3
2.3. Hello Packets ..............................................4
2.4. DBD Packets ................................................4
2.5. Neighbor State Treatment ...................................7
2.6. Initiating OOB LSDB Resynchronization ......................7
3. Backward Compatibility ..........................................7
4. Security Considerations .........................................7
5. IANA Considerations .............................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
Appendix A. Acknowledgements ......................................9
According to the OSPF standard [RFC2328], after two OSPF routers have established an adjacency (the neighbor Finite State Machines (FSMs) have reached Full state), routers announce the adjacency states in their router-Link State Advertisements (LSAs). Asynchronous flooding algorithm ensures that routers' LSDBs stay in sync in the presence of topology changes. However, if routers need (for some reason) to resynchronize their LSDBs, they cannot do that without actually putting the neighbor FSMs into the ExStart state. This effectively causes the adjacencies to be removed from the router-LSAs, which may not be acceptable if the desire is to prevent routing table flaps during database resynchronization. In this document, we provide the means for so-called out-of-band (OOB) LSDB resynchronization.
OSPF標準[RFC2328]によれば、2つのOSPFルーターが隣接能力を確立した後（近隣の有限状態マシン（FSM）が完全な状態に達した）、ルーターはルーターリンク状態広告（LSA）の隣接状態を発表します。非同期洪水アルゴリズムにより、トポロジの変化が存在する場合、ルーターのLSDBが同期し続けることが保証されます。ただし、ルーターが（何らかの理由で）LSDBを再同期するために（何らかの理由で）必要な場合、隣人FSMを実際にExstart状態に入れなければそれを行うことはできません。これにより、データベースの再同期中にルーティングテーブルフラップを防ぐことを望んでいる場合、隣接がルーターLSAから削除される可能性があります。このドキュメントでは、いわゆる帯域外（OOB）LSDB再同期の手段を提供します。
The described mechanism can be used in a number of situations including those where the routers are picking up the adjacencies after a reload. The process of adjacency preemption is outside the scope of this document. Only the details related to LSDB resynchronization are mentioned herein.
説明されたメカニズムは、ルーターがリロード後に隣接を拾っている状況を含む多くの状況で使用できます。隣接する先制のプロセスは、このドキュメントの範囲外です。LSDBの再同期に関連する詳細のみがここに記載されています。
With this Out-of-Band Resynchronization Solution, the format of the OSPF Database Description (DBD) packet is changed to include a new R-bit indicating OOB LSDB resynchronization. All DBD packets sent during the OOB resynchronization procedure are sent with the R-bit set.
この帯域外の再同期ソリューションを使用すると、OSPFデータベース説明（DBD）パケットの形式が変更され、OOB LSDB再同期を示す新しいRビットが含まれます。OOB再同期手順中に送信されるすべてのDBDパケットは、Rビットセットで送信されます。
Also, two new fields are added to the neighbor data structure. The first field indicates a neighbor's OOB resynchronization capability. The second indicates that OOB LSDB resynchronization is in process. The latter field allows OSPF implementations to utilize the existing neighbor FSM code.
また、2つの新しいフィールドが隣接データ構造に追加されます。最初のフィールドは、隣人のOOB再同期機能を示します。2番目は、OOB LSDB再同期が進行中であることを示しています。後者のフィールドでは、OSPFの実装が既存の近隣FSMコードを利用できるようにします。
A bit is occupied in the Extended Options (EO) TLV (see [RFC4813]). Routers set this bit to indicate their capability to support the described technique.
拡張オプション（EO）TLV（[RFC4813]を参照）で少し占められています。ルーターは、このビットを設定して、説明されている手法をサポートする能力を示しています。
A new bit, called LR (LR stands for LSDB Resynchronization), is introduced to the LLS Extended Options TLV (see [RFC4813]). The value of the bit is 0x00000001; see Figure 1. See the "IANA Considerations" section of [RFC4813] for more information on the Extended Options bit definitions. Routers set the LR-bit to announce OOB LSDB resynchronization capability.
LR（LRはLSDB再同期の略）と呼ばれる新しいビットが、LLS拡張オプションTLVに導入されます（[RFC4813]を参照）。ビットの値は0x00000001です。図1を参照してください。拡張オプションビット定義の詳細については、[RFC4813]の[RFC4813]の「IANA考慮事項」セクションを参照してください。ルーターはLRビットを設定して、OOB LSDB再同期機能を発表します。
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
| * | * | * | * | * | * | * |...| * | * | * | * | * | * | * | LR|
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
Figure 1. The Options Field
図1.オプションフィールド
Routers supporting the OOB LSDB resynchronization technique set the LR-bit in the EO-TLV in the LLS block attached to both Hello and DBD packets. Note that no bit is set in the standard OSPF Options field, neither in OSPF packets nor in LSAs.
OOB LSDB再同期技術をサポートするルーターは、HelloとDBDパケットの両方に接続されたLLSブロックのEO-TLVにLRビットを設定します。OSPFパケットでもLSAでも、標準のOSPFオプションフィールドには少し設定されていないことに注意してください。
A field is introduced into OSPF neighbor data structure, as described below. The name of the field is OOBResync, and it is a flag indicating that the router is currently performing OOB LSDB resynchronization with the neighbor.
以下で説明するように、フィールドはOSPF隣接データ構造に導入されます。フィールドの名前はOOBRESYNCであり、ルーターが現在隣接とOOB LSDBの再同期を実行していることを示すフラグです。
The OOBResync flag is set when the router is initiating OOB LSDB resynchronization (see Section 2.6 for more details).
OOBRESYNCフラグは、ルーターがOOB LSDB再同期を開始しているときに設定されます（詳細についてはセクション2.6を参照）。
Routers clear the OOBResync flag on the following conditions:
ルーターは、次の条件でoobresyncフラグをクリアします。
o The neighbor data structure is first created.
o 隣接データ構造が最初に作成されます。
o The neighbor FSM transitions to any state lower than ExStart.
o 隣人FSMは、Exstartよりも低い状態に移行します。
o The neighbor FSM transitions to the ExStart state because a DBD packet with the R-bit clear has been received.
o 近隣FSMは、Rビットクリアを備えたDBDパケットが受信されたため、Exstart状態に移行します。
o The neighbor FSM reaches the state Full.
o 隣人FSMは状態に到達します。
Note that the OOBResync flag may have a TRUE value only if the neighbor FSM is in states ExStart, Exchange, or Loading. As indicated above, if the FSM transitions to any other state, the OOBResync flag should be cleared.
OoBresyncフラグは、近隣FSMが州にある場合にのみ、真の値を持つ可能性があることに注意してください。上記のように、FSMが他の状態に移行する場合、OOBRESYNCフラグをクリアする必要があります。
It is important to mention that operation of the OSPF neighbor FSM is not changed by this document. However, depending on the state of the OOBResync flag, the router sends either normal DBD packets or DBD packets with the R-bit set.
OSPF隣人FSMの操作はこのドキュメントによって変更されないことに言及することが重要です。ただし、OOBRESYNCフラグの状態に応じて、ルーターは通常のDBDパケットまたはDBDパケットをRビットセットで送信します。
Routers capable of performing OOB LSDB resynchronization should always set the LR-bit in their Hello packets.
OOB LSDB再同期を実行できるルーターは、常にLRビットをハローパケットに設定する必要があります。
Routers supporting the described technique should always set the LR-bit in the DBD packets. Since the Options field of the initial DBD packet is stored in corresponding neighbor data structure, the LR-bit may be used later to check if a neighbor is capable of performing OOB LSDB resynchronization.
説明された手法をサポートするルーターは、常にDBDパケットにLRビットを設定する必要があります。最初のDBDパケットのオプションフィールドは、対応する隣接データ構造に保存されるため、LRビットは後で使用され、隣接がOOB LSDB再同期を実行できるかどうかを確認できます。
The format of type 2 (DBD) OSPF packets is changed to include a flag indicating the OOB LSDB resynchronization procedure. Figure 2 illustrates the new packet format.
タイプ2（DBD）OSPFパケットの形式は、OOB LSDB再同期手順を示すフラグを含むように変更されます。図2は、新しいパケット形式を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Options |0|0|0|0|R|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Figure 2. Modified DBD Packet
図2.変更されたDBDパケット
The R-bit in OSPF type 2 packets is set when the OOBResync flag for the specific neighbor is set to TRUE. If a DBD packets with the R-bit clear is received for a neighbor with active OOBResync flag, the OOB LSDB resynchronization process is canceled and normal LSDB synchronization procedure is initiated.
OSPFタイプ2パケットのRビットは、特定の隣接のOOBRESYNCフラグがtrueに設定されているときに設定されます。アクティブなOBRESYNCフラグを備えた隣人に対してRビットクリアを備えたDBDパケットが受信された場合、OOB LSDB再同期プロセスがキャンセルされ、通常のLSDB同期手順が開始されます。
When a DBD packet is received with the R-bit set and the sender is known to be OOB-incapable, the packet should be dropped and a SeqNumber-Mismatch event should be generated for the neighbor.
RビットセットでDBDパケットが受信され、送信者がOOBインコーペップであることがわかっている場合、パケットをドロップし、隣人に対してSEQNUMBER-MISMATCHイベントを生成する必要があります。
Processing of DBD packets is modified as follows:
DBDパケットの処理は、次のように変更されます。
1. If the OOBResync flag for the neighbor is set (the LSDB resynchronization process has been started) and the received DBD packet does not have the R-bit set, ignore the packet and generate a SeqNumberMismatch event for the neighbor FSM.
1. ネイバーのOOBRESYNCフラグが設定されている場合（LSDB再同期プロセスが開始されました）、受信したDBDパケットにはRビットセットがなく、パケットを無視し、隣人FSMのSEQNumberMismatchイベントを生成します。
2. Otherwise, if the OOBResync flag for the neighbor is clear and the received DBD packet has the R-bit set, perform the following steps:
2. それ以外の場合、隣人のoobresyncフラグが明確で、受信したDBDパケットにRビットセットがある場合、次の手順を実行します。
* If the neighbor FSM is in state Full and bits I, M, and MS are set in the DBD packet, set the OOBResync flag for the neighbor, put the FSM in ExStart state, and continue processing the DBD packet as described in [RFC2328].
* 隣接FSMが状態の状態であり、ビットI、M、およびMSがDBDパケットに設定されている場合、近隣のOOBRESYNCフラグを設定し、FSMをExstART状態に置き、[RFC2328]に記載されているDBDパケットの処理を続けます。
* Otherwise, ignore received DBD packet (no OOB DBD packets are allowed with OOBResync flag clear and FSM in state other than Full). Also, if the state of the FSM is Exchange or higher, generate a SeqNumberMismatch event for the neighbor FSM.
* それ以外の場合は、受信したDBDパケットを無視します（OOB DBDパケットは、Full以外の状態でoobresync Flag ClearとFSMで許可されていません）。また、FSMの状態がExchange以上の場合、Neighbor FSMのSEQNumberMismatchイベントを生成します。
3. Otherwise, process the DBD packet as described in [RFC2328].
3. それ以外の場合は、[RFC2328]で説明されているDBDパケットを処理します。
During normal processing of the initial OOB DBD packet (with bits R, I, M, and MS set), if the receiving router is selected to be the Master, it may speed up the resynchronization process by immediately replying to the received packet.
初期OOB DBDパケット（ビットR、I、M、およびMSセットを使用）の通常の処理中、受信ルーターがマスターになるように選択されている場合、受信したパケットに直ちに返信することで再同期プロセスをスピードアップする場合があります。
It is also necessary to limit the time an adjacency can spend in ExStart, Exchange, and Loading states with OOBResync flag set to a finite period of time (e.g., by limiting the number of times DBD and link state request packets can be retransmitted). If the adjacency does not proceed to Full state before the timeout, it is indicative that the neighboring router cannot resynchronize its LSDB with the local router. The requesting router may decide to stop trying to resynchronize the LSDB over this adjacency (if, for example, it can be resynchronized via another neighbor on the same segment) or to resynchronize using the legacy method by clearing the OOBResync flag and leaving the FSM in ExStart state. The neighboring router may decide to cancel the OOB procedure for the neighbor.
また、隣接する時間をExstart、Exchange、およびLoadingの時間を制限する必要があります。これは、oobresyncフラグを有限の期間に設定します（たとえば、DBDとリンク状態リクエストパケットを再送信することができます）。隣接がタイムアウト前に完全な状態に進まない場合、隣接するルーターがLSDBをローカルルーターと再同期させることができないことを示しています。要求するルーターは、この隣接能力でLSDBを再同期させようとするのを止めることを決定する場合があります（たとえば、同じセグメントの別の隣人を介して再同期することができる場合）、またはOOBRESYNCフラグをクリアしてFSMを残してレガシー法を使用して再同期することを決定します。エクススタート状態。隣接するルーターは、近隣のOOB手順をキャンセルすることを決定する場合があります。
An OSPF implementation supporting the described technique should modify the logic consulting the state of a neighbor FSM as described below.
説明された手法をサポートするOSPF実装は、以下に説明するように、隣接FSMの状態に相談するロジックを変更する必要があります。
o FSM state transitioning from and to the Full state with the OOBResync flag set should not cause origination of a new version of router-LSA or network-LSA.
o OOBRESYNCフラグセットを使用して完全な状態から移行するFSM状態は、ルーターLSAまたはネットワークLSAの新しいバージョンの起源を引き起こすべきではありません。
o Any explicit checks for the Full state of a neighbor FSM for the purposes other than LSDB synchronization and flooding should treat states ExStart, Exchange, and Loading as state Full, provided that OOBResync flag is set for the neighbor. (Flooding and MaxAge-LSA-specific procedures should not check the state of the OOBResync flag, but should continue consulting only the FSM state.)
o LSDBの同期と洪水以外の目的のために隣接FSMの完全な状態を明示的にチェックすることは、隣人向けにoobresyncフラグが設定されていることを条件に、状態を状態にし、交換し、状態を完全に扱う必要があります。（洪水とMaxage-LSA固有の手順は、OOBRESYNCフラグの状態を確認する必要はありませんが、FSM状態のみを継続する必要があります。）
To initiate out-of-band LSDB resynchronization, the router must first make sure that the corresponding neighbor supports this technology (by checking the LR-bit in the Options field of the neighbor data structure). If the neighboring router is capable, the OOBResync flag for the neighbor should be set to TRUE and the FSM state should be forced to ExStart.
バンド外のLSDB再同期を開始するには、ルーターはまず対応する隣接がこのテクノロジーをサポートすることを確認する必要があります（近隣データ構造のオプションフィールドでLRビットをチェックすることにより）。隣接するルーターが能力がある場合、隣人のoobresyncフラグは真に設定され、FSM状態を除去することを余儀なくされる必要があります。
Because OOB-capable routers explicitly indicate their capability by setting the corresponding bit in the Options field, no DBD packets with the R-bit set are sent to OOB-incapable routers.
OOB対応ルーターは、対応するビットをオプションフィールドに設定することにより、その機能を明示的に示しているため、RビットセットのあるDBDパケットはOOBインコープ可能なルーターに送信されません。
The LR-bit itself is transparent for OSPF implementations and does not affect communication between routers.
LR-BIT自体はOSPF実装に対して透明であり、ルーター間の通信には影響しません。
The described technique does not introduce any new security issues into the OSPF protocol.
説明されている手法では、OSPFプロトコルに新しいセキュリティの問題を導入しません。
Please refer to the "IANA Considerations" section of [RFC4813] for more information on the Extended Options bit definitions.
拡張オプションビット定義の詳細については、[RFC4813]の[RFC4813]の「IANA考慮事項」セクションを参照してください。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[RFC3623] Moy、J.、Pillay-Esnault、P。、およびA. Lindem、「Graceful OSPF Restart」、RFC 3623、2003年11月。
[RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007.
[RFC4813] Friedman、B.、Nguyen、L.、Roy、A.、Yeung、D。、およびA. Zinin、「OSPF Link-Local Signaling」、RFC 4813、2007年3月。
The authors would like to thank Acee Lindem, Russ White, Don Slice, and Alvaro Retana for their valuable comments.
著者は、貴重なコメントをしてくれたAcee Lindem、Russ White、Don Slice、Alvaro Retanaに感謝します。
Authors' Addresses
著者のアドレス
Liem Nguyen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: lhnguyen@cisco.com
Liem Nguyen Cisco Systems 225 West Tasman Drive San Jose、CA 95134 USAメール：lhnguyen@cisco.com
Abhay Roy Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: akr@cisco.com
Abhay Roy Cisco Systems 225 West Tasman Drive San Jose、CA 95134 USAメール：akr@cisco.com
Alex Zinin Alcatel-Lucent Mountain View, CA USA EMail: alex.zinin@alcatel-lucent.com
Alex Zinin Alcatel-Lucent Mountain View、CA USAメール：alex.zinin@alcatel-lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。