[要約] RFC 7391は、ForCESプロトコルの拡張に関するものであり、転送と制御要素の分離を目的としています。このRFCは、ネットワークデバイスの制御と転送を分離するためのプロトコル拡張を提供します。
Internet Engineering Task Force (IETF) J. Hadi Salim
Request for Comments: 7391 Mojatatu Networks
Updates: 5810, 7121 October 2014
Category: Standards Track
ISSN: 2070-1721
Forwarding and Control Element Separation (ForCES) Protocol Extensions
転送および制御要素分離（ForCES）プロトコル拡張
Abstract
概要
Experience in implementing and deploying the Forwarding and Control Element Separation (ForCES) architecture has demonstrated the need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. The ForCES protocol is extended with a table range operation and a new extension for error handling. This document updates the semantics in RFCs 5810 and 7121 to achieve that end goal.
Forwarding and Control Element Separation（ForCES）アーキテクチャの実装と展開の経験から、プログラマビリティを容易にし、一部のトランザクションのワイヤ効率を向上させるために、いくつかの小さな拡張が必要であることが実証されています。 ForCESプロトコルは、テーブル範囲操作とエラー処理のための新しい拡張機能で拡張されています。このドキュメントでは、RFC 5810および7121のセマンティクスを更新して、その最終目標を達成しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7391.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7391で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology and Conventions ................................3
1.1.1. Requirements Language ...............................3
1.1.2. Terminology .........................................3
2. Problem Overview ................................................4
2.1. Table Ranges ...............................................4
2.2. Error Codes ................................................4
3. Protocol Update .................................................5
3.1. Table Ranges ...............................................5
3.2. Error Codes ................................................6
3.2.1. New Codes ...........................................7
3.2.2. Private Vendor Codes ................................8
3.2.3. Extended Result TLV .................................8
3.2.3.1. Extended Result Backward Compatibility .....9
3.3. Large Table Dumping ........................................9
4. IANA Considerations ............................................11
5. Security Considerations ........................................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................12
Appendix A. New FEPO Version ......................................13
Acknowledgments ...................................................23
Author's Address ..................................................23
Experience in implementing and deploying the ForCES architecture has demonstrated the need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. This document describes a few extensions to the semantics in the ForCES protocol specification [RFC5810] to achieve that end goal.
ForCESアーキテクチャの実装と展開の経験から、プログラミングを容易にし、一部のトランザクションのワイヤ効率を向上させるために、いくつかの小さな拡張が必要であることが実証されています。このドキュメントでは、その最終目標を達成するためのForCESプロトコル仕様[RFC5810]のセマンティクスのいくつかの拡張について説明します。
This document describes and justifies the need for two small extensions that are backward compatible. This document also clarifies details of how dumping of a large table residing on an FE (Forwarding Element) is achieved. To summarize:
このドキュメントでは、下位互換性のある2つの小さな拡張機能の必要性について説明し、正当化します。このドキュメントでは、FE（Forwarding Element）にある大きなテーブルのダンプがどのように行われるかについても詳しく説明しています。要約する：
1. A table range operation to allow a controller or control application to request an arbitrary range of table rows is introduced.
1. コントローラーまたは制御アプリケーションが任意の範囲のテーブル行を要求できるようにするテーブル範囲操作が導入されました。
2. Additional error codes returned to the controller (or control application) by an FE are introduced. Additionally, a new extension to carry details on error codes is introduced. As a result, this document updates the definition of the FE Protocol Object (FEPO) Logical Functional Block (LFB) in [RFC7121].
2. FEによってコントローラー（または制御アプリケーション）に返される追加のエラーコードが導入されています。さらに、エラーコードの詳細を伝える新しい拡張機能が導入されました。結果として、このドキュメントは[RFC7121]のFEプロトコルオブジェクト（FEPO）論理機能ブロック（LFB）の定義を更新します。
3. While already supported, an FE response to a GET request of a large table that does not fit in a single Protocol Layer (PL) message is not described in [RFC5810]. This document clarifies the details.
3. すでにサポートされていますが、単一のプロトコル層（PL）メッセージに収まらない大きなテーブルのGET要求に対するFE応答は、[RFC5810]で説明されていません。このドキュメントは詳細を明らかにします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document reiterates the terminology defined in several ForCES documents ([RFC3746], [RFC5810], [RFC5811], and [RFC5812]) for the sake of contextual clarity.
このドキュメントでは、コンテキストを明確にするために、いくつかのForCESドキュメント（[RFC3746]、[RFC5810]、[RFC5811]、および[RFC5812]）で定義されている用語を繰り返します。
Control Element (CE)
制御要素（CE）
Forwarding Element (FE)
転送要素（FE）
FE Model
モデルで
LFB (Logical Functional Block) Class (or type)
LFB（論理機能ブロック）クラス（またはタイプ）
LFB Instance
LFBインスタンス
LFB Model
LFBモデル
LFB Metadata
LFBメタデータ
ForCES Component
ForCESコンポーネント
LFB Component
LFBコンポーネント
ForCES Protocol Layer (ForCES PL)
ForCESプロトコル層（ForCES PL）
ForCES Protocol Transport Mapping Layer (ForCES TML)
ForCESプロトコルトランスポートマッピングレイヤー（ForCES TML）
In this section, we present sample use cases to illustrate each challenge being addressed.
このセクションでは、サンプルユースケースを提示して、対処される各課題を説明します。
Consider, for the sake of illustration, an FE table with 1 million reasonably sized table rows that are sparsely populated. Assume, again for the sake of illustration, that there are 2000 table rows sparsely populated between the row indices 23-10023.
説明のために、まばらに設定された100万個の適度なサイズのテーブル行を持つFEテーブルを考えてみます。ここでも、説明のために、行インデックス23〜10023の間に2000個のテーブル行がまばらに配置されていると想定します。
Implementation experience has shown that existing approaches for retrieving or deleting a sizable number of table rows are both programmatically tedious and inefficient on utilization of both compute and wire resources.
実装の経験では、相当数のテーブル行を取得または削除するための既存のアプローチは、プログラム的に面倒であり、コンピューティングリソースとワイヤリソースの両方の利用に関して非効率的です。
By definition, ForCES GET and DEL requests sent from a controller (or control application) are prepended with a path to a component and sent to the FE. In the case of indexed tables, the component path can point to either a table or a table row index.
定義により、コントローラー（または制御アプリケーション）から送信されたForCES GETおよびDEL要求には、コンポーネントへのパスが付加され、FEに送信されます。インデックス付きテーブルの場合、コンポーネントパスはテーブルまたはテーブル行インデックスのいずれかを指すことができます。
As an example, a control application attempting to retrieve the first 2000 table rows appearing between row indices 23 and 10023 can achieve its goal in one of the following ways:
例として、行インデックス23と10023の間にある最初の2000テーブル行を取得しようとする制御アプリケーションは、次のいずれかの方法で目標を達成できます。
o Dump the whole table and filter for the needed 2000 table rows.
o テーブル全体をダンプし、必要な2000テーブル行をフィルタリングします。
o Send up to 10000 ForCES PL requests, incrementing the index by one each time, and stop when the needed 2000 entries are retrieved.
o 最大10000のForCES PLリクエストを送信し、毎回1つずつインデックスをインクリメントし、必要な2000エントリが取得されると停止します。
o If the application had knowledge of which table rows existed (not unreasonable given the controller is supposed to be aware of state within a Network Element (NE)), then the application could take advantage of ForCES batching to send fewer large messages (each with different path entries for a total of 2000).
o アプリケーションが存在するテーブル行を認識している場合（コントローラーがネットワーク要素（NE）内の状態を認識していることを考えると不合理ではありません）、アプリケーションはForCESバッチ処理を利用して、より大きなメッセージを送信することができます（それぞれ異なる合計2000のパスエントリ）。
As argued, while the above options exist, all are tedious.
主張されているように、上記のオプションは存在しますが、すべて面倒です。
[RFC5810] has defined a generic set of error codes that are to be returned to the CE from an FE. Deployment experience has shown that it would be useful to have more fine-grained error codes. As an example, the error code E_NOT_SUPPORTED could be mapped to many FE error source possibilities that need to then be interpreted by the caller based on some understanding of the nature of the sent request. This makes debugging more time consuming.
[RFC5810]は、FEからCEに返される一般的なエラーコードのセットを定義しています。デプロイメントの経験では、より細かいエラーコードを使用すると便利であることが示されています。例として、エラーコードE_NOT_SUPPORTEDは、送信された要求の性質の理解に基づいて呼び出し元が解釈する必要のある多くのFEエラーソースの可能性にマップできます。これにより、デバッグに時間がかかります。
This section describes a normative update to the ForCES protocol to address the issues discussed in Section 2.
このセクションでは、セクション2で説明した問題に対処するためのForCESプロトコルの規範的な更新について説明します。
We define a new TLV, TABLERANGE-TLV (type ID 0x0117), that will be associated with the PATH-DATA-TLV in the same manner the KEYINFO-TLV is. Figure 1 shows how this new TLV is constructed.
新しいTLVであるTABLERANGE-TLV（タイプID 0x0117）を定義します。これは、KEYINFO-TLVと同じ方法でPATH-DATA-TLVに関連付けられます。図1は、この新しいTLVの構成方法を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x0117) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ForCES Table Range Request Layout
図1：ForCESテーブル範囲リクエストのレイアウト
Figure 2 illustrates a GET request for a range of rows 11 to 23 of a table with a component path of "1/6".
図2は、「1/6」のコンポーネントパスを持つテーブルの行11〜23の範囲に対するGETリクエストを示しています。
OPER = GET-TLV
PATH-DATA-TLV:
flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6}
TABLERANGE-TLV content = {11,23}
Figure 2: ForCES Table Range Request Example
図2：ForCESテーブル範囲リクエストの例
The path flag F_SELTABRANGE (0x2, i.e., bit 1, where bit 0 is F_SELKEY as defined in [RFC5810]) MUST be set to indicate the presence of the TABLERANGE-TLV. The path flag bit F_SELTABRANGE can only be used in a GET or DEL and is mutually exclusive with F_SELKEY. The FE MUST enforce the path flag constraints and ensure that the selected path belongs to a defined, indexed table component. Any violation of these constraints MUST be rejected with an error code of E_INVALID_TFLAGS with a description of what the problem is when using extended error reporting (refer to Section 3.2).
パスフラグF_SELTABRANGE（0x2、つまりビット1。ビット0は[RFC5810]で定義されているF_SELKEYです）は、TABLERANGE-TLVの存在を示すように設定する必要があります。パスフラグビットF_SELTABRANGEは、GETまたはDELでのみ使用でき、F_SELKEYと相互に排他的です。 FEはパスフラグの制約を適用し、選択したパスが定義済みのインデックス付きテーブルコンポーネントに属していることを確認する必要があります。これらの制約の違反は、E_INVALID_TFLAGSのエラーコードと一緒に拒否する必要があります。拡張エラーレポートの使用時の問題の説明（3.2を参照）。
It should be noted that there are combinations of path selection mechanisms that should not appear together for the sake of simplicity of operations. These include TABLERANGE-TLV and KEYINFO-TLV as well as multiple nested TABLERANGE-TLVs.
動作を簡単にするために一緒に現れてはならない経路選択メカニズムの組み合わせがあることに注意すべきである。これらには、TABLERANGE-TLVとKEYINFO-TLV、およびネストされた複数のTABLERANGE-TLVが含まれます。
The TABLERANGE-TLV contents constitute:
TABLERANGE-TLVの内容は以下を構成します。
o A 32-bit start index. An index of 0 implies the beginning of the table row.
o 32ビットの開始インデックス。インデックス0は、テーブル行の始まりを意味します。
o A 32-bit end index. A value of 0xFFFFFFFF implies the last entry.
o 32ビットの終了インデックス。値0xFFFFFFFFは、最後のエントリを意味します。
The response for a table range query will either be:
テーブル範囲クエリの応答は次のいずれかになります。
o The requested table data returned (when at least one referenced row is available); in such a case, a response with a path pointing to the table and whose data content contains the row(s) will be sent to the CE. The data content MUST be encapsulated in a SPARSEDATA-TLV. The SPARSEDATA-TLV content will have the "I" (in Index-Length-Value (ILV)) for each table row indicating the table indices.
o 返された要求されたテーブルデータ（少なくとも1つの参照された行が使用可能な場合）。このような場合、テーブルを指すパスを持ち、そのデータコンテンツに行が含まれる応答がCEに送信されます。データコンテンツは、SPARSEDATA-TLVにカプセル化する必要があります。 SPARSEDATA-TLVコンテンツには、テーブルインデックスを示す各テーブル行の（Index-Length-Value（ILV）内の）「I」が含まれます。
o An EXTENDEDRESULT-TLV (refer to Section 3.2.3) when:
o EXTENDEDRESULT-TLV（セクション3.2.3を参照）：
* the response is to a range delete request. The result will either be:
* 応答は範囲削除要求に対するものです。結果は次のいずれかになります。
+ a success if any of the rows that were requested are deleted; or
+ 要求された行のいずれかが削除された場合は成功。または
+ a proper error code if none of the rows that were requested can be deleted.
+ 要求された行を削除できない場合の適切なエラーコード。
* data is absent and an error code of E_EMPTY with an optional content string describing the nature of the error is used (refer to Section 3.2).
* データが存在せず、エラーの性質を説明するオプションのコンテンツ文字列を含むE_EMPTYのエラーコードが使用されます（セクション3.2を参照）。
* both a path key and path table range were stated on the path flags of the original request. In such a case, an error code of E_INVALID_TFLAGS with an optional content string describing the nature of the error is used (refer to Section 3.2).
* パスキーとパステーブル範囲の両方が、元のリクエストのパスフラグに記載されていました。このような場合、エラーの性質を説明するオプションのコンテンツ文字列を含むE_INVALID_TFLAGSのエラーコードが使用されます（セクション3.2を参照）。
* other standard ForCES errors (such as Access Control List (ACL) constraints trying to retrieve contents of an unreadable table, accessing unknown components, etc.) occur.
* その他の標準のForCESエラー（アクセス制御リスト（ACL）制約など、読み取り不可能なテーブルの内容を取得しようとしたり、不明なコンポーネントにアクセスしたりするなど）が発生します。
We define the following:
以下を定義します。
1. A new set of error codes.
1. エラーコードの新しいセット。
2. Allocation of some reserved codes for private use.
2. いくつかの予約済みコードを私的使用のために割り当てます。
3. A new TLV, EXTENDEDRESULT-TLV (0x0118), that will carry a code (which will be a superset of what is currently specified in [RFC5810]) as well as an optional cause content. This is illustrated in Figure 3.
3. 新しいTLVであるEXTENDEDRESULT-TLV（0x0118）は、コード（[RFC5810]で現在指定されているもののスーパーセットになります）とオプションの原因コンテンツを含みます。これを図3に示します。
The EXTENDEDRESULT-TLV Result Value is 32 bits and is a superset of the RESULT-TLV Result Value defined in [RFC5810]. The new version code space is 32 bits as opposed to the code size of 8 bits in [RFC5810]. The first 8-bit values (256 codes) are common to both code spaces.
EXTENDEDRESULT-TLV Result Valueは32ビットであり、[RFC5810]で定義されているRESULT-TLV Result Valueのスーパーセットです。 [RFC5810]の8ビットのコードサイズとは対照的に、新しいバージョンのコードスペースは32ビットです。最初の8ビット値（256コード）は両方のコード空間に共通です。
+------------+-------------------------+----------------------------+
| Code | Mnemonic | Details |
+------------+-------------------------+----------------------------+
| 0x18 | E_TIMED_OUT | A timeout occurred while |
| | | processing the message |
| | | |
| 0x19 | E_INVALID_TFLAGS | Invalid table flags |
| | | |
| 0x1A | E_INVALID_OP | Requested operation is |
| | | invalid |
| | | |
| 0x1B | E_CONGEST_NT | Node congestion |
| | | notification |
| | | |
| 0x1C | E_COMPONENT_NOT_A_TABLE | Component not a table |
| | | |
| 0x1D | E_PERM | Operation not permitted |
| | | |
| 0x1E | E_BUSY | System is busy |
| | | |
| 0x1F | E_EMPTY | Table is empty |
| | | |
| 0x20 | E_UNKNOWN | A generic catch-all error |
| | | code. Carries a string to |
| | | further extrapolate what |
| | | the error implies. |
+------------+-------------------------+----------------------------+
Table 1: New Codes
表1：新しいコード
Codes 0x100-0x200 are reserved for use as private codes. Since these are freely available, it is expected that the FE and CE side implementations will both understand/interpret the semantics of any used codes and avoid any conflicts.
コード0x100-0x200は、プライベートコードとして使用するために予約されています。これらは自由に利用できるため、FE側とCE側の実装の両方が、使用されているコードのセマンティクスを理解/解釈し、競合を回避することが期待されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = EXTENDEDRESULT-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Cause Content |
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EXTENDEDRESULT-TLV
図3：EXTENDEDRESULT-TLV
o Like all other ForCES TLVs, the EXTENDEDRESULT-TLV is expected to be 32-bit aligned.
o 他のすべてのForCES TLVと同様に、EXTENDEDRESULT-TLVは32ビット境界で整列されることが期待されています。
o The EXTENDEDRESULT-TLV Result Value derives and extends from the same current namespace that is used by the RESULT-TLV Result Value as specified in Section 7.1.7 of [RFC5810]. The main difference is that there is now a 32-bit Result Value (as opposed to the old 8-bit).
o EXTENDEDRESULT-TLV Result Valueは、[RFC5810]のセクション7.1.7で指定されているRESULT-TLV Result Valueで使用されているのと同じ現在のネームスペースから派生して拡張されます。主な違いは、（古い8ビットではなく）32ビットの結果値が存在することです。
o The Optional Cause Content is defined to further disambiguate the Result Value. It is expected that UTF-8 string values will be used. The content Result Value is intended to be consumed by the (human) operator, and implementations may choose to specify different content for the same error code. Additionally, future codes may specify cause content to be of types other than string.
o オプションの原因コンテンツは、結果値をさらに明確にするために定義されています。 UTF-8文字列値が使用されることが予想されます。コンテンツの結果値は（人間の）オペレーターによって消費されることが意図されており、実装は同じエラーコードに対して異なるコンテンツを指定することを選択できます。さらに、将来のコードでは、コンテンツが文字列以外のタイプになる原因を指定する可能性があります。
o It is recommended that the maximum size of the cause string should not exceed 32 bytes. The cause string is not standardized by this document.
o 原因文字列の最大サイズは32バイトを超えないようにすることをお勧めします。原因文字列は、このドキュメントでは標準化されていません。
To support backward compatibility, we update the FEPO LFB (in Appendix A) to version 1.2. We also add a new component ID 16 (named EResultAdmin), and a capability component ID 32 (named EResultCapab).
下位互換性をサポートするために、FEPO LFB（付録A）をバージョン1.2に更新します。また、新しいコンポーネントID 16（EResultAdminという名前）と機能コンポーネントID 32（EResultCapabという名前）を追加します。
An FE will advertise its capability to support extended TLVs via the EResultCapab table. When an FE is capable of responding with both extended results and older result TLVs, it will have two table rows, one for each supported value. By default, an FE capable of supporting both modes will assume the lowest common denominator (i.e., EResultAdmin will be EResultNotSupported) and will issue responses using RESULT-TLVs. It should be noted that an FE advertising FEPO version 1.2 MUST support EXTENDEDRESULT-TLVs at minimum.
FEは、拡張されたTLVをサポートする機能をEResultCapabテーブルを介してアドバタイズします。 FEが拡張結果と古い結果のTLVの両方で応答できる場合、サポートされている値ごとに1つずつ、2つのテーブル行があります。デフォルトでは、両方のモードをサポートできるFEは、共通の最小値を想定し（つまり、EResultAdminはEResultNotSupportedになります）、RESULT-TLVを使用して応答を発行します。 FEアドバタイジングFEPOバージョン1.2は、最低でもEXTENDEDRESULT-TLVをサポートする必要があることに注意してください。
On an FE that supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a master CE can turn on support for extended results by setting the EResultAdmin value to 2, in which case the FE MUST switch over to sending only EXTENDEDRESULT-TLVs. Likewise, a master CE can turn off extended result responses by writing a 1 to the EResultAdmin. An FE that does not support one mode or the other MUST reject setting EResultAdmin to a value it does not support by responding with an error code of E_NOT_SUPPORTED. It is expected that all CEs participating in a high availability (HA) mode be capable of supporting FEPO version 1.2 whenever EResultAdmin is set to strict support of EXTENDEDRESULT-TLVs. The consensus between CEs in an HA set up to set strict support of EXTENDEDRESULT-TLVs is out of scope for this document.
RESULT-TLVとEXTENDEDRESULT-TLVの両方をサポートするFEでは、マスターCEはEResultAdmin値を2に設定することで拡張結果のサポートをオンにできます。この場合、FEはEXTENDEDRESULT-TLVのみの送信に切り替える必要があります。同様に、マスターCEは、1をEResultAdminに書き込むことにより、拡張結果応答をオフにすることができます。いずれかのモードをサポートしないFEは、エラーコードE_NOT_SUPPORTEDで応答することにより、サポートされていない値へのEResultAdminの設定を拒否する必要があります。 EResultAdminがEXTENDEDRESULT-TLVの厳密なサポートに設定されている場合は常に、高可用性（HA）モードに参加しているすべてのCEがFEPOバージョン1.2をサポートできることが期待されます。 EXTENDEDRESULT-TLVの厳密なサポートを設定するように設定されたHAのCE間のコンセンサスは、このドキュメントの範囲外です。
Imagine a GET request to a path that is a table, i.e., a table dump. Such a request is sent to the FE with a specific correlator, say X. Imagine this table to have a large number of entries at the FE. For the sake of illustration, let's say millions of rows. This requires that the FE delivers the response over multiple messages, all using the same correlator X.
テーブルであるパスへのGETリクエスト、つまりテーブルダンプを想像してください。このような要求は、特定の相関関係子（Xなど）を使用してFEに送信されます。このテーブルがFEに多数のエントリを持つと想像してください。説明のために、何百万行としましょう。これには、FEがすべて同じコリレータXを使用して複数のメッセージを介して応答を配信する必要があります。
The ForCES protocol document [RFC5810] does not adequately describe how a large multi-part GET response message is delivered; the text in this section clarifies. We limit the discussion to a table object only.
ForCESプロトコルドキュメント[RFC5810]では、大規模なマルチパートGET応答メッセージがどのように配信されるかについて十分に説明されていません。このセクションのテキストは明確にします。説明はテーブルオブジェクトのみに限定します。
Implementation experience of dumping large tables shows that we can use transaction flags to indicate that a GET response is the beginning, middle, or end of a multi-part message. In other words, we mirror the effect of an atomic transaction sent by a CE to an FE.
大きなテーブルをダンプする実装経験は、トランザクションフラグを使用して、GET応答がマルチパートメッセージの先頭、中間、または末尾であることを示すことができることを示しています。つまり、CEからFEに送信されるアトミックトランザクションの影響を反映しています。
CE PL FE PL
CE PL FE PL
| |
| (0) Query, Path-to-a-large-table, OP=GET |
|----------------------------------------------------->|
| correlator = X |
| |
| (1) Query-Response, SOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (2) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (3) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
. .
. .
. .
. .
| |
| (N) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (N) Query-Response, EOT,AT, OP=GET-RESPONSE |
|<-----------------------------------------------------|
| correlator = X |
| RESULT-TLV (SUCCESS) |
| |
Figure 4: Large Table Dump Time Sequence
図4：大規模なテーブルダンプの時間シーケンス
The last message to go to the CE, which carries the End Of Transaction (EOT) flag, MUST NOT carry any data. This allows us to mirror ForCES two-phase commit (2PC) messaging [RFC5810] where the last message is an empty commit message. A GET response will carry a RESULT-TLV in such a case.
トランザクションの終了（EOT）フラグを運ぶCEに行く最後のメッセージは、データを運んではいけません。これにより、最後のメッセージが空のコミットメッセージであるForCES 2フェーズコミット（2PC）メッセージング[RFC5810]をミラーリングできます。このような場合、GET応答はRESULT-TLVを送信します。
This document updates <https://www.iana.org/assignments/forces> as follows:
このドキュメントは、<https://www.iana.org/assignments/forces>を次のように更新します。
This document registers two new top-level TLVs and two new path flags; it also updates an IANA-registered FE Protocol Object Logical Functional Block (LFB).
このドキュメントでは、2つの新しいトップレベルTLVと2つの新しいパスフラグを登録しています。また、IANAに登録されたFEプロトコルオブジェクトの論理機能ブロック（LFB）も更新します。
Appendix A defines an update to the FE Protocol Object LFB to version 1.2. An entry for FE Protocol Object LFB version 1.2 has been added to the "Logical Functional Block (LFB) Class Names and Class Identifiers" sub-registry.
付録Aでは、FEプロトコルオブジェクトLFBのバージョン1.2への更新を定義しています。 FEプロトコルオブジェクトLFBバージョン1.2のエントリが「論理機能ブロック（LFB）クラス名とクラス識別子」サブレジストリに追加されました。
The following new TLVs have been defined and added to the "TLV Types" sub-registry:
以下の新しいTLVが定義され、「TLVタイプ」サブレジストリに追加されました。
o TABLERANGE-TLV (type ID 0x0117)
o TABLERANGE-TLV（タイプID 0x0117）
o EXTENDEDRESULT-TLV (type ID 0x0118)
o EXTENDEDRESULT-TLV（タイプID 0x0118）
The "RESULT-TLV Result Values" sub-registry has been updated as follows:
「RESULT-TLV Result Values」サブレジストリが次のように更新されました。
o Codes 0x21-0xFE are marked as Unassigned.
o コード0x21-0xFEは未割り当てとしてマークされます。
o Codes 0x18-0x20 are defined by this document in Section 3.2.1.
o コード0x18-0x20は、このドキュメントのセクション3.2.1で定義されています。
o Codes 0x100-0x200 are reserved for private use.
o コード0x100-0x200は、私的使用のために予約されています。
A new "EXTENDEDRESULT-TLV Result Values" sub-registry has been created. The codes 0x00-0xFF are mirrored from the "RESULT-TLV Result Values" sub-registry. Any future allocations of this code range (in the range 0x21-0xFE) must be made only in the new "EXTENDEDRESULT-TLV Result Values" sub-registry and not in the "RESULT-TLV Result Values" sub-registry. The codes 0x100-0x200 are reserved for private use as described earlier, and the code ranges 0x21-0xFE and 0x201-0xFFFFFFFF are marked as Unassigned with the IANA allocation policy of Specification Required [RFC5226]. The Designated Expert (DE) needs to ensure that existing deployments are not broken by any specified request. The DE should post a given code request to the ForCES WG mailing list (or a successor designated by the Area Director) for comment and review. The DE should then either approve or deny the registration request, publish a notice of the decision to the ForCES WG mailing list or its successor, and inform IANA of his/her decision. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable.
新しい「EXTENDEDRESULT-TLV Result Values」サブレジストリが作成されました。コード0x00-0xFFは、「RESULT-TLV Result Values」サブレジストリからミラーリングされます。このコード範囲（0x21-0xFEの範囲）の今後の割り当ては、新しい「EXTENDEDRESULT-TLV結果値」サブレジストリでのみ行う必要があり、「RESULT-TLV結果値」サブレジストリでは行わないでください。前に説明したように、コード0x100-0x200はプライベート用に予約されており、コード範囲0x21-0xFEおよび0x201-0xFFFFFFFFは、Specification Required [RFC5226]のIANA割り当てポリシーでUnassignedとしてマークされています。 Designated Expert（DE）は、指定された要求によって既存のデプロイメントが中断されないようにする必要があります。 DEは、コメントおよびレビューのために、所定のコード要求をForCES WGメーリングリスト（またはエリアディレクターによって指定された後継者）に投稿する必要があります。次に、DEは登録要求を承認または拒否し、決定の通知をForCES WGメーリングリストまたはその後継者に公開し、IANAに決定を通知する必要があります。拒否通知は説明によって正当化する必要があり、可能な場合は、要求を受け入れられるように変更する方法に関する具体的な提案を行う必要があります。
The security considerations described in the ForCES protocol [RFC5810] apply to this document as well.
ForCESプロトコル[RFC5810]で説明されているセキュリティの考慮事項は、このドキュメントにも適用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>.
[RFC5810] Doria、A.、Hadi Salim、J.、Haas、R.、Khosravi、H.、Wang、W.、Dong、L.、Gopal、R。、およびJ. Halpern、「転送および制御要素の分離（ForCES）プロトコル仕様」、RFC 5810、2010年3月、<http://www.rfc-editor.org/info/rfc5810>。
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol", RFC 5811, March 2010, <http://www.rfc-editor.org/info/rfc5811>.
[RFC5811] Hadi Salim、J。およびK. Ogawa、「Forwarding and Control Element Separation（ForCES）ProtocolのSCTPベースのトランスポートマッピングレイヤー（TML）」、RFC 5811、2010年3月、<http：//www.rfc -editor.org/info/rfc5811>。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010, <http://www.rfc-editor.org/ info/rfc5812>.
[RFC5812] Halpern、J。およびJ. Hadi Salim、「Forwarding and Control Element Separation（ForCES）Forwarding Element Model」、RFC 5812、2010年3月、<http://www.rfc-editor.org/ info / rfc5812> 。
[RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, "High Availability within a Forwarding and Control Element Separation (ForCES) Network Element", RFC 7121, February 2014, <http://www.rfc-editor.org/info/rfc7121>.
[RFC7121] Ogawa、K.、Wang、W.、Haleplidis、E.、and J. Hadi Salim、 "High Availability within a Forwarding and Control Element Separation（ForCES）Network Element"、RFC 7121、February 2014、<http： //www.rfc-editor.org/info/rfc7121>。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004, <http://www.rfc-editor.org/info/rfc3746>.
[RFC3746] Yang、L.、Dantu、R.、Anderson、T。、およびR. Gopal、「Forwarding and Control Element Separation（ForCES）Framework」、RFC 3746、2004年4月、<http：//www.rfc- editor.org/info/rfc3746>。
This version of FEPO updates the earlier one given in [RFC7121]. The XML has been validated against the schema defined in [RFC5812].
このバージョンのFEPOは、[RFC7121]で提供されている以前のバージョンを更新します。 XMLは、[RFC5812]で定義されているスキーマに対して検証されています。
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="lfb-schema.xsd" provides="FEPO">
<!-- XXX -->
<dataTypeDefs>
<dataTypeDef>
<name>CEHBPolicyValues</name>
<synopsis>
The possible values of CE heartbeat policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEHBPolicy0</name>
<synopsis>
The CE will send heartbeats to the FE
every CEHDI timeout if no other messages
have been sent since.
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEHBPolicy1</name>
<synopsis>
The CE will not send heartbeats to the FE.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FEHBPolicyValues</name>
<synopsis>
The possible values of FE heartbeat policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FEHBPolicy0</name>
<synopsis>
The FE will not generate any heartbeats to the CE.
</synopsis>
</specialValue>
<specialValue value="1">
<name>FEHBPolicy1</name>
<synopsis>
The FE generates heartbeats to the CE every
FEHI if no other
messages have been sent to the CE.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FERestartPolicyValues</name>
<synopsis>
The possible values of FE restart policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FERestartPolicy0</name>
<synopsis>
The FE restarts its state from scratch.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>HAModeValues</name>
<synopsis>
The possible values of HA modes
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>NoHA</name>
<synopsis>
The FE is not running in HA mode.
</synopsis>
</specialValue>
<specialValue value="1">
<name>ColdStandby</name>
<synopsis>
The FE is running in HA mode cold standby.
</synopsis>
</specialValue>
<specialValue value="2">
<name>HotStandby</name>
<synopsis>
The FE is running in HA mode hot standby.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>CEFailoverPolicyValues</name>
<synopsis>
The possible values of CE failover policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEFailoverPolicy0</name>
<synopsis>
The FE should stop functioning immediately
and transition to FE OperDisable state.
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEFailoverPolicy1</name>
<synopsis>
The FE should continue forwarding even
without an associated CE for CEFTI. The
FE goes to FE OperDisable when the CEFTI
expires and there is no association. Requires
graceful restart support.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FEHACapab</name>
<synopsis>
The supported HA features
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>GracefullRestart</name>
<synopsis>
The FE supports graceful restart.
</synopsis>
</specialValue>
<specialValue value="1">
<name>HA</name>
<synopsis>
The FE supports HA.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>CEStatusType</name>
<synopsis>Status values. Status for each CE</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>Disconnected</name>
<synopsis>No connection attempt with the CE yet
</synopsis>
</specialValue>
<specialValue value="1">
<name>Connected</name>
<synopsis>The FE connection with the CE at the TML
has been completed.
</synopsis>
</specialValue>
<specialValue value="2">
<name>Associated</name>
<synopsis>The FE has associated with the CE.
</synopsis>
</specialValue>
<specialValue value="3">
<name>IsMaster</name>
<synopsis>The CE is the master (and associated).
</synopsis>
</specialValue>
<specialValue value="4">
<name>LostConnection</name>
<synopsis>The FE was associated with the CE but
lost the connection.
</synopsis>
</specialValue>
<specialValue value="5">
<name>Unreachable</name>
<synopsis>The CE is deemed as unreachable by the FE.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>StatisticsType</name>
<synopsis>Statistics Definition</synopsis>
<struct>
<component componentID="1">
<name>RecvPackets</name>
<synopsis>Packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>RecvErrPackets</name>
<synopsis>Packets received from CE with errors
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>RecvBytes</name>
<synopsis>Bytes received from CE</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>RecvErrBytes</name>
<synopsis>Bytes received from CE in error</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="5">
<name>TxmitPackets</name>
<synopsis>Packets transmitted to CE</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="6">
<name>TxmitErrPackets</name>
<synopsis>
Packets transmitted to CE that incurred
errors
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="7">
<name>TxmitBytes</name>
<synopsis>Bytes transmitted to CE</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="8">
<name>TxmitErrBytes</name>
<synopsis>Bytes transmitted to CE incurring errors
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>AllCEType</name>
<synopsis>Table Type for AllCE component</synopsis>
<struct>
<component componentID="1">
<name>CEID</name>
<synopsis>ID of the CE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>Statistics</name>
<synopsis>Statistics per CE</synopsis>
<typeRef>StatisticsType</typeRef>
</component>
<component componentID="3">
<name>CEStatus</name>
<synopsis>Status of the CE</synopsis>
<typeRef>CEStatusType</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>ExtendedResultType</name>
<synopsis>
Possible extended result support
</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="1" max="2"/>
</rangeRestriction>
<specialValues>
<specialValue value="1">
<name>EResultNotSupported</name>
<synopsis>
Extended results are not supported.
</synopsis>
</specialValue>
<specialValue value="2">
<name>EResultSupported</name>
<synopsis>
Extended results are supported.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="2">
<name>FEPO</name>
<synopsis>
The FE Protocol Object, with extended result control
</synopsis>
<version>1.2</version>
<components>
<component componentID="1" access="read-only">
<name>CurrentRunningVersion</name>
<synopsis>Currently running ForCES version</synopsis>
<typeRef>uchar</typeRef>
</component>
<component componentID="2" access="read-only">
<name>FEID</name>
<synopsis>Unicast FEID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3" access="read-write">
<name>MulticastFEIDs</name>
<synopsis>
The table of all multicast IDs
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="4" access="read-write">
<name>CEHBPolicy</name>
<synopsis>
The CE Heartbeat Policy
</synopsis>
<typeRef>CEHBPolicyValues</typeRef>
</component>
<component componentID="5" access="read-write">
<name>CEHDI</name>
<synopsis>
The CE Heartbeat Dead Interval in milliseconds
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="6" access="read-write">
<name>FEHBPolicy</name>
<synopsis>
The FE Heartbeat Policy
</synopsis>
<typeRef>FEHBPolicyValues</typeRef>
</component>
<component componentID="7" access="read-write">
<name>FEHI</name>
<synopsis>
The FE Heartbeat Interval in milliseconds
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8" access="read-write">
<name>CEID</name>
<synopsis>
The Primary CE this FE is associated with
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="9" access="read-write">
<name>BackupCEs</name>
<synopsis>
The table of all backup CEs other than the
primary
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="10" access="read-write">
<name>CEFailoverPolicy</name>
<synopsis>
The CE Failover Policy
</synopsis>
<typeRef>CEFailoverPolicyValues</typeRef>
</component>
<component componentID="11" access="read-write">
<name>CEFTI</name>
<synopsis>
The CE Failover Timeout Interval in milliseconds
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="12" access="read-write">
<name>FERestartPolicy</name>
<synopsis>
The FE Restart Policy
</synopsis>
<typeRef>FERestartPolicyValues</typeRef>
</component>
<component componentID="13" access="read-write">
<name>LastCEID</name>
<synopsis>
The Primary CE this FE was last associated
with
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="14" access="read-write">
<name>HAMode</name>
<synopsis>
The HA mode used
</synopsis>
<typeRef>HAModeValues</typeRef>
</component>
<component componentID="15" access="read-only">
<name>AllCEs</name>
<synopsis>The table of all CEs</synopsis>
<array type="variable-size">
<typeRef>AllCEType</typeRef>
</array>
</component>
<component componentID="16" access="read-write">
<name>EResultAdmin</name>
<synopsis>
Turn extended results off or on,
but default to off.
</synopsis>
<typeRef>ExtendedResultType</typeRef>
<defaultValue>1</defaultValue>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>SupportableVersions</name>
<synopsis>
The table of ForCES versions that FE supports
</synopsis>
<array type="variable-size">
<typeRef>uchar</typeRef>
</array>
</capability>
<capability componentID="31">
<name>HACapabilities</name>
<synopsis>
The table of HA capabilities the FE supports
</synopsis>
<array type="variable-size">
<typeRef>FEHACapab</typeRef>
</array>
</capability>
<capability componentID="32">
<name>EResultCapab</name>
<synopsis>
The table of supported result capabilities
</synopsis>
<array type="variable-size">
<typeRef>ExtendedResultType</typeRef>
</array>
</capability>
</capabilities>
<events baseID="61">
<event eventID="1">
<name>PrimaryCEDown</name>
<synopsis>
The primary CE has changed.
</synopsis>
<eventTarget>
<eventField>LastCEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>LastCEID</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>PrimaryCEChanged</name>
<synopsis>A new primary CE has been selected.
</synopsis>
<eventTarget>
<eventField>CEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>CEID</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
Acknowledgments
謝辞
The author would like to thank Evangelos Haleplidis and Joel Halpern for discussions that made this document better. Adrian Farrel did an excellent AD review of the document, which improved the quality of this document. Tobias Gondrom did the Security Directorate review. Brian Carpenter did the Gen-ART review. Nevil Brownlee performed the Operations Directorate review. S. Moonesamy (SM) worked hard to review our publication process. Pearl Liang caught issues in the IANA text.
著者は、このドキュメントをより良くする議論をしてくれたEvangelos HaleplidisとJoel Halpernに感謝します。エイドリアン・ファレルは、この文書の優れたADレビューを行ったため、この文書の品質が向上しました。 Tobias GondromがSecurity Directorateのレビューを行いました。 Brian CarpenterがGen-ARTレビューを行いました。 Nevil Brownleeが作戦総局のレビューを行いました。 S.ムーネサミー（SM）は、私たちの出版プロセスをレビューするために懸命に働きました。パールリャンは、IANAテキストで問題を捉えました。
The author would like to thank the following IESG members who reviewed and improved this document: Alia Atlas, Barry Leiba, Brian Haberman, Kathleen Moriarty, Richard Barnes, and Spencer Dawkins.
著者は、このドキュメントをレビューおよび改善した次のIESGメンバーに感謝します。AliaAtlas、Barry Leiba、Brian Haberman、Kathleen Moriarty、Richard Barnes、およびSpencer Dawkins。
Author's Address
著者のアドレス
Jamal Hadi Salim Mojatatu Networks Suite 400, 303 Moodie Dr. Ottawa, Ontario K2H 9R4 Canada
Jamal Hadi Salim Mojatatu Networks Suite 400、303 Moodie Dr. Ottawa、オンタリオK2H 9R4カナダ
EMail: hadi@mojatatu.com