[要約] RFC 5810は、Forwarding and Control Element Separation (ForCES) Protocol Specificationに関するものであり、ForCESプロトコルの仕様と目的を定義しています。ForCESは、ネットワークデバイスの転送機能と制御機能を分離するためのプロトコルです。
Internet Engineering Task Force (IETF) A. Doria, Ed.
Request for Comments: 5810 Lulea University of Technology
Category: Standards Track J. Hadi Salim, Ed.
ISSN: 2070-1721 Znyx
R. Haas, Ed.
IBM
H. Khosravi, Ed.
Intel
W. Wang, Ed.
L. Dong
Zhejiang Gongshang University
R. Gopal
Nokia
J. Halpern
March 2010
Forwarding and Control Element Separation (ForCES) Protocol Specification
転送および制御要素分離（力）プロトコル仕様
Abstract
概要
This document specifies the Forwarding and Control Element Separation (ForCES) protocol. The ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC 3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML).
このドキュメントは、転送および制御要素分離（Force）プロトコルを指定します。力プロトコルは、力ネットワーク要素（力NE）の制御要素（CE）と転送要素（FE）間の通信に使用されます。この仕様は、RFC 3654で定義されている力プロトコル要件を満たすことを目的としています。力プロトコルに加えて、この仕様は輸送マッピング層（TML）の要件も定義します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc5810.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5810で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................5
2. Terminology and Conventions .....................................6
2.1. Requirements Language ......................................6
2.2. Other Notation .............................................6
2.3. Integers ...................................................6
3. Definitions .....................................................6
4. Overview .......................................................10
4.1. Protocol Framework ........................................11
4.1.1. The PL .............................................13
4.1.2. The TML ............................................14
4.1.3. The FEM/CEM Interface ..............................14
4.2. ForCES Protocol Phases ....................................15
4.2.1. Pre-association ....................................16
4.2.2. Post-association ...................................18
4.3. Protocol Mechanisms .......................................19
4.3.1. Transactions, Atomicity, Execution, and Responses ..19
4.3.2. Scalability ........................................25
4.3.3. Heartbeat Mechanism ................................26
4.3.4. FE Object and FE Protocol LFBs .....................27
4.4. Protocol Scenarios ........................................27
4.4.1. Association Setup State ............................27
4.4.2. Association Established State or Steady State ......29
5. TML Requirements ...............................................31
5.1. TML Parameterization ......................................34
6. Message Encapsulation ..........................................35
6.1. Common Header .............................................35
6.2. Type Length Value (TLV) Structuring .......................40
6.2.1. Nested TLVs ........................................41
6.2.2. Scope of the T in TLV ..............................41
6.3. ILV .......................................................41
6.4. Important Protocol Encapsulations .........................42
6.4.1. Paths ..............................................42
6.4.2. Keys ...............................................42
6.4.3. DATA TLVs ..........................................43
6.4.4. Addressing LFB Entities ............................43
7. Protocol Construction ..........................................44
7.1. Discussion on Encoding ....................................48
7.1.1. Data Packing Rules .................................48
7.1.2. Path Flags .........................................49
7.1.3. Relation of Operational Flags with Global
Message Flags ......................................49
7.1.4. Content Path Selection .............................49
7.1.5. LFBselect-TLV ......................................49
7.1.6. OPER-TLV ...........................................50
7.1.7. RESULT TLV .........................................52
7.1.8. DATA TLV ...........................................55
7.1.9. SET and GET Relationship ...........................56
7.2. Protocol Encoding Visualization ...........................56
7.3. Core ForCES LFBs ..........................................59
7.3.1. FE Protocol LFB ....................................60
7.3.2. FE Object LFB ......................................63
7.4. Semantics of Message Direction ............................63
7.5. Association Messages ......................................64
7.5.1. Association Setup Message ..........................64
7.5.2. Association Setup Response Message .................66
7.5.3. Association Teardown Message .......................68
7.6. Configuration Messages ....................................69
7.6.1. Config Message .....................................69
7.6.2. Config Response Message ............................71
7.7. Query Messages ............................................73
7.7.1. Query Message ......................................73
7.7.2. Query Response Message .............................75
7.8. Event Notification Message ................................77
7.9. Packet Redirect Message ...................................79
7.10. Heartbeat Message ........................................82
8. High Availability Support ......................................83
8.1. Relation with the FE Protocol .............................83
8.2. Responsibilities for HA ...................................86
9. Security Considerations ........................................87
9.1. No Security ...............................................87
9.1.1. Endpoint Authentication ............................88
9.1.2. Message Authentication .............................88
9.2. ForCES PL and TML Security Service ........................88
9.2.1. Endpoint Authentication Service ....................88
9.2.2. Message Authentication Service .....................89
9.2.3. Confidentiality Service ............................89
10. Acknowledgments ...............................................89
11. References ....................................................89
11.1. Normative References .....................................89
11.2. Informative References ...................................90
Appendix A. IANA Considerations ..................................91
A.1. Message Type Namespace ....................................91
A.2. Operation Selection .......................................92
A.3. Header Flags ..............................................93
A.4. TLV Type Namespace ........................................93
A.5. RESULT-TLV Result Values ..................................94
A.6. Association Setup Response ................................94
A.7. Association Teardown Message ..............................95
Appendix B. ForCES Protocol LFB Schema ...........................96
B.1. Capabilities .............................................102
B.2. Components ...............................................102
Appendix C. Data Encoding Examples ..............................103
Appendix D. Use Cases ...........................................107
Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework. While there may be multiple protocols used within the overall ForCES architecture, the terms "ForCES protocol" and "protocol" as used in this document refer to the protocol used to standardize the information exchange between Control Elements (CEs) and Forwarding Elements (FEs) only.
転送および制御要素分離（Forces）は、コントロールプレーンとフォワードプレーン間の情報交換をForce Network Element（Force NE）との間の情報交換を標準化するためのアーキテクチャのフレームワークと関連するプロトコルを定義します。RFC 3654は力の要件を定義し、RFC 3746はForce Frameworkを定義しました。全体的な力アーキテクチャ内で使用される複数のプロトコルが存在する場合がありますが、このドキュメントで使用される「力プロトコル」と「プロトコル」という用語は、制御要素（CES）と転送要素（FES）間の情報交換を標準化するために使用されるプロトコルを指します。それだけ。
The ForCES FE model [RFC5812] presents a formal way to define FE Logical Function Blocks (LFBs) using XML. LFB configuration components, capabilities, and associated events are defined when the LFB is formally created. The LFBs within the FE are accordingly controlled in a standardized way by the ForCES protocol.
力Feモデル[RFC5812]は、XMLを使用してFe論理関数ブロック（LFB）を定義する正式な方法を示しています。LFB構成コンポーネント、機能、および関連するイベントは、LFBが正式に作成されたときに定義されます。それに応じて、FE内のLFBは、力プロトコルによって標準化された方法で制御されます。
This document defines the ForCES protocol specifications. The ForCES protocol works in a master-slave mode in which FEs are slaves and CEs are masters. The protocol includes commands for transport of LFB configuration information, association setup, status, event notifications, etc.
このドキュメントでは、力のプロトコル仕様を定義しています。Force Protocolは、FESが奴隷であり、CESがマスターであるマスタースレーブモードで機能します。プロトコルには、LFB構成情報の輸送、関連付け、ステータス、イベント通知などのコマンドが含まれています。
Section 3 provides a glossary of terminology used in the specification.
セクション3では、仕様で使用される用語の用語集を提供します。
Section 4 provides an overview of the protocol, including a discussion on the protocol framework and descriptions of the Protocol Layer (PL), a Transport Mapping Layer (TML), and the ForCES protocol mechanisms. Section 4.4 describes several protocol scenarios and includes message exchange descriptions.
セクション4では、プロトコルフレームワークに関する議論やプロトコル層（PL）、トランスポートマッピング層（TML）、および力プロトコルメカニズムの説明を含む、プロトコルの概要を説明します。セクション4.4では、いくつかのプロトコルシナリオについて説明し、メッセージ交換の説明が含まれています。
While this document does not define the TML, Section 5 details the services that a TML MUST provide (TML requirements).
このドキュメントはTMLを定義していませんが、セクション5では、TMLが提供する必要があるサービス（TML要件）を詳しく説明しています。
The ForCES protocol defines a common header for all protocol messages. The header is defined in Section 6.1, while the protocol messages are defined in Section 7.
Force Protocolは、すべてのプロトコルメッセージの共通ヘッダーを定義します。ヘッダーはセクション6.1で定義され、プロトコルメッセージはセクション7で定義されています。
Section 8 describes the protocol support for high-availability mechanisms including redundancy and fail over.
セクション8では、冗長性を含む高可用性メカニズムのプロトコルサポートについて説明します。
Section 9 defines the security mechanisms provided by the PL and TML.
セクション9では、PLとTMLによって提供されるセキュリティメカニズムを定義しています。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
In Table 1 and Table 2, the following notation is used to indicate multiplicity:
表1と表2では、次の表記を使用して、多重性を示しています。
(value)+ .... means "1 or more instances of value"
(value)* .... means "0 or more instances of value"
All integers are to be coded as unsigned binary integers of appropriate length.
すべての整数は、適切な長さの署名されていないバイナリ整数としてコード化されます。
This document follows the terminology defined by the ForCES requirements in [RFC3654] and by the ForCES framework in [RFC3746]. The definitions be are repeated below for clarity.
このドキュメントは、[RFC3654]の力要件と[RFC3746]の力フレームワークによって定義された用語に従います。明確にするために、定義を以下に繰り返します。
Addressable Entity (AE):
アドレス可能なエンティティ（AE）：
A physical device that is directly addressable given some interconnect technology. For example, on IP networks, it is a device that can be reached using an IP address; and on a switch fabric, it is a device that can be reached using a switch fabric port number.
相互接続テクノロジーを考慮して、直接アドレス指定できる物理デバイス。たとえば、IPネットワークでは、IPアドレスを使用して到達できるデバイスです。また、スイッチファブリックでは、スイッチファブリックポート番号を使用して到達できるデバイスです。
Control Element (CE):
制御要素（CE）：
A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs on how to process packets. CEs handle functionality such as the execution of control and signaling protocols.
Force Protocolを実装し、それを使用してパケットの処理方法について1つ以上のFESに指示する論理的エンティティ。CESは、制御プロトコルやシグナル伝達プロトコルの実行などの機能を処理します。
CE Manager (CEM):
CEマネージャー（CEM）：
A logical entity responsible for generic CE management tasks. It is particularly used during the pre-association phase to determine with which FE(s) a CE should communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs.
一般的なCE管理タスクを担当する論理的エンティティ。これは、Pre-Asociation段階で特に、どのFe（S）が通信すべきかを決定するために使用されます。このプロセスはFe Discoveryと呼ばれ、CEマネージャーが利用可能なFESの機能を学習することが含まれる場合があります。
Data Path:
データ経路：
A conceptual path taken by packets within the forwarding plane inside an FE.
FE内の転送面内のパケットによって採用された概念パス。
Forwarding Element (FE):
転送要素（FE）：
A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per-packet processing and handling as directed/controlled by one or more CEs via the ForCES protocol.
Force Protocolを実装する論理的エンティティ。FESは、基礎となるハードウェアを使用して、パケットごとの処理と取り扱いを、力プロトコルを介して1つ以上のCESが指示/制御します。
FE Model:
FEモデル：
A model that describes the logical processing functions of an FE. The FE model is defined using Logical Function Blocks (LFBs).
Feの論理処理関数を記述するモデル。FEモデルは、論理関数ブロック（LFB）を使用して定義されます。
FE Manager (FEM):
FEマネージャー（FEM）：
A logical entity responsible for generic FE management tasks. It is used during the pre-association phase to determine with which CE(s) an FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. An FE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which CE(s) to use. Being a logical entity, an FE manager might be physically combined with any of the other logical entities such as FEs.
一般的なFE管理タスクを担当する論理的エンティティ。事前分類段階で使用され、FEがどのCE（S）が通信するかを決定します。このプロセスはCE Discoveryと呼ばれ、FEマネージャーが利用可能なCEの機能を学習することが含まれる場合があります。FEマネージャーは、静的構成から事前関連フェーズプロトコル（以下を参照）まで何でも使用して、使用するCE（S）を決定できます。論理的なエンティティであるため、FEマネージャーは、FESなどの他の論理エンティティと物理的に組み合わせることができます。
ForCES Network Element (NE):
強制ネットワーク要素（NE）：
An entity composed of one or more CEs and one or more FEs. To entities outside an NE, the NE represents a single point of management. Similarly, an NE usually hides its internal organization from external entities.
1つ以上のCEと1つ以上のFESで構成されるエンティティ。NE以外のエンティティにとって、NEは単一の管理ポイントを表します。同様に、NEは通常、外部エンティティから内部組織を隠します。
High Touch Capability:
ハイタッチ機能：
This term will be used to apply to the capabilities found in some forwarders to take action on the contents or headers of a packet based on content other than what is found in the IP header. Examples of these capabilities include quality of service (QoS) policies, virtual private networks, firewall, and L7 content recognition.
この用語は、一部のフォワーダーで見つかった機能に適用され、IPヘッダーで見つかったもの以外のコンテンツに基づいてパケットの内容またはヘッダーにアクションを実行します。これらの機能の例には、サービス品質（QOS）ポリシー、仮想プライベートネットワーク、ファイアウォール、L7コンテンツ認識が含まれます。
Inter-FE Topology:
Inter-FEトポロジ：
See FE Topology.
FEトポロジーを参照してください。
Intra-FE Topology:
Intra-FEトポロジ：
See LFB Topology.
LFBトポロジーを参照してください。
LFB (Logical Function Block):
LFB（論理関数ブロック）：
The basic building block that is operated on by the ForCES protocol. The LFB is a well-defined, logically separable functional block that resides in an FE and is controlled by the CE via the ForCES protocol. The LFB may reside at the FE's data path and process packets or may be purely an FE control or configuration entity that is operated on by the CE. Note that the LFB is a functionally accurate abstraction of the FE's processing capabilities, but not a hardware-accurate representation of the FE implementation.
フォースプロトコルによって動作する基本的なビルディングブロック。LFBは、FEに存在する明確に定義された論理的に分離可能な機能ブロックであり、Forceプロトコルを介してCEによって制御されます。LFBは、FEのデータパスとプロセスパケットに存在する場合があります。または、CEによって操作されるFEコントロールまたは構成エンティティの純粋なものである場合があります。LFBは、FEの処理能力を機能的に正確に抽象化しているが、FE実装のハードウェアがアクセスする表現ではないことに注意してください。
FE Topology:
FEトポロジ：
A representation of how the multiple FEs within a single NE are interconnected. Sometimes this is called inter-FE topology, to be distinguished from intra-FE topology (i.e., LFB topology).
単一のNE内の複数のFEがどのように相互接続されているかの表現。これは、FE内トポロジーと呼ばれる場合があり、FE内トポロジ（つまり、LFBトポロジ）と区別されます。
LFB Class and LFB Instance:
LFBクラスとLFBインスタンス：
LFBs are categorized by LFB classes. An LFB instance represents an LFB class (or type) existence. There may be multiple instances of the same LFB class (or type) in an FE. An LFB class is represented by an LFB class ID, and an LFB instance is represented by an LFB instance ID. As a result, an LFB class ID associated with an LFB instance ID uniquely specifies an LFB existence.
LFBはLFBクラスによって分類されます。LFBインスタンスは、LFBクラス（またはタイプ）の存在を表します。FEには、同じLFBクラス（またはタイプ）の複数のインスタンスがある場合があります。LFBクラスはLFBクラスIDで表され、LFBインスタンスはLFBインスタンスIDで表されます。その結果、LFBインスタンスIDに関連付けられたLFBクラスIDは、LFBの存在を一意に指定します。
LFB Meta Data:
LFBメタデータ：
Meta data is used to communicate per-packet state from one LFB to another, but is not sent across the network. The FE model defines how such meta data is identified, produced, and consumed by the LFBs. It defines the functionality but not how meta data is encoded within an implementation.
メタデータは、パケットごとの状態をあるLFBから別のLFBに通信するために使用されますが、ネットワーク全体で送信されません。FEモデルは、そのようなメタデータがLFBによってどのように識別、生産、および消費されるかを定義しています。機能を定義しますが、実装内でメタデータがエンコードされる方法は定義しません。
LFB Component:
LFBコンポーネント：
Operational parameters of the LFBs that must be visible to the CEs are conceptualized in the FE model as the LFB components. The LFB components include, for example, flags, single parameter arguments, complex arguments, and tables that the CE can read and/or write via the ForCES protocol (see below).
CESに見える必要があるLFBの運用パラメーターは、FEモデルでLFBコンポーネントとして概念化されます。LFBコンポーネントには、たとえば、フラグ、単一のパラメーター引数、複雑な引数、およびCEがフォースプロトコルを介して読み取りおよび/または書き込むことができる表が含まれます（以下を参照）。
LFB Topology:
LFBトポロジ：
Representation of how the LFB instances are logically interconnected and placed along the data path within one FE. Sometimes it is also called intra-FE topology, to be distinguished from inter-FE topology.
LFBインスタンスが論理的に相互接続され、1つのFE以内のデータパスに沿って配置される方法の表現。時には、FE内トポロジーと区別されることもあります。
Pre-association Phase:
前協会段階：
The period of time during which an FE manager and a CE manager are determining which FE(s) and CE(s) should be part of the same network element.
FEマネージャーとCEマネージャーがどのFe（S）とCE（S）が同じネットワーク要素の一部であるかを決定している期間。
Post-association Phase:
関連後段階：
The period of time during which an FE knows which CE is to control it and vice versa. This includes the time during which the CE and FE are establishing communication with one another.
FeがどのCEがそれを制御するかを知っている期間、逆も同様です。これには、CEとFEが互いにコミュニケーションを確立している時間が含まれます。
ForCES Protocol:
力プロトコル：
While there may be multiple protocols used within the overall ForCES architecture, the terms "ForCES protocol" and "protocol" refer to the Fp reference points in the ForCES framework in [RFC3746]. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or communication between FE and CE managers. Basically, the ForCES protocol works in a master-slave mode in which FEs are slaves and CEs are masters. This document defines the specifications for this ForCES protocol.
全体的な力アーキテクチャ内で使用される複数のプロトコルがある場合がありますが、「Force Protocol」と「プロトコル」という用語は、[RFC3746]のForce FrameworkのFP参照ポイントを指します。このプロトコルは、CE-CE-CE通信、FE対FE通信、またはFEマネージャーとCEマネージャーの間の通信には適用されません。基本的に、Force Protocolは、FESが奴隷であり、CEがマスターであるマスタースレーブモードで機能します。このドキュメントは、この力プロトコルの仕様を定義しています。
ForCES Protocol Layer (ForCES PL):
力プロトコル層（Forces PL）：
A layer in the ForCES protocol architecture that defines the ForCES protocol messages, the protocol state transfer scheme, and the ForCES protocol architecture itself (including requirements of ForCES TML as shown below). Specifications of ForCES PL are defined by this document.
Force Protocolメッセージ、プロトコル状態転送スキーム、およびForces Protocol Architecture自体を定義するForce Protocolアーキテクチャのレイヤー（以下に示すようにForce TMLの要件を含む）。力PLの仕様は、このドキュメントで定義されています。
ForCES Protocol Transport Mapping Layer (ForCES TML):
力プロトコル輸送マッピング層（力TML）：
A layer in ForCES protocol architecture that uses the capabilities of existing transport protocols to specifically address protocol message transportation issues, such as how the protocol messages are mapped to different transport media (like TCP, IP, ATM, Ethernet, etc.), and how to achieve and implement reliability, multicast, ordering, etc. The ForCES TML specifications are detailed in separate ForCES documents, one for each TML.
既存のトランスポートプロトコルの機能を使用して、プロトコルメッセージの輸送の問題に特異的に対処するために、プロトコルメッセージをさまざまなトランスポートメディアにマッピングする方法（TCP、IP、ATM、イーサネットなど）や方法や方法や方法やどのように対処するための力プロトコルアーキテクチャのレイヤー信頼性、マルチキャスト、注文などを実現および実装するため。TMLの仕様は、TMLごとに1つずつ、個別の力文書で詳述されています。
The reader is referred to the framework document [RFC3746], and in particular, Sections 3 and 4, for an architectural overview and an explanation of how the ForCES protocol fits in. There may be some content overlap between the framework document and this section in order to provide clarity. This document is authoritative on the protocol, whereas [RFC3746] is authoritative on the architecture.
読者は、アーキテクチャの概要と、力のプロトコルがどのように適合するかの説明については、フレームワークドキュメント[RFC3746]、特にセクション3と4を参照してください。明確さを提供するために。このドキュメントはプロトコルで権威がありますが、[RFC3746]はアーキテクチャでは権威があります。
Figure 1 below is reproduced from the framework document for clarity. It shows an NE with two CEs and two FEs.
以下の図1は、明確にするためにフレームワークドキュメントから再現されています。2つのCEと2つのFEを持つNEを示します。
---------------------------------------
| ForCES Network Element |
-------------- Fc | -------------- -------------- |
| CE Manager |---------+-| CE 1 |------| CE 2 | |
-------------- | | | Fr | | |
| | -------------- -------------- |
| Fl | | | Fp / |
| | Fp| |----------| / |
| | | |/ |
| | | | |
| | | Fp /|----| |
| | | /--------/ | |
-------------- Ff | -------------- -------------- |
| FE Manager |---------+-| FE 1 | Fi | FE 2 | |
-------------- | | |------| | |
| -------------- -------------- |
| | | | | | | | | |
----+--+--+--+----------+--+--+--+-----
| | | | | | | |
| | | | | | | |
Fi/f Fi/f
Fp: CE-FE interface Fi: FE-FE interface Fr: CE-CE interface Fc: Interface between the CE manager and a CE Ff: Interface between the FE manager and an FE Fl: Interface between the CE manager and the FE manager Fi/f: FE external interface
FP：CE-FEインターフェイスFi：Fe-FeインターフェイスFR：CE-CEインターフェイスFC：CEマネージャーとCE FFの間のインターフェイス：FEマネージャーとFE FLの間のインターフェース：CEマネージャーとFEマネージャーFIの間のインターフェイス/F：FE外部インターフェイス
Figure 1: ForCES Architectural Diagram
図1：アーキテクチャ図を強制します
The ForCES protocol domain is found in the Fp reference points. The Protocol Element configuration reference points, Fc and Ff, also play a role in the booting up of the ForCES protocol. The protocol element configuration (indicated by reference points Fc, Ff, and Fl in [RFC3746]) is out of scope of the ForCES protocol but is touched on in this document in discussion of FEM and CEM since it is an integral part of the protocol pre-association phase.
Force Protocolドメインは、FP参照ポイントにあります。プロトコル要素構成基準点FCおよびFFも、Force Protocolの起動に役割を果たします。プロトコル要素構成（[RFC3746]の基準点FC、FF、およびFLで示される）は、力プロトコルの範囲外ですが、プロトコルの不可欠な部分であるため、FEMとCEMの議論でこのドキュメントで触れられています。前協会段階。
Figure 2 below shows further breakdown of the Fp interfaces by means of the example of an MPLS QoS-enabled Network Element.
以下の図2は、MPLS QoS対応ネットワーク要素の例によるFPインターフェイスのさらなる内訳を示しています。
-------------------------------------------------
| | | | | | |
|OSPF |RIP |BGP |RSVP |LDP |. . . |
| | | | | | |
------------------------------------------------- CE
| ForCES Interface |
-------------------------------------------------
^ ^
| |
ForCES | |data
control | |packets
messages| |(e.g., routing packets)
| |
v v
-------------------------------------------------
| ForCES Interface |
------------------------------------------------- FE
| | | | | | |
|LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . |
| | | | |fier | |
-------------------------------------------------
Figure 2: Examples of CE and FE Functions
図2：CEおよびFE関数の例
The ForCES interface shown in Figure 2 constitutes two pieces: the PL and the TML.
図2に示す力界面は、PLとTMLの2つの部分を構成します。
This is depicted in Figure 3 below.
これを以下の図3に示します。
+------------------------------------------------
| CE PL |
+------------------------------------------------
| CE TML |
+------------------------------------------------
^
|
ForCES | (i.e., ForCES data + control
PL | packets )
messages |
over |
specific |
TML |
encaps |
and |
transport |
|
v
+------------------------------------------------
| FE TML |
+------------------------------------------------
| FE PL |
+------------------------------------------------
Figure 3: ForCES Interface
図3：強制インターフェイス
The PL is in fact the ForCES protocol. Its semantics and message layout are defined in this document. The TML layer is necessary to connect two ForCES PLs as shown in Figure 3 above. The TML is out of scope for this document but is within scope of ForCES. This document defines requirements the PL needs the TML to meet.
実際、PLは力プロトコルです。このセマンティクスとメッセージレイアウトは、このドキュメントで定義されています。上記の図3に示すように、2つの力PLを接続するには、TML層が必要です。TMLはこのドキュメントの範囲外ですが、力の範囲内です。このドキュメントでは、PLが満たすためにTMLが必要な要件を定義しています。
Both the PL and the TML are standardized by the IETF. While only one PL is defined, different TMLs are expected to be standardized. To interoperate, the TML at the CE and FE are expected to conform to the same definition.
PLとTMLの両方がIETFによって標準化されています。1つのPLのみが定義されていますが、異なるTMLが標準化されると予想されます。相互運用するために、CEとFEのTMLは同じ定義に適合すると予想されます。
On transmit, the PL delivers its messages to the TML. The local TML delivers the message to the destination TML. On receive, the TML delivers the message to its destination PL.
送信時に、PLはTMLにメッセージを送信します。ローカルTMLは、宛先TMLにメッセージを配信します。受信時に、TMLはメッセージを宛先PLに配信します。
The PL is common to all implementations of ForCES and is standardized by the IETF as defined in this document. The PL is responsible for associating an FE or CE to an NE. It is also responsible for tearing down such associations. An FE uses the PL to transmit various subscribed-to events to the CE PL as well as to respond to various status requests issued from the CE PL. The CE configures both the FE and associated LFBs' operational parameters using the PL. In addition, the CE may send various requests to the FE to activate or deactivate it, reconfigure its HA parameterization, subscribe to specific events, etc. More details can be found in Section 7.
PLは、すべての力の実装に共通しており、このドキュメントで定義されているIETFによって標準化されています。PLは、FeまたはCEをNEに関連付ける責任があります。また、そのような関連性を取り壊す責任があります。FEでは、PLを使用して、さまざまなサブスクライブに登録されたイベントをCE PLに送信し、CE PLから発行されたさまざまなステータスリクエストに応答します。CEは、PLを使用してFEと関連するLFBSの動作パラメーターの両方を構成します。さらに、CEは、さまざまなリクエストをFEに送信してアクティブ化または非アクティブ化し、HAのパラメーター化を再構成し、特定のイベントをサブスクライブするなどします。詳細については、セクション7をご覧ください。
The TML transports the PL messages. The TML is where the issues of how to achieve transport-level reliability, congestion control, multicast, ordering, etc. are handled. It is expected that more than one TML will be standardized. The various possible TMLs could vary their implementations based on the capabilities of underlying media and transport. However, since each TML is standardized, interoperability is guaranteed as long as both endpoints support the same TML. All ForCES protocol layer implementations MUST be portable across all TMLs, because all TMLs MUST have the top-edge semantics defined in this document.
TMLはPLメッセージを輸送します。TMLは、輸送レベルの信頼性、混雑制御、マルチキャスト、注文などを達成する方法の問題が処理される場所です。複数のTMLが標準化されることが予想されます。可能なさまざまなTMLは、基礎となるメディアと輸送の機能に基づいて実装を変化させる可能性があります。ただし、各TMLは標準化されているため、両方のエンドポイントが同じTMLをサポートする限り、相互運用性が保証されます。すべてのTMLには、このドキュメントで定義されているトップエッジセマンティクスが必要なため、すべての力のプロトコル層の実装はすべてのTMLにわたって移植可能でなければなりません。
The FEM and CEM components, although valuable in the setup and configurations of both the PL and TML, are out of scope of the ForCES protocol. The best way to think of them is as configurations/ parameterizations for the PL and TML before they become active (or even at runtime based on implementation). In the simplest case, the FE or CE reads a static configuration file. RFC 3746 has a more detailed description on how the FEM and CEM could be used. The pre-association phase, where the CEM and FEM can be used, are described briefly in Section 4.2.1.
FEMおよびCEMコンポーネントは、PLとTMLの両方のセットアップと構成で価値がありますが、Force Protocolの範囲外です。それらを考える最良の方法は、PLとTMLがアクティブになる前（または実装に基づいて実行時に）構成/パラメーター化としてです。最も簡単な場合、FEまたはCEは静的構成ファイルを読み取ります。RFC 3746には、FEMとCEMをどのように使用できるかについて、より詳細な説明があります。CEMとFEMを使用できる場所では、セクション4.2.1で簡単に説明します。
An example of typical things the FEM/CEM could configure would be TML-specific parameterizations such as:
FEM/CEMが構成できる典型的なものの例は、次のようなTML固有のパラメーター化です。
a. How the TML connection should happen (for example, what IP addresses to use, transport modes, etc.)
a. TML接続の発生方法（たとえば、使用するIPアドレス、輸送モードなど）
b. The ID for the FE (FEID) or CE (CEID) (which would also be issued during the pre-association phase)
b. FE（FEID）またはCE（CEID）のID（前協会の段階でも発行されます）
c. Security parameterization such as keys, etc.
c. キーなどのセキュリティパラメーター化
d. Connection association parameters An example of connection association parameters might be:
d. 接続アソシエーションパラメーター接続関連パラメーターの例は次のとおりです。
o simple parameters: send up to 3 association messages every 1 second
o 簡単なパラメーター：1秒ごとに最大3つのアソシエーションメッセージを送信します
o complex parameters: send up to 4 association messages with increasing exponential timeout
o 複雑なパラメーター：指数タイムアウトの増加とともに最大4つの関連メッセージを送信します
ForCES, in relation to NEs, involves two phases: the pre-association phase where configuration/initialization/bootup of the TML and PL layer happens, and the post-association phase where the ForCES protocol operates to manipulate the parameters of the FEs.
NESに関連する力には、TMLおよびPL層の構成/初期化/ブートアップが発生する前分離段階と、FESのパラメーターを操作するために力プロトコルが動作するアサシエーション後フェーズの2つのフェーズが含まれます。
CE sends Association Setup
+---->--->------------>---->---->---->------->----+
| Y
^ |
| Y
+---+-------+ +-------------+
|FE pre- | | FE post- |
|association| CE sends Association Teardown | association |
|phase |<------- <------<-----<------<-------+ phase |
| | | |
+-----------+ +-------------+
^ Y
| |
+-<---<------<-----<------<----<---------<------+
FE loses association
Figure 4: The FE Protocol Phases
図4：FEプロトコルフェーズ
In the mandated case, once associated, the FE may forward packets depending on the configuration of its specific LFBs. An FE that is associated to a CE will continue sending packets until it receives an Association Teardown Message or until it loses association. An unassociated FE MAY continue sending packets when it has a high availability capability. The extra details are explained in Section 8 and not discussed here to allow for a clear explanation of the basics.
義務付けられたケースでは、関連すると、特定のLFBの構成に応じて、FEは5月のフォワードパケットです。CEに関連付けられているFEは、関連性の断倒メッセージを受信するか、関連性が失われるまでパケットを送信し続けます。関連していないFEは、高可用性機能がある場合、パケットを送信し続ける可能性があります。追加の詳細については、セクション8で説明し、基本の明確な説明を可能にするためにここでは説明しません。
The FE state transitions are controlled by means of the FE Object LFB FEState component, which is defined in [RFC5812], Section 5.1, and also explained in Section 7.3.2.
Fe状態の遷移は、[RFC5812]、セクション5.1で定義されており、セクション7.3.2で説明されているFEオブジェクトLFB Festateコンポーネントによって制御されます。
The FE initializes in the FEState OperDisable. When the FE is ready to process packets in the data path, it transitions itself to the OperEnable state.
FEは、フェスティブオペレーションの初期化を行います。FEがデータパスでパケットを処理する準備ができたら、それ自体がオペレーション可能な状態に移行します。
The CE may decide to pause the FE after it already came up as OperEnable. It does this by setting the FEState to AdminDisable. The FE stays in the AdminDisable state until it is explicitly configured by the CE to transition to the OperEnable state.
CEは、FEがすでに操作可能であると登場した後、FEを一時停止することを決定する場合があります。これは、祭りを設定することによって行います。FEは、CEによって明示的に設定され、オペレーション可能な状態に移行するまで、明白な状態にとどまります。
When the FE loses its association with the CE, it may go into the pre-association phase depending on the programmed policy. For the FE to properly complete the transition to the AdminDisable state, it MUST stop packet forwarding and this may impact multiple LFBS. How this is achieved is outside the scope of this specification.
FEがCEとの関連性を失うと、プログラムされたポリシーに応じて、それが事前分類段階に入る可能性があります。FEが入場可能な状態への移行を適切に完了するには、パケット転送を停止する必要があり、これは複数のLFBに影響を与える可能性があります。これがどのように達成されるかは、この仕様の範囲外です。
The ForCES interface is configured during the pre-association phase. In a simple setup, the configuration is static and is typically read from a saved configuration file. All the parameters for the association phase are well known after the pre-association phase is complete. A protocol such as DHCP may be used to retrieve the configuration parameters instead of reading them from a static configuration file. Note, this will still be considered static pre-association. Dynamic configuration may also happen using the Fc, Ff, and Fl reference points (refer to [RFC3746]). Vendors may use their own proprietary service discovery protocol to pass the parameters. Essentially, only guidelines are provided here and the details are left to the implementation.
Force Interfaceは、前協会の段階で構成されます。単純なセットアップでは、構成は静的であり、通常、保存された構成ファイルから読み取られます。関連段階のすべてのパラメーターは、前協会の段階が完了した後によく知られています。DHCPなどのプロトコルを使用して、静的構成ファイルから読み取る代わりに構成パラメーターを取得できます。注意してください、これはまだ静的な事前関連と見なされます。動的構成は、FC、FF、およびFLの参照ポイントを使用しても発生する可能性があります（[RFC3746]を参照）。ベンダーは、独自のサービスディスカバリープロトコルを使用してパラメーターを渡すことができます。基本的に、ここではガイドラインのみが提供され、詳細は実装に残されています。
The following are scenarios reproduced from the framework document to show a pre-association example.
以下は、前協会の例を示すために、フレームワークドキュメントから再現されたシナリオです。
<----Ff ref pt---> <--Fc ref pt------->
FE Manager FE CE Manager CE
| | | |
| | | |
(security exchange) (security exchange)
1|<------------>| authentication 1|<----------->|authentication
| | | |
(FE ID, components) (CE ID, components)
2|<-------------| request 2|<------------|request
| | | |
3|------------->| response 3|------------>|response
(corresponding CE ID) (corresponding FE ID)
| | | |
| | | |
Figure 5: Examples of a Message Exchange over the Ff and Fc Reference Points
図5：FFおよびFCの参照ポイントを介したメッセージ交換の例
<-----------Fl ref pt--------------> |
FE Manager FE CE Manager CE
| | | |
| | | |
(security exchange) | |
1|<------------------------------>| |
| | | |
(a list of CEs and their components) |
2|<-------------------------------| |
| | | |
(a list of FEs and their components) |
3|------------------------------->| |
| | | |
| | | |
Figure 6: Example of a Message Exchange over the Fl Reference Point
図6：FL参照ポイント上のメッセージ交換の例
Before the transition to the association phase, the FEM will have established contact with a CEM component. Initialization of the ForCES interface will have completed, and authentication as well as capability discovery may be complete. Both the FE and CE would have the necessary information for connecting to each other for configuration, accounting, identification, and authentication purposes. To summarize, at the completion of this stage both sides have all the necessary protocol parameters such as timers, etc. The Fl reference point may continue to operate during the association phase and may be used to force a disassociation of an FE or CE. The specific interactions of the CEM and the FEM that are part of the pre-association phase are out of scope; for this reason, these details are not discussed any further in this specification. The reader is referred to the framework document [RFC3746] for a slightly more detailed discussion.
関連フェーズへの移行の前に、FEMはCEMコンポーネントとの接触を確立します。Force Interfaceの初期化が完了し、認証と能力の発見が完了する可能性があります。FEとCEの両方には、構成、会計、識別、および認証の目的で相互に接続するために必要な情報があります。要約すると、この段階の完了時に、両側にはタイマーなどの必要なすべてのプロトコルパラメーターがあります。FL基準点は、関連フェーズ中に引き続き動作し、FeまたはCEの分離を強制するために使用される場合があります。CEMとPre-Associationフェーズの一部であるFEMの特定の相互作用は、範囲外です。このため、これらの詳細については、この仕様ではこれ以上議論されていません。読者は、少し詳細な議論をするために、フレームワークドキュメント[RFC3746]を参照されます。
In this phase, the FE and CE components communicate with each other using the ForCES protocol (PL over TML) as defined in this document. There are three sub-phases:
このフェーズでは、このドキュメントで定義されているように、FeおよびCEコンポーネントはForce Protocol（PL over TML）を使用して互いに通信します。3つのサブフェーズがあります。
o Association Setup Stage
o 協会のセットアップ段階
o Established Stage
o 確立されたステージ
o Association Lost Stage
o 協会の失われた段階
The FE attempts to join the NE. The FE may be rejected or accepted. Once granted access into the NE, capabilities exchange happens with the CE querying the FE. Once the CE has the FE capability information, the CE can offer an initial configuration (possibly to restore state) and can query certain components within either an LFB or the FE itself.
FEはNEに参加しようとします。FEは拒否または受け入れられる場合があります。NEへのアクセスが付与されると、FEをクエリするCEで機能交換が行われます。CEにFE機能情報があると、CEは初期構成（おそらく状態を復元するため）を提供し、LFBまたはFE自体内の特定のコンポーネントを照会できます。
More details are provided in Section 4.4.
詳細については、セクション4.4に記載されています。
On successful completion of this stage, the FE joins the NE and is moved to the Established Stage.
この段階が正常に完了すると、FEはNEに結合し、確立されたステージに移動します。
In this stage, the FE is continuously updated or queried. The FE may also send asynchronous event notifications to the CE or synchronous heartbeat notifications if programmed to do so. This stage continues until a termination occurs, either due to loss of connectivity or due to a termination initiated by either the CE or the FE.
この段階では、FEは継続的に更新または照会されます。FEは、プログラムされている場合は、CEまたは同期ハートビート通知に非同期イベント通知を送信する場合があります。この段階は、接続の喪失のため、またはCEまたはFEによって開始された終了のいずれかにより、終了が発生するまで続きます。
Refer to the section on protocol scenarios, Section 4.4, for more details.
詳細については、プロトコルシナリオのセクション4.4のセクションを参照してください。
In this stage, both or either the CE or FE declare the other side is no longer associated. The disconnection could be initiated by either party for administrative purposes but may also be driven by operational reasons such as loss of connectivity.
この段階では、CEまたはFEの両方が、反対側がもはや関連していないと宣言します。この切断は、行政目的のためにどちらの当事者によっても開始される可能性がありますが、接続の喪失などの運用上の理由によっても推進される場合があります。
A core LFB known as the FE Protocol Object (FEPO) is defined (refer to Appendix B and Section 7.3.1). FEPO defines various timers that can be used in conjunction with a traffic-sensitive heartbeat mechanism (Section 4.3.3) to detect loss of connectivity.
FEプロトコルオブジェクト（FEPO）として知られるコアLFBが定義されています（付録Bおよびセクション7.3.1を参照）。FEPOは、接続の喪失を検出するために、交通に敏感なハートビートメカニズム（セクション4.3.3）と組み合わせて使用できるさまざまなタイマーを定義します。
The loss of connectivity between TMLs does not indicate a loss of association between respective PL layers. If the TML cannot repair the transport loss before the programmed FEPO timer thresholds associated with the FE is exceeded, then the association between the respective PL layers will be lost.
TML間の接続性の損失は、それぞれのPL層間の関連性の損失を示すものではありません。FEに関連付けられたプログラムされたFEPOタイマーのしきい値を超える前にTMLが輸送損失を修復できない場合、それぞれのPL層間の関連が失われます。
FEPO defines several policies that can be programmed to define behavior upon a detected loss of association. The FEPO's programmed CE failover policy (refer to Sections 8, 7.3.1, 4.3.3, and B) defines what takes place upon loss of association.
FEPOは、検出された関連性の喪失時に行動を定義するようにプログラムできるいくつかのポリシーを定義します。FEPOのプログラムされたCEフェイルオーバーポリシー（セクション8、7.3.1、4.3.3、およびbを参照）は、関連性の喪失時に起こることを定義しています。
For this version of the protocol (as defined in this document), the FE, upon re-association, MUST discard any state it has as invalid and retrieve new state. This approach is motivated by a desire for simplicity (as opposed to efficiency).
このバージョンのプロトコル（このドキュメントで定義されている）の場合、再アソシエーション時にFEは、それが持っている状態を無効であると破棄し、新しい状態を取得する必要があります。このアプローチは、（効率とは対照的に）、単純さへの欲求によって動機付けられています。
Various semantics are exposed to the protocol users via the PL header including transaction capabilities, atomicity of transactions, two-phase commits, batching/parallelization, high availability, and failover as well as command pipelines.
トランザクション機能、トランザクションの原子性、2フェーズコミット、バッチ/並列化、高可用性、フェイルオーバー、およびコマンドパイプラインなど、PLヘッダーを介してプロトコルユーザーにさまざまなセマンティクスが公開されます。
The EM (Execution Mode) flag, AT (Atomic Transaction) flag, and TP (Transaction Phase) flag as defined in the common header (Section 6.1) are relevant to these mechanisms.
共通ヘッダー（セクション6.1）で定義されているEM（実行モード）フラグ、（アトミックトランザクション）フラグ、およびTP（トランザクションフェーズ）フラグは、これらのメカニズムに関連しています。
In the master-slave relationship, the CE instructs one or more FEs on how to execute operations and how to report the results.
マスタースレーブの関係では、CEは、操作を実行する方法と結果を報告する方法について1つ以上のFESに指示します。
This section details the different modes of execution that a CE can order the FE(s) to perform, as defined in Section 4.3.1.1. It also describes the different modes a CE can ask the FE(s) to use for formatting the responses after processing the operations as requested. These modes relate to the transactional two-phase commit operations.
このセクションでは、セクション4.3.1.1で定義されているように、CEがFE（S）を実行するように命じることができる異なる実行モードについて詳しく説明します。また、CEがFE（s）に要求されたように操作を処理した後に応答をフォーマットするために使用するように依頼できるさまざまなモードについても説明しています。これらのモードは、トランザクション2フェーズコミット操作に関連しています。
There are 3 execution modes that can be requested for a batch of operations spanning one or more LFB selectors (refer to Section 7.1.5) in one protocol message. The EM flag defined in the common header (Section 6.1) selects the execution mode for a protocol message, as below:
1つのプロトコルメッセージに1つまたは複数のLFBセレクター（セクション7.1.5を参照）にまたがる操作のバッチに対して要求できる3つの実行モードがあります。共通ヘッダー（セクション6.1）で定義されているEMフラグは、以下のようにプロトコルメッセージの実行モードを選択します。
a. execute-all-or-none
a. execute-all-or-none
b. continue-execute-on-failure
b. 継続的なエクスカイートオンフェイル
c. execute-until-failure
c. 実行途中で実行します
When set to this mode of execution, independent operations in a message MAY be targeted at one or more LFB selectors within an FE. All these operations are executed serially, and the FE MUST have no execution failure for any of the operations. If any operation fails to execute, then all the previous ones that have been executed prior to the failure will need to be undone. That is, there is rollback for this mode of operation.
この実行モードに設定すると、メッセージ内の独立した操作は、FE内の1つまたは複数のLFBセレクターを対象とする場合があります。これらの操作はすべて連続して実行され、FEは操作のいずれにおいても実行障害を持たない必要があります。いずれかの操作が実行に失敗した場合、障害の前に実行されたすべての操作は元に戻す必要があります。つまり、この動作モードにはロールバックがあります。
Refer to Section 4.3.1.2.2 for how this mode is used in cases of transactions. In such a case, no operation is executed unless a commit is issued by the CE.
トランザクションの場合のこのモードの使用方法については、セクション4.3.1.2.2を参照してください。そのような場合、CEによってコミットが発行されない限り、操作は実行されません。
Care should be taken on how this mode is used because a mis-configuration could result in traffic losses. To add certainty to the success of an operation, one should use this mode in a transactional operation as described in Section 4.3.1.2.2
誤って構成がトラフィックの損失をもたらす可能性があるため、このモードの使用方法に注意する必要があります。操作の成功に確実性を追加するには、セクション4.3.1.2.2で説明されているように、トランザクション操作でこのモードを使用する必要があります。
If several independent operations are targeted at one or more LFB selectors, execution continues for all operations at the FE even if one or more operations fail.
いくつかの独立した操作が1つ以上のLFBセレクターを対象としている場合、1つ以上の操作が失敗した場合でも、FEでのすべての操作の実行が継続されます。
In this mode, all operations are executed on the FE sequentially until the first failure. The rest of the operations are not executed but operations already completed are not undone. That is, there is no rollback in this mode of operation.
このモードでは、すべての操作が最初の障害まで順次順番に実行されます。残りの操作は実行されませんが、すでに完了した操作は取り消されません。つまり、この動作モードにはロールバックはありません。
A transaction is defined as a collection of one or more ForCES operations within one or more PL messages that MUST meet the ACIDity properties [ACID], defined as:
トランザクションは、次のように定義される酸性度特性[酸]を満たさなければならない1つまたは複数のPLメッセージ内の1つ以上の力操作のコレクションとして定義されます。
Atomicity: In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are.
Atomity：2つ以上の個別の情報を含むトランザクションでは、すべてのピースがコミットされるか、何もありません。
Consistency: A transaction either creates a new and valid state of data or, if any failure occurs, returns all data to the state it was in before the transaction was started.
一貫性：トランザクションは、新しい有効なデータの状態を作成するか、失敗が発生した場合、すべてのデータをトランザクションが開始される前に状態に戻します。
Isolation: A transaction in process and not yet committed MUST remain isolated from any other transaction.
分離：プロセス中のトランザクションであり、まだコミットされていないトランザクションは、他のトランザクションから隔離されたままでなければなりません。
Durability: Committed data is saved by the system such that, even in the event of a failure and a system restart, the data is available in its correct state.
耐久性：コミットされたデータはシステムによって保存され、障害やシステムの再起動の場合でも、データが正しい状態で利用可能になります。
There are cases where the CE knows exact memory and implementation details of the FE such as in the case of an FE-CE pair from the same vendor where the FE-CE pair is tightly coupled. In such a case, the transactional operations may be simplified further by extra computation at the CE. This view is not discussed further other than to mention that it is not disallowed.
CEがFEの正確なメモリと実装の詳細を知っている場合があります。たとえば、Fe-CEペアがしっかりと結合されている同じベンダーからのFE-CEペアの場合の場合です。そのような場合、CEでの追加の計算により、トランザクション操作がさらに簡素化される場合があります。この見解は、許可されていないことを言う以外に、これ以上議論されていません。
As defined above, a transaction is always atomic and MAY be
上記で定義されているように、トランザクションは常にアトミックであり、
a. Within an FE alone Example: updating multiple tables that are dependent on each other. If updating one fails, then any that were already updated MUST be undone.
a. FEのみの例：例：互いに依存する複数のテーブルを更新します。更新に失敗した場合、既に更新されたものはすべて元に戻す必要があります。
b. Distributed across the NE Example: updating table(s) that are inter-dependent across several FEs (such as L3 forwarding-related tables).
b. NEの例に分布している例：いくつかのFES（L3転送関連テーブルなど）に依存するテーブルを更新します。
By use of the execution mode, as defined in Section 4.3.1.1, the protocol has provided a mechanism for transactional operations within one stand-alone message. The 'execute-all-or-none' mode can meet the ACID requirements.
セクション4.3.1.1で定義されているように、実行モードを使用することにより、プロトコルは1つのスタンドアロンメッセージ内でトランザクション操作のメカニズムを提供しました。「execute-all-or-none」モードは、酸の要件を満たすことができます。
For transactional operations of multiple messages within one FE or across FEs, a classical transactional protocol known as two-phase commit (2PC) [2PCREF] is supported by the protocol to achieve the transactional operations utilizing Config messages (Section 7.6.1).
FESまたはFES全体の複数のメッセージのトランザクション操作の場合、2フェーズコミット（2PC）[2PCREF]として知られる古典的なトランザクションプロトコルは、構成メッセージを利用するトランザクション操作を実現するためにプロトコルによってサポートされます（セクション7.6.1）。
The COMMIT and TRCOMP operations in conjunction with the AT and the TP flags in the common header (Section 6.1) are provided for 2PC-based transactional operations spanning multiple messages.
Common Header（セクション6.1）のATおよびTPフラグと併用したTRCOMP操作は、複数のメッセージにまたがる2PCベースのトランザクション操作に提供されます。
The AT flag, when set, indicates that this message belongs to an Atomic Transaction. All messages for a transaction operation MUST have the AT flag set. If not set, it means that the message is a stand-alone message and does not participate in any transaction operation that spans multiple messages.
ATフラグは、設定されたときに、このメッセージが原子トランザクションに属していることを示します。トランザクション操作のすべてのメッセージには、ATフラグセットが必要です。設定されていない場合、メッセージはスタンドアロンメッセージであり、複数のメッセージにまたがるトランザクション操作に参加しないことを意味します。
The TP flag indicates the Transaction Phase to which this message belongs. There are 4 possible phases for a transactional operation known as:
TPフラグは、このメッセージが属するトランザクションフェーズを示します。次のように知られるトランザクション操作には、4つの可能なフェーズがあります。
SOT (Start of Transaction)
SOT（トランザクションの開始）
MOT (Middle of Transaction)
MOT（トランザクションの中央）
EOT (End of Transaction)
EOT（トランザクションの終わり）
ABT (Abort)
abt（abort）
The COMMIT operation is used by the CE to signal to the FE(s) to commit a transaction. When used with an ABT TP flag, the COMMIT operation signals the FE(s) to roll back (i.e., un-COMMIT) a previously committed transaction.
コミット操作は、CEがFE（S）に合図するためにトランザクションをコミットするために使用されます。ABT TPフラグで使用すると、コミット操作はFE（s）を示して、以前にコミットされたトランザクションをロールバック（つまり、コミットしていません）。
The TRCOMP operation is a small addition to the classical 2PC approach. TRCOMP is sent by the CE to signal to the FE(s) that the transaction they have COMMITed is now over. This allows the FE(s) an opportunity to clear state they may have kept around to perform a roll back (if it became necessary).
TRCOMP操作は、古典的な2PCアプローチへのわずかな追加です。TRCOMPは、CEによって送信され、彼らがコミットしたトランザクションが終わったことをFe（s）に信号します。これにより、Fe（s）がロールバックを実行するために維持した可能性のある状態をクリアする機会を可能にします（必要になった場合）。
A transaction operation is started with a message in which the TP flag is set to Start of Transaction (SOT). Multi-part messages, after the first one, are indicated by the Middle of Transaction (MOT) flag. All messages from the CE MUST set the AlwaysACK flag (Section 6) to solicit responses from the FE(s).
トランザクション操作は、TPフラグがトランザクションの開始（SOT）に設定されるメッセージから開始されます。マルチパートメッセージは、最初のメッセージの後、トランザクション（MOT）フラグの中央で示されます。CEからのすべてのメッセージは、Fe（s）からの応答を求めるために、Alwaysackフラグ（セクション6）を設定する必要があります。
Before the CE issues a commit (described further below), the FE MUST only validate that the operation can be executed but not execute it.
CEがコミットを発行する前に（以下でさらに説明）、FEは操作を実行できることのみを検証する必要がありますが、実行しない必要があります。
Any failure notified by an FE causes the CE to abort the transaction on all FEs involved in the transaction. This is achieved by sending a Config message with an ABT flag and a COMMIT operation.
FEによって通知された障害により、CEはトランザクションに関与するすべてのFEのトランザクションを中止します。これは、ABTフラグとコミット操作で構成メッセージを送信することによって達成されます。
If there are no failures by any participating FE, the transaction commitment phase is signaled from the CE to the FE by an End of Transaction (EOT) configuration message with a COMMIT operation.
参加FEによる障害がない場合、トランザクションコミットメントフェーズは、コミット操作を備えたトランザクション（EOT）構成メッセージの終了までにCEからFEに合図されます。
The FE MUST respond to the CE's EOT message. There are two possible failure scenarios in which the CE MUST abort the transaction (as described above):
FEはCEのEOTメッセージに応答する必要があります。CEがトランザクションを中止する必要がある2つの障害シナリオがあります（上記のように）。
a. If any participating FE responds with a failure message in relation to the transaction.
a. 参加しているFEが、トランザクションに関連して失敗メッセージで応答した場合。
b. If no response is received from a participating FE within a specified timeout.
b. 指定されたタイムアウト内の参加FEから応答がない場合。
If all participating FEs respond with a success indicator within the expected time, then the CE MUST issue a TRCOMP operation to all participating FEs. An FE MUST NOT respond to a TRCOMP.
すべての参加FESが予想される時間内に成功指標で応答する場合、CEはすべての参加FESにTRCOMP操作を発行する必要があります。FEはTRCOMPに応答してはなりません。
Note that a transactional operation is generically atomic; therefore, it requires that the execution modes of all messages in a transaction operation should always be kept the same and be set to 'execute-all-or-none'. If the EM flag is set to other execution modes, it will result in a transaction failure.
トランザクション操作は一般的に原子的であることに注意してください。したがって、トランザクション操作内のすべてのメッセージの実行モードを常に同じままに保ち、「execute-all-none」に設定する必要があります。EMフラグが他の実行モードに設定されている場合、トランザクションの障害が発生します。
As noted above, a transaction may span multiple messages. It is up to the CE to keep track of the different outstanding messages making up a transaction. As an example, the correlator field could be used to mark transactions and a sequence field to label the different messages within the same atomic transaction, but this is out of scope and up to implementations.
上記のように、トランザクションは複数のメッセージにまたがる場合があります。トランザクションを構成するさまざまな未解決のメッセージを追跡するのはCE次第です。例として、相関器フィールドを使用して、トランザクションとシーケンスフィールドをマークして、同じ原子トランザクション内の異なるメッセージにラベルを付けますが、これは範囲外で実装までです。
Any of the participating FEs or the CE or the associations between them may fail after the EOT Response message has been sent by the FE but before the CE has received all the responses, e.g., if the EOT response never reaches the CE.
参加しているFESまたはCEまたはそれらの間の関連付けは、EOT応答メッセージがFEによって送信された後に失敗する可能性がありますが、CEがすべての応答を受け取る前に、たとえばEOT応答がCEに到達しない場合。
In this protocol revision, as indicated in Section 4.2.2.3, an FE losing an association would be required to get entirely new state from the newly associated CE upon a re-association. Although this approach is simplistic and provides likeliness of losing data path traffic, it is a design choice to avoid the additional complexity of managing graceful restarts. The HA mechanisms (Section 8) are provided to allow for a continuous operation in case of FE failures.
セクション4.2.2.3で示されているように、このプロトコルの改訂では、再同でのCEからまったく新しい状態を取得するために、関連性を失うFEが必要になります。このアプローチは単純化されており、データパストラフィックを失う可能性を提供しますが、優雅な再起動の管理の追加の複雑さを回避することは設計の選択です。HAメカニズム（セクション8）が提供されており、Fe故障の場合に連続動作を可能にします。
Flexibility is provided on how to react when an FE loses association. This is dictated by the CE failover policy (refer to Section 8 and Section 7.3).
FEが関連性を失ったときに反応する方法について柔軟性が提供されます。これは、CEフェールオーバーポリシーによって決定されます（セクション8およびセクション7.3を参照）。
This section illustrates an example of how a successful two-phase commit between a CE and an FE would look in the simple case.
このセクションでは、CEとFEの間の成功した2相のコミットが単純なケースでどのように見えるかの例を示しています。
FE PL CE PL
Fe pl ce pl
| |
| (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (2) ACKnowledge |
|----------------------------------------------------->|
| |
| (3) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (4) ACKnowledge |
|----------------------------------------------------->|
| |
| (5) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (6) ACKnowledge |
|----------------------------------------------------->|
. .
. .
. .
. .
| |
| (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT |
|<-----------------------------------------------------|
| |
| (N+1)Config-response, ACKnowledge, OP=COMMIT-RESPONSE|
|----------------------------------------------------->|
| |
| (N+2) Config, OP=TRCOMP |
|<-----------------------------------------------------|
Figure 7: Example of a Two-Phase Commit
図7：2相コミットの例
For the scenario illustrated above:
上記のシナリオについては：
o In step 1, the CE issues a Config message with an operation of choice like a DEL or SET. The transaction flags are set to indicate a Start of Transaction (SOT), Atomic Transaction (AT), and execute-all-or-none.
o ステップ1では、CEは、DELやセットなどの選択の操作を備えた構成メッセージを発行します。トランザクションフラグは、トランザクション（SOT）、アトミックトランザクション（at）、および実行の開始を示すように設定されています。
o The FE validates that it can execute the request successfully and then issues an acknowledgment back to the CE in step 2.
o FEは、リクエストを正常に実行できることを検証し、ステップ2でCEに承認を発行することを検証します。
o In step 3, the same sort of construct as in step 1 is repeated by the CE with the transaction flag changed to Middle of Transaction (MOT).
o ステップ3では、ステップ1と同じ種類の構成がCEによって繰り返され、トランザクションフラグがトランザクション中央（MOT）に変更されます。
o The FE validates that it can execute the request successfully and then issues an acknowledgment back to the CE in step 4.
o FEは、リクエストを正常に実行できることを検証し、ステップ4でCEに承認を発行することを検証します。
o The CE-FE exchange continues in the same manner until all the operations and their parameters are transferred to the FE. This happens in step (N-1).
o CE-FE交換は、すべての操作とそのパラメーターがFEに転送されるまで、同じ方法で継続します。これはステップ（n-1）で発生します。
o In step N, the CE issues a commit. A commit is a Config message with an operation of type COMMIT. The transaction flag is set to End of Transaction (EOT). Essentially, this is an "empty" message asking the FE to execute all the operations it has gathered since the beginning of the transaction (message #1).
o ステップnでは、CEはコミットを発行します。コミットは、型コミットの操作を伴う構成メッセージです。トランザクションフラグは、トランザクションの終了（EOT）に設定されています。基本的に、これは、トランザクションの開始以来収集したすべての操作を実行するためにFEを尋ねる「空の」メッセージです（メッセージ＃1）。
o The FE at this point executes the full transaction. It then issues an acknowledgment back to the CE in step (N+1) that contains a COMMIT-RESPONSE.
o この時点でのFEは、完全なトランザクションを実行します。次に、コミットレスポンスを含むステップ（n 1）のCEに戻る承認を発行します。
o The CE in this case has the simple task of issuing a TRCOMP operation to the FE in step (N+2).
o この場合のCEには、ステップ（n 2）でFEにTRCOMP操作を発行するという単純なタスクがあります。
It is desirable that the PL not become the bottleneck when larger bandwidth pipes become available. To pick a hypothetical example in today's terms, if a 100-Gbps pipe is available and there is sufficient work, then the PL should be able to take advantage of this and use all of the 100-Gbps pipe. Two mechanisms have been provided to achieve this. The first one is batching and the second one is a command pipeline.
より大きな帯域幅パイプが利用可能になったときに、PLがボトルネックにならないことが望ましいです。今日の用語で仮説的な例を選択するために、100 gbpsパイプが利用可能で十分な作業がある場合、PLはこれを利用して100 gbpsパイプのすべてを使用できるはずです。これを達成するために2つのメカニズムが提供されています。最初のものはバッチで、2番目はコマンドパイプラインです。
Batching is the ability to send multiple commands (such as Config) in one Protocol Data Unit (PDU). The size of the batch will be affected by, among other things, the path MTU. The commands may be part of the same transaction or may be part of unrelated transactions that are independent of each other.
バッチングとは、1つのプロトコルデータユニット（PDU）に複数のコマンド（構成など）を送信する機能です。バッチのサイズは、とりわけパスMTUの影響を受けます。コマンドは同じトランザクションの一部であるか、互いに独立した無関係なトランザクションの一部である場合があります。
Command pipelining allows for pipelining of independent transactions that do not affect each other. Each independent transaction could consist of one or more batches.
コマンドパイプラインは、互いに影響を与えない独立したトランザクションのパイプラインを可能にします。各独立したトランザクションは、1つ以上のバッチで構成されています。
There are several batching levels at different protocol hierarchies.
異なるプロトコル階層にはいくつかのバッチレベルがあります。
o Multiple PL PDUs can be aggregated under one TML message.
o 複数のPL PDUを1つのTMLメッセージの下で集約できます。
o Multiple LFB classes and instances (as indicated in the LFB selector) can be addressed within one PL PDU.
o 複数のLFBクラスとインスタンス（LFBセレクターに示されているように）は、1つのPL PDU内で対処できます。
o Multiple operations can be addressed to a single LFB class and instance.
o 複数の操作に、単一のLFBクラスとインスタンスに対処できます。
The protocol allows any number of messages to be issued by the CE before the corresponding acknowledgments (if requested) have been returned by the FE. Hence, pipelining is inherently supported by the protocol. Matching responses with requests messages can be done using the correlator field in the message header.
このプロトコルにより、対応する謝辞（要求された場合）がFEによって返される前に、CEによって任意の数のメッセージを発行できます。したがって、パイプラインは本質的にプロトコルによってサポートされています。応答とリクエストメッセージを一致させることは、メッセージヘッダーの相関者フィールドを使用して実行できます。
Heartbeats (HBs) between FEs and CEs are traffic sensitive. An HB is sent only if no PL traffic is sent between the CE and FE within a configured interval. This has the effect of reducing the amount of HB traffic in the case of busy PL periods.
FESとCES間のハートビート（HB）はトラフィックに敏感です。HBは、構成された間隔内でCEとFEの間にPLトラフィックが送信されない場合にのみ送信されます。これは、忙しいPL期間の場合にHBトラフィックの量を減らす効果があります。
An HB can be sourced by either the CE or FE. When sourced by the CE, a response can be requested (similar to the ICMP ping protocol). The FE can only generate HBs in the case of being configured to do so by the CE. Refer to Section 7.3.1 and Section 7.10 for details.
HBは、CEまたはFEのいずれかによって調達できます。CEによって供給されると、応答を要求できます（ICMP pingプロトコルと同様）。FEは、CEによってそうするように設定されている場合にのみHBを生成できます。詳細については、セクション7.3.1およびセクション7.10を参照してください。
All PL messages operate on LFB constructs, as this provides more flexibility for future enhancements. This means that maintenance and configurability of FEs, NE, and the ForCES protocol itself MUST be expressed in terms of this LFB architecture. For this reason, special LFBs are created to accommodate this need.
すべてのPLメッセージはLFBコンストラクトで動作します。これにより、将来の強化により柔軟性が向上します。これは、FES、NE、および力プロトコル自体のメンテナンスと構成可能性をこのLFBアーキテクチャの観点から表現する必要があることを意味します。このため、このニーズに対応するために特別なLFBが作成されています。
In addition, this shows how the ForCES protocol itself can be controlled by the very same type of structures (LFBs) it uses to control functions such as IP forwarding, filtering, etc.
さらに、これは、IP転送、フィルタリングなどの機能を制御するために使用するまったく同じタイプの構造（LFB）によって、力プロトコル自体がどのように制御できるかを示しています。
To achieve this, the following specialized LFBs are introduced:
これを達成するために、次の特殊なLFBが導入されています。
o FE Protocol LFB, which is used to control the ForCES protocol.
o FeプロトコルLFB。これは、力プロトコルを制御するために使用されます。
o FE Object LFB, which is used to control components relative to the FE itself. Such components include FEState [RFC5812], vendor, etc.
o FeオブジェクトLFB。これは、Fe自体に対するコンポーネントを制御するために使用されます。このようなコンポーネントには、Festate [RFC5812]、ベンダーなどが含まれます。
These LFBs are detailed in Section 7.3.
これらのLFBはセクション7.3で詳しく説明されています。
This section provides a very high level description of sample message sequences between a CE and an FE. For protocol message encoding refer to Section 6.1, and for the semantics of the protocol refer to Section 4.3.
このセクションでは、CEとFEの間のサンプルメッセージシーケンスの非常に高いレベルの説明を提供します。プロトコルメッセージのエンコードについては、セクション6.1を参照し、プロトコルのセマンティクスについてはセクション4.3を参照してください。
The associations among CEs and FEs are initiated via the Association Setup message from the FE. If a Setup Request is granted by the CE, a successful Setup Response message is sent to the FE. If CEs and FEs are operating in an insecure environment, then the security associations have to be established between them before any association messages can be exchanged. The TML MUST take care of establishing any security associations.
CESとFES間の関連付けは、FEからのアソシエーションセットアップメッセージを介して開始されます。セットアップ要求がCEによって許可された場合、FEに成功したセットアップ応答メッセージが送信されます。CESとFESが不安定な環境で動作している場合、協会のメッセージを交換する前に、セキュリティ協会をそれらの間に確立する必要があります。TMLは、セキュリティ協会の確立に注意する必要があります。
This is typically followed by capability query, topology query, etc. When the FE is ready to start processing the data path, it sets the FEO FEState component to OperEnable (refer to [RFC5812] for details) and reports it to the CE as such when it is first queried. Typically, the FE is expected to be ready to process the data path before it associates, but there may be rare cases where it needs time do some pre-processing -- in such a case, the FE will start in the OperDisable state and when it is ready will transition to the OperEnable state. An example of an FE starting in OperDisable then transitioning to OperEnable is illustrated in Figure 8. The CE could at any time also disable the FE's data path operations by setting the FEState to AdminDisable. The FE MUST NOT process packets during this state unless the CE sets the state back to OperEnable. These sequences of messages are illustrated in Figure 8 below.
これには通常、機能クエリ、トポロジクエリなどが続きます。FEがデータパスの処理を開始する準備ができたら、Feo FestateコンポーネントをOperenableに設定します（詳細については[RFC5812]を参照）。最初に質問されたとき。通常、FEは関連する前にデータパスを処理する準備ができていると予想されますが、前処理を行う時間が必要なまれなケースがあるかもしれません。そのような場合、FEは操作可能な状態で始まります。準備ができているので、操作可能な状態に移行します。Operdisableから始まるFEの例は、図8に操作可能に移行することを示します。CEは、フェスティブを許可できるように設定することにより、FEのデータパス操作をいつでも無効にする可能性があります。CEが状態を操作可能に戻さない限り、FEはこの状態でパケットを処理してはなりません。これらのメッセージシーケンスは、以下の図8に示されています。
FE PL CE PL
Fe pl ce pl
| |
| Asso Setup Req |
|---------------------->|
| |
| Asso Setup Resp |
|<----------------------|
| |
| LFBx Query capability |
|<----------------------|
| |
| LFBx Query Resp |
|---------------------->|
| |
| FEO Query (Topology) |
|<----------------------|
| |
| FEO Query Resp |
|---------------------->|
| |
| FEO OperEnable Event |
|---------------------->|
| |
| Config FEO Adminup |
|<----------------------|
| |
| FEO Config-Resp |
|---------------------->|
| |
Figure 8: Message Exchange between CE and FE to Establish an NE Association
図8：NE関連を確立するためのCEとFEの間のメッセージ交換
On successful completion of this state, the FE joins the NE.
この状態が正常に完了すると、FeはNEに結合します。
In this state, the FE is continuously updated or queried. The FE may also send asynchronous event notifications to the CE, synchronous Heartbeat messages, or Packet Redirect message to the CE. This continues until a termination (or deactivation) is initiated by either the CE or FE. Figure 9 below, helps illustrate this state.
この状態では、FEは継続的に更新または照会されています。FEは、CEに非同期イベント通知、同期ハートビートメッセージ、またはCEにメッセージをリダイレクトすることもできます。これは、終了（または非アクティブ化）がCEまたはFEによって開始されるまで続きます。以下の図9は、この状態を説明するのに役立ちます。
FE PL CE PL
Fe pl ce pl
| |
| Heartbeat |
|<---------------------------->|
| |
| Heartbeat |
|----------------------------->|
| |
| Config-set LFBy (Event sub.) |
|<-----------------------------|
| |
| Config Resp LFBy |
|----------------------------->|
| |
| Config-set LFBx Component |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
|Config-Query LFBz (Stats) |
|<--------------------------- -|
| |
| Query Resp LFBz |
|----------------------------->|
| |
| FE Event Report |
|----------------------------->|
| |
| Config-Del LFBx Component |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
| Packet Redirect LFBx |
|----------------------------->|
| |
| Heartbeat |
|<-----------------------------|
. .
. .
| |
Figure 9: Message Exchange between CE and FE during Steady-State Communication Note that the sequence of messages shown in the figure serve only as examples and the message exchange sequences could be different from what is shown in the figure. Also, note that the protocol scenarios described in this section do not include all the different message exchanges that would take place during failover. That is described in the HA section (Section 8).
図9：定常状態通信中のCEとFEの間のメッセージ交換は、図に示されているメッセージのシーケンスは例としてのみ機能し、メッセージ交換シーケンスは図に示されているものとは異なる可能性があることに注意してください。また、このセクションで説明するプロトコルシナリオには、フェールオーバー中に行われるすべての異なるメッセージ交換が含まれていないことに注意してください。これは、HAセクション（セクション8）で説明されています。
The requirements below are expected to be met by the TML. This text does not define how such mechanisms are delivered. As an example, the mechanisms to meet the requirements could be defined to be delivered via hardware or between 2 or more TML software processes on different CEs or FEs in protocol-level schemes.
以下の要件は、TMLによって満たされると予想されます。このテキストは、そのようなメカニズムがどのように配信されるかを定義しません。例として、要件を満たすメカニズムは、ハードウェアを介して、またはプロトコルレベルのスキームで異なるCEまたはFESで2つ以上のTMLソフトウェアプロセスを介して配信されるように定義できます。
Each TML MUST describe how it contributes to achieving the listed ForCES requirements. If for any reason a TML does not provide a service listed below, a justification needs to be provided.
各TMLは、リストされた部隊の要件の達成にどのように貢献するかを説明する必要があります。何らかの理由でTMLが以下にリストされているサービスを提供しない場合、正当化を提供する必要があります。
Implementations that support the ForCES protocol specification MUST implement [RFC5811]. Note that additional TMLs might be specified in the future, and if a new TML defined in the future that meets the requirements listed here proves to be better, then the "MUST implement TML" may be redefined.
力プロトコル仕様をサポートする実装は、[RFC5811]を実装する必要があります。追加のTMLは将来指定される可能性があり、ここにリストされている要件を満たす将来定義された新しいTMLがより良いことが証明された場合、「TMLを実装する必要がある」が再定義される可能性があることに注意してください。
1. Reliability
1. 信頼性
Various ForCES messages will require varying degrees of reliable delivery via the TML. It is the TML's responsibility to provide these shades of reliability and describe how the different ForCES messages map to reliability.
さまざまな力メッセージには、TMLを介してさまざまな程度の信頼できる配信が必要です。これらの信頼性の色合いを提供し、さまざまなForcesメッセージが信頼性にどのようにマッピングされるかを説明することは、TMLの責任です。
The most common level of reliability is what we refer to as strict or robust reliability in which we mean no losses, corruption, or re-ordering of information being transported while ensuring message delivery in a timely fashion.
最も一般的なレベルの信頼性は、私たちがタイムリーにメッセージ配信を確保しながら、輸送される情報の損失、腐敗、または再注文を意味することを意味する厳格または堅牢な信頼性と呼ぶものです。
Payloads such as configuration from a CE and its response from an FE are mission critical and must be delivered in a robust reliable fashion. Thus, for information of this sort, the TML MUST either provide built-in protocol mechanisms or use a reliable transport protocol for achieving robust/strict reliability.
CEからの構成やFEからのその応答などのペイロードはミッションクリティカルであり、堅牢な信頼できる方法で配信する必要があります。したがって、この種の情報のために、TMLは組み込みプロトコルメカニズムを提供するか、堅牢/厳密な信頼性を達成するために信頼できる輸送プロトコルを使用する必要があります。
Some information or payloads, such as redirected packets or packet sampling, may not require robust reliability (can tolerate some degree of losses). For information of this sort, the TML could define to use a mechanism that is not strictly reliable (while conforming to other TML requirements such as congestion control).
リダイレクトされたパケットやパケットサンプリングなど、一部の情報またはペイロードには、堅牢な信頼性が必要ない場合があります（ある程度の損失に耐えることができます）。この種の情報については、TMLは、厳密に信頼できないメカニズムを使用するように定義できます（混雑制御などの他のTML要件に準拠しています）。
Some information or payloads, such as heartbeat packets, may prefer timeliness over reliable delivery. For information of this sort, the TML could define to use a mechanism that is not strictly reliable (while conforming to other TML requirements such as congestion control).
ハートビートパケットなどの一部の情報やペイロードは、信頼できる配信よりも適時性を好む場合があります。この種の情報については、TMLは、厳密に信頼できないメカニズムを使用するように定義できます（混雑制御などの他のTML要件に準拠しています）。
2. Security
2. 安全
TML provides security services to the ForCES PL. Because a ForCES PL is used to operate an NE, attacks designed to confuse, disable, or take information from a ForCES-based NE may be seen as a prime objective during a network attack.
TMLは、フォースPLにセキュリティサービスを提供します。力PLはNEを操作するために使用されるため、NEWベースのNEから情報を混乱させたり、無効にしたり、撮影するように設計された攻撃は、ネットワーク攻撃中に主要な目的と見なされる場合があります。
An attacker in a position to inject false messages into a PL stream can affect either the FE's treatment of the data path (for example, by falsifying control data reported as coming from the CE) or the CE itself (by modifying events or responses reported as coming from the FE). For this reason, CE and FE node authentication and TML message authentication are important.
誤ったメッセージをPLストリームに注入する立場にある攻撃者は、データパスのFEの処理（たとえば、CEから報告された制御データを偽造することにより）またはCE自体（CE自体（）（報告されたイベントまたは応答を変更すること）のいずれかに影響を与える可能性があります。Fe）から来る。このため、CEおよびFEノード認証とTMLメッセージ認証が重要です。
The PL messages may also contain information of value to an attacker, including information about the configuration of the network, encryption keys, and other sensitive control data, so care must be taken to confine their visibility to authorized users.
PLメッセージには、ネットワークの構成、暗号化キー、その他の機密制御データに関する情報など、攻撃者への価値の情報も含まれている場合があるため、認可されたユーザーに可視性を限定するように注意する必要があります。
* The TML MUST provide a mechanism to authenticate ForCES CEs and FEs, in order to prevent the participation of unauthorized CEs and unauthorized FEs in the control and data path processing of a ForCES NE.
* TMLは、力NEの制御およびデータパス処理に不正なCEと不正なFEの参加を防ぐために、力CEとFESを認証するメカニズムを提供する必要があります。
* The TML SHOULD provide a mechanism to ensure message authentication of PL data transferred from the CE to FE (and vice versa), in order to prevent the injection of incorrect data into PL messages.
* TMLは、PLメッセージへの誤ったデータの注入を防ぐために、CEからFEに転送されたPLデータのメッセージ認証を確保するためのメカニズムを提供する必要があります（およびその逆）。
* The TML SHOULD provide a mechanism to ensure the confidentiality of data transferred from the ForCES PL, in order to prevent disclosure of PL-level information transported via the TML.
* TMLは、TMLを介して輸送されたPLレベルの情報の開示を防ぐために、Force PLから転送されたデータの機密性を確保するメカニズムを提供する必要があります。
The TML SHOULD provide these services by employing TLS or IPsec.
TMLは、TLSまたはIPSECを使用してこれらのサービスを提供する必要があります。
3. Congestion control
3. 混雑制御
The transport congestion control scheme used by the TML needs to be defined. The congestion control mechanism defined by the TML MUST prevent transport congestive collapse [RFC2914] on either the FE or CE side.
TMLが使用する輸送渋滞制御スキームを定義する必要があります。TMLによって定義された輻輳制御メカニズムは、FeまたはCE側のいずれかでの輸送渋滞[RFC2914]を防ぐ必要があります。
4. Uni/multi/broadcast addressing/delivery, if any
4. uni/multi/broadcastアドレス指定/配信があれば
If there is any mapping between PL- and TML-level uni/multi/ broadcast addressing, it needs to be defined.
PL-およびTMLレベルのUNI/ Multi/ Broadcastアドレス指定の間にマッピングがある場合は、定義する必要があります。
5. HA decisions
5. HAの決定
It is expected that availability of transport links is the TML's responsibility. However, based upon its configuration, the PL may wish to participate in link failover schemes and therefore the TML MUST support this capability.
輸送リンクの可用性がTMLの責任であることが期待されています。ただし、その構成に基づいて、PLはリンクフェールオーバースキームに参加したい場合があるため、TMLはこの機能をサポートする必要があります。
Please refer to Section 8 for details.
詳細については、セクション8を参照してください。
6. Encapsulations used
6. 使用されているカプセル
Different types of TMLs will encapsulate the PL messages on different types of headers. The TML needs to specify the encapsulation used.
さまざまなタイプのTMLが、さまざまなタイプのヘッダーでPLメッセージをカプセル化します。TMLは、使用されるカプセル化を指定する必要があります。
7. Prioritization
7. 優先順位付け
It is expected that the TML will be able to handle up to 8 priority levels needed by the PL and will provide preferential treatment.
TMLは、PLが必要とする最大8つの優先度レベルを処理できることが予想され、優先的な治療を提供します。
While the TML needs to define how this is achieved, it should be noted that the requirement for supporting up to 8 priority levels does not mean that the underlying TML MUST be capable of providing up to 8 actual priority levels. In the event that the underlying TML layer does not have support for 8 priority levels, the supported priority levels should be divided between the available TML priority levels. For example, if the TML only supports 2 priority levels, 0-3 could go in one TML priority level, while 4-7 could go in the other.
TMLはこれがどのように達成されるかを定義する必要がありますが、最大8つの優先レベルをサポートするための要件は、基礎となるTMLが最大8つの実際の優先レベルを提供できることを意味しないことに注意する必要があります。基礎となるTML層が8つの優先レベルをサポートしていない場合、サポートされている優先度レベルは、利用可能なTML優先度レベル間で分割する必要があります。たとえば、TMLが2つの優先度レベルのみをサポートしている場合、0〜3は1つのTML優先度レベルで進むことができ、4〜7はもう1つの優先レベルで進むことができます。
The TML MUST NOT re-order config packets with the same priority.
TMLは、同じ優先度で構成パケットを再注文してはなりません。
8. Node Overload Prevention
8. ノード過負荷防止
The TML MUST define mechanisms it uses to help prevent node overload.
TMLは、ノードの過負荷を防ぐために使用するメカニズムを定義する必要があります。
Overload results in starvation of node compute cycles and/or bandwidth resources, which reduces the operational capacity of a ForCES NE. NE node overload could be deliberately instigated by a hostile node to attack a ForCES NE and create a denial of service (DoS). It could also be created by a variety of other reasons such as large control protocol updates (e.g., BGP flaps), which consequently cause a high frequency of CE to FE table updates, HA failovers, or component failures, which migrate an FE or CE load overwhelming the new CE or FE, etc. Although the environments under which SIP and ForCES operate are different, [RFC5390] provides a good guide to generic node requirements one needs to guard for.
過負荷の結果、ノード計算サイクルおよび/または帯域幅リソースの飢vが生じ、力NEの運用能力が低下します。NEノードの過負荷は、敵対的なノードによって意図的に扇動され、力を攻撃し、サービス拒否（DOS）を作成することができます。また、大規模なコントロールプロトコルの更新（BGPフラップなど）など、さまざまな理由で作成することもできます。これにより、CEからFEテーブルの更新、HAフェールオーバー、またはコンポーネントの障害が高くなり、FEまたはCEが移動します。SIPと力が動作する環境は異なっているが[RFC5390]、GENERIC NODE要件の適切なガイドを提供する必要がある環境が異なるが、新しいCEまたはFEなどを圧倒する負荷を負荷。
A ForCES node CPU may be overwhelmed because the incoming packet rate is higher than it can keep up with -- in such a case, a node's transport queues grow and transport congestion subsequently follows. A ForCES node CPU may also be adversely overloaded with very few packets, i.e., no transport congestion at all (e.g., a in a DoS attack against a table hashing algorithm that overflows the table and/or keeps the CPU busy so it does not process other tasks). The TML node overload solution specified MUST address both types of node overload scenarios.
力ノードCPUは、着信パケットレートが追いつくことができるよりも高いため、圧倒される可能性があります。そのような場合、ノードのトランスポートキューが増加し、その後輸送混雑が続きます。力ノードCPUは、非常に少ないパケットで逆に過負荷になっている可能性があります。つまり、輸送渋滞はまったくありません（たとえば、テーブルをオーバーフルしたり、CPUを忙しくしたりするテーブルハッシュアルゴリズムに対するDOS攻撃では、処理しないようにCPUを忙しくします。その他のタスク）。指定されたTMLノード過負荷ソリューションは、両方のタイプのノード過負荷シナリオに対処する必要があります。
It is expected that it should be possible to use a configuration reference point, such as the FEM or the CEM, to configure the TML.
TMLを構成するために、FEMやCEMなどの構成基準点を使用することができるはずです。
Some of the configured parameters may include:
構成されたパラメーターの一部には、次のものが含まれます。
o PL ID
o pl id
o Connection Type and associated data. For example, if a TML uses IP/TCP/UDP, then parameters such as TCP and UDP port and IP addresses need to be configured.
o 接続タイプと関連するデータ。たとえば、TMLがIP/TCP/UDPを使用する場合、TCPやUDPポート、IPアドレスなどのパラメーターを構成する必要があります。
o Number of transport connections
o 輸送接続の数
o Connection capability, such as bandwidth, etc.
o 帯域幅などの接続機能。
o Allowed/supported connection QoS policy (or congestion control policy)
o 許可/サポートされている接続QoSポリシー（または混雑制御ポリシー）
All PL PDUs start with a common header Section 6.1 followed by one or more TLVs Section 6.2, which may nest other TLVs Section 6.2.1. All fields are in network byte order.
すべてのPL PDUは、共通のヘッダーセクション6.1で始まり、その後に1つ以上のTLVSセクション6.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| rsvd | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[63:32] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[31:0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Common Header
図10：一般的なヘッダー
The message is 32-bit aligned.
メッセージは32ビットアライメントされています。
Version (4 bits): Version number. Current version is 1.
バージョン（4ビット）：バージョン番号。現在のバージョンは1です。
rsvd (4 bits): Unused at this point. A receiver should not interpret this field. Senders MUST set it to zero and receivers MUST ignore this field.
RSVD（4ビット）：この時点で使用されていません。受信機はこのフィールドを解釈してはなりません。送信者はそれをゼロに設定する必要があり、レシーバーはこのフィールドを無視する必要があります。
Message Type (8 bits): Commands are defined in Section 7.
メッセージタイプ（8ビット）：コマンドはセクション7で定義されています。
Length (16 bits): length of header + the rest of the message in DWORDS (4-byte increments).
長さ（16ビット）：ヘッダーの長さDWORDSの残りのメッセージ（4バイト増分）。
Source ID (32 bits): Dest ID (32 bits):
ソースID（32ビット）：Dest ID（32ビット）：
* Each of the source and destination IDs are 32-bit IDs that are unique NE-wide and that identify the termination points of a ForCES PL message.
* ソースおよび宛先IDのそれぞれは、32ビットIDであり、これは一意のNE-WIDEであり、Force PLメッセージの終端ポイントを識別します。
* IDs allow multi/broad/unicast addressing with the following approach:
* IDは、次のアプローチでマルチ/ブロード/ユニキャストアドレス指定を許可します。
a. A split address space is used to distinguish FEs from CEs. Even though in a large NE there are typically two or more orders of magnitude of more FEs than CEs, the address space is split uniformly for simplicity.
a. FESとCESを区別するために、スプリットアドレススペースが使用されます。大規模なNEでは、通常、CESよりも2桁以上のFESのFESが2桁以上ありますが、アドレス空間は簡単にするために均一に分割されます。
b. The address space allows up to 2^30 (over a billion) CEs and the same amount of FEs.
b. アドレススペースでは、最大2^30（10億を超える）CEと同じ量のFEが許可されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TS | sub-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ForCES ID Format
図11：ID形式を強制します
c. The 2 most significant bits called Type Switch (TS) are used to split the ID space as follows:
c. タイプスイッチ（TS）と呼ばれる2つの最も重要なビットは、次のようにIDスペースを分割するために使用されます。
TS Corresponding ID range Assignment
-- ---------------------- ----------
0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30)
0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30)
0b10 0x80000000 to 0xBFFFFFFF reserved
0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16)
0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved
0b11 0xFFFFFFFD all CEs broadcast
0b11 0xFFFFFFFE all FEs broadcast
0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast
Figure 12: Type Switch ID Space
図12：タイプスイッチIDスペース
* Multicast or broadcast IDs are used to group endpoints (such as CEs and FEs). As an example, one could group FEs in some functional group, by assigning a multicast ID. Likewise, subgroups of CEs that act, for instance, in a back-up mode may be assigned a multicast ID to hide them from the FE.
* マルチキャストまたはブロードキャストIDは、エンドポイント（CESやFESなど）をグループ化するために使用されます。例として、マルチキャストIDを割り当てることにより、一部の機能グループにFESをグループ化できます。同様に、たとえば、バックアップモードで作用するCESのサブグループには、FEからそれらを隠すためにマルチキャストIDを割り当てることができます。
+ Multicast IDs can be used for both source or destination IDs.
+ マルチキャストIDは、ソースIDまたは宛先IDの両方に使用できます。
+ Broadcast IDs can be used only for destination IDs.
+ ブロードキャストIDは、宛先IDにのみ使用できます。
* This document does not discuss how a particular multicast ID is associated to a given group though it could be done via configuration process. The list of IDs an FE owns or is part of are listed on the FE Object LFB.
* このドキュメントでは、特定のマルチキャストIDが特定のグループにどのように関連付けられているかについては説明しませんが、構成プロセスを介して実行できます。FEが所有または一部のIDSのリストは、FEオブジェクトLFBにリストされています。
Correlator (64 bits):
相関者（64ビット）：
This field is set by the CE to correlate ForCES Request messages with the corresponding Response messages from the FE. Essentially, it is a cookie. The correlator is handled transparently by the FE, i.e., for a particular Request message the FE MUST assign the same correlator value in the corresponding Response message. In the case where the message from the CE does not elicit a response, this field may not be useful.
このフィールドは、FEからの対応する応答メッセージと力要求メッセージを相関させるためにCEによって設定されます。本質的に、それはクッキーです。相関器はFEによって透過的に処理されます。つまり、特定の要求メッセージの場合、FEは対応する応答メッセージに同じ相関者値を割り当てる必要があります。CEからのメッセージが応答を引き出しない場合、このフィールドは役に立たない場合があります。
The correlator field could be used in many implementations in specific ways by the CE. For example, the CE could split the correlator into a 32-bit transactional identifier and 32-bit message sequence identifier. Another example is a 64-bit pointer to a context block. All such implementation-specific uses of the correlator are outside the scope of this specification.
相関器フィールドは、CEによって特定の方法で多くの実装で使用できます。たとえば、CEは相関器を32ビットトランザクション識別子と32ビットメッセージシーケンス識別子に分割することができます。別の例は、コンテキストブロックへの64ビットポインターです。相関器のそのような実装固有のすべてはすべて、この仕様の範囲外です。
It should be noted that the correlator is transmitted on the network as if it were a 64-bit unsigned integer with the leftmost or most significant octet (bits 63-56) transmitted first.
最初に送信された左端または最も重要なオクテット（ビット63-56）を備えた64ビットの非署名整数であるかのように、相関器がネットワーク上に送信されることに注意する必要があります。
Whenever the correlator field is not relevant, because no message is expected, the correlator field is set to 0.
メッセージが予想されないため、相関器フィールドが関連性がない場合はいつでも、相関器フィールドは0に設定されます。
Flags (32 bits): Identified so far:
フラグ（32ビット）：これまで識別：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | |
|ACK| Pri |Rsr |EM |A|TP | Reserved |
| | | vd. | |T| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Header Flags
図13：ヘッダーフラグ
- ACK: ACK indicator (2 bits) The ACK indicator flag is only used by the CE when sending a Config message (Section 7.6.1) or an HB message (Section 7.10) to indicate to the message receiver whether or not a response is required by the sender. Note that for all other messages than the Config message or the HB message this flag MUST be ignored.
- ACK：ACKインジケータ（2ビット）ACKインジケーターフラグは、CEでのみ構成メッセージ（セクション7.6.1）またはHBメッセージ（セクション7.10）を送信する場合にのみ使用され、メッセージ受信者に応答が必要かどうかを示します。送信者によって。構成メッセージまたはHBメッセージ以外のすべてのメッセージについては、このフラグを無視する必要があることに注意してください。
The flag values are defined as follows:
フラグの値は次のように定義されています。
'NoACK' (0b00) - to indicate that the message receiver MUST NOT send any Response message back to this message sender.
'noack'（0B00） - メッセージ受信者がこのメッセージ送信者に応答メッセージを送り返さないことを示すため。
'SuccessACK'(0b01) - to indicate that the message receiver MUST send a Response message back only when the message has been successfully processed by the receiver.
'Susterack'（0B01） - メッセージ受信者がレシーバーによって正常に処理された場合にのみ、メッセージ受信者が応答メッセージを送信する必要があることを示すため。
'FailureACK'(0b10) - to indicate that the message receiver MUST send a Response message back only when there is failure by the receiver in processing (executing) the message. In other words, if the message can be processed successfully, the sender will not expect any response from the receiver.
'failureack'（0B10） - メッセージの受信者がメッセージの処理（実行）に障害がある場合にのみ、メッセージ受信者が応答メッセージを送信する必要があることを示すため。言い換えれば、メッセージを正常に処理できる場合、送信者は受信者からの応答を期待しません。
'AlwaysACK' (0b11) - to indicate that the message receiver MUST send a Response message.
「Alwaysack」（0B11） - メッセージ受信者が応答メッセージを送信する必要があることを示すため。
Note that in above definitions, the term success implies a complete execution without any failure of the message. Anything else than a complete successful execution is defined as a failure for the message processing. As a result, for the execution modes (defined in Section 4.3.1.1) like execute-all-or-none, execute-until-failure, and continue-execute-on-failure, if any single operation among several operations in the same message fails, it will be treated as a failure and result in a response if the ACK indicator has been set to 'FailureACK' or 'AlwaysACK'.
上記の定義では、成功という用語は、メッセージを失敗させることなく完全な実行を意味することに注意してください。完全に成功した実行以外は、メッセージ処理の失敗として定義されます。その結果、実行モード（セクション4.3.1.1で定義されています）の場合、実行モード、オールオアノン、実行、実行途中の実行、および継続的な操作の場合、同じ操作の間で単一の操作がある場合は、メッセージが失敗し、障害として扱われ、ACKインジケーターが「FailureAck」または「AlwaysAck」に設定されている場合、応答が発生します。
Also note that, other than in Config and HB messages, requirements for responses of messages are all given in a default way rather than by ACK flags. The default requirements of these messages and the expected responses are summarized below. Detailed descriptions can be found in the individual message definitions:
また、ConfigおよびHBメッセージ以外に、メッセージの応答の要件はすべてACKフラグではなくデフォルトの方法で与えられることに注意してください。これらのメッセージのデフォルト要件と予想される応答を以下に要約します。詳細な説明は、個々のメッセージ定義に記載されています。
+ Association Setup message always expects a response.
+ Associationセットアップメッセージは常に応答を期待します。
+ Association Teardown Message, and Packet Redirect message, never expect responses.
+ 協会の分解メッセージ、およびパケットリダイレクトメッセージは、応答を期待することはありません。
+ Query message always expects a response.
+ クエリメッセージは常に応答を期待します。
+ Response message never expects further responses.
+ 応答メッセージは、さらなる応答を決して期待しません。
- Pri: Priority (3 bits)
- PRI：優先度（3ビット）
ForCES protocol defines 8 different levels of priority (0-7). The priority level can be used to distinguish between different protocol message types as well as between the same message type. The higher the priority value, the more important the PDU is. For example, the REDIRECT packet message could have different priorities to distinguish between routing protocol packets and ARP packets being redirected from FE to CE. The normal priority level is 1. The different priorities imply messages could be re-ordered; however, re-ordering is undesirable when it comes to a set of messages within a transaction and caution should be exercised to avoid this.
力プロトコルは、8つの異なるレベルの優先度（0-7）を定義します。優先度レベルを使用して、異なるプロトコルメッセージタイプと同じメッセージタイプを区別できます。優先度の値が高いほど、PDUはより重要です。たとえば、リダイレクトパケットメッセージには、ルーティングプロトコルパケットとFからCEまでリダイレクトされるARPパケットを区別するための優先順位が異なる場合があります。通常の優先度レベルは1です。異なる優先順位は、メッセージを再注文できることを意味します。ただし、トランザクション内の一連のメッセージに関しては、再注文は望ましくありません。これを避けるために注意する必要があります。
- EM: Execution Mode (2 bits)
- EM：実行モード（2ビット）
There are 3 execution modes; refer to Section 4.3.1.1 for details.
3つの実行モードがあります。詳細については、セクション4.3.1.1を参照してください。
Reserved..................... (0b00)
`execute-all-or-none` ....... (0b01)
`execute-until-failure` ..... (0b10)
`continue-execute-on-failure` (0b11)
`Continue-Execute-on-failure`（0B11）
- AT: Atomic Transaction (1 bit)
- AT：アトミックトランザクション（1ビット）
This flag indicates if the message is a stand-alone message or one of multiple messages that belong to 2PC transaction operations. See Section 4.3.1.2.2 for details.
このフラグは、メッセージがスタンドアロンメッセージであるか、2PCトランザクション操作に属する複数のメッセージの1つであるかを示します。詳細については、セクション4.3.1.2.2を参照してください。
Stand-alone message ......... (0b0)
2PC transaction message ..... (0b1)
- TP: Transaction Phase (2 bits)
- TP：トランザクションフェーズ（2ビット）
A message from the CE to the FE within a transaction could be indicative of the different phases the transaction is in. Refer to Section 4.3.1.2.2 for details.
トランザクション内のCEからFEへのメッセージは、トランザクションがあるさまざまなフェーズを示す可能性があります。詳細については、セクション4.3.1.2.2を参照してください。
SOT (start of transaction) ..... (0b00)
MOT (middle of transaction) .... (0b01)
EOT (end of transaction) ........(0b10)
ABT (abort) .....................(0b11)
TLVs are extensively used by the ForCES protocol. TLVs have some very nice properties that make them a good candidate for encoding the XML definitions of the LFB class model. These are:
TLVは、フォースプロトコルによって広く使用されています。TLVには、LFBクラスモデルのXML定義をエンコードするための優れた候補になる非常に優れた特性があります。これらは：
o Providing for binary type-value encoding that is close to the XML string tag-value scheme.
o XML String Tag-Valueスキームに近いバイナリタイプ値エンコードを提供します。
o Allowing for fast generalized binary-parsing functions.
o 高速な一般化バイナリパルシング関数を可能にします。
o Allowing for forward and backward tag compatibility. This is equivalent to the XML approach, i.e., old applications can ignore new TLVs and newer applications can ignore older TLVs.
o 順方向および後方タグの互換性を可能にします。これはXMLアプローチに相当します。つまり、古いアプリケーションは新しいTLVを無視でき、新しいアプリケーションは古い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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Essentially the TLV Data) |
~ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: TLV Representation
図14：TLV表現
TLV Type (16):
TLVタイプ（16）：
The TLV type field is 2 octets, and semantically indicates the type of data encapsulated within the TLV.
TLVタイプフィールドは2オクテットであり、TLV内でカプセル化されたデータのタイプを意味的に示します。
TLV Length (16):
TLV長さ（16）：
The TLV length field is 2 octets, and includes the length of the TLV type (2 octets), TLV Length (2 octets), and the length of the TLV data found in the value field, in octets. Note that this length is the actual length of the value, before any padding for alignment is added.
TLVの長さフィールドは2オクテットで、TLVタイプ（2オクテット）の長さ（2オクテット）、TLV長（2オクテット）、および値フィールドにあるTLVデータの長さが含まれます。この長さは、アライメントのパディングが追加される前の値の実際の長さであることに注意してください。
TLV Value (variable):
TLV値（変数）：
The TLV value field carries the data. For extensibility, the TLV value may in fact be a TLV. Padding is required when the length is not a multiple of 32 bits, and is the minimum number of octets required to bring the TLV to a multiple of 32 bits. The length of the value before padding is indicated by the TLV Length field.
TLV値フィールドにはデータが含まれます。拡張性のために、TLV値は実際にはTLVである可能性があります。長さが32ビットの倍数ではなく、TLVを32ビットの倍数にするために必要なオクテットの最小数である場合、パディングが必要です。パディング前の値の長さは、TLV長さフィールドで示されます。
Note: The value field could be empty, which implies the minimal length a TLV could be is 4 (length of "T" field and length of "L" field).
注：値フィールドは空になる可能性があります。これは、TLVが4（「T」フィールドの長さと「L」フィールドの長さ）である可能性があることを意味します。
TLV values can be other TLVs. This provides the benefits of protocol flexibility (being able to add new extensions by introducing new TLVs when needed). The nesting feature also allows for a conceptual optimization with the XML LFB definitions to binary PL representation (represented by nested TLVs).
TLV値は他のTLVにすることができます。これにより、プロトコルの柔軟性の利点が得られます（必要に応じて新しいTLVを導入することで新しい拡張機能を追加できます）。ネスト機能により、XML LFB定義がバイナリPL表現（ネストされたTLVで表される）を使用した概念的な最適化も可能になります。
There are two global name scopes for the "Type" in the TLV. The first name scope is for OPER-TLVs and is defined in A.4 whereas the second name scope is outside OPER-TLVs and is defined in section A.2.
TLVには「タイプ」には2つのグローバル名スコープがあります。最初の名前の範囲はOper-TLVのものであり、A.4で定義されていますが、2番目の名前の範囲はOper-TLVの外側であり、セクションA.2で定義されています。
The ILV is a slight variation of the TLV. This sets the type ("T") to be a 32-bit local index that refers to a ForCES component ID (refer to Section 6.4.1).
ILVは、TLVのわずかなバリエーションです。これにより、タイプ（ "T"）が、力コンポーネントIDを指す32ビットローカルインデックスに設定します（セクション6.4.1を参照）。
The ILV length field is a 4-octet integer, and includes the length of the ILV type (4 octets), ILV Length (4 octets), and the length of the ILV data found in the value field, in octets. Note that, as in the case of the TLV, this length is the actual length of the value, before any padding for alignment is added.
ILVの長さフィールドは4-OCTET整数であり、ILVタイプ（4オクテット）の長さ（4オクテット）、ILV長（4オクテット）、および値フィールドで見つかったILVデータの長さが含まれます。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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ILV Representation
図15：ILV表現
It should be noted that the "I" values are of local scope and are defined by the data declarations from the LFB definition. Refer to Section 7.1.8 for discussions on usage of ILVs.
「i」値はローカル範囲のものであり、LFB定義からのデータ宣言によって定義されることに注意する必要があります。ILVの使用に関する議論については、セクション7.1.8を参照してください。
In this section, we review a few encapsulation concepts that are used by the ForCES protocol for its operations.
このセクションでは、操作のためにフォースプロトコルによって使用されるいくつかのカプセル化概念をレビューします。
We briefly re-introduce two concepts, paths, and keys, from the ForCES model [RFC5812] in order to provide context. The reader is referred to [RFC5812] for a lot of the finer details.
コンテキストを提供するために、力モデル[RFC5812]から2つの概念、パス、およびキーを簡単に再導入します。読者は、多くのより細かい詳細について[RFC5812]に紹介されます。
For readability reasons, we introduce the encapsulation schemes that are used to carry content in a protocol message, namely, FULLDATA-TLV, SPARSEDATA-TLV, and RESULT-TLV.
読みやすさの理由から、プロトコルメッセージ、つまりfulldata-tlv、Sparsedata-TLV、およびresult-tlvのコンテンツを運ぶために使用されるカプセル化スキームを導入します。
The ForCES model [RFC5812] defines an XML-based language that allows for a formal definition of LFBs. This is similar to the relationship between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB and ASN.1 being analogous to the XML model language). Any entity that the CE configures on an FE MUST be formally defined in an LFB. These entities could be scalars (e.g., a 32-bit IPv4 address) or vectors (such as a nexthop table). Each entity within the LFB is given a numeric 32-bit identifier known as a "component id". This scheme allows the component to be "addressed" in a protocol construct.
Force Model [RFC5812]は、LFBの正式な定義を可能にするXMLベースの言語を定義します。これは、ASN.1とSNMP MIBの定義の関係に似ています（MIBはLFBとASN.1に類似していることはXMLモデル言語に類似しています）。CEがFEで構成するエンティティは、LFBで正式に定義する必要があります。これらのエンティティは、スカラー（32ビットIPv4アドレスなど）またはベクトル（Nexthopテーブルなど）です。LFB内の各エンティティには、「コンポーネントID」として知られる数値32ビット識別子が与えられます。このスキームにより、コンポーネントをプロトコルコンストラクトで「アドレス指定」することができます。
These addressable entities could be hierarchical (e.g., a table column or a cell within a table row). In order to address hierarchical data, the concept of a path is introduced by the model [RFC5812]. A path is a series of 32-bit component IDs that are typically presented in a dot-notation (e.g., 1.2.3.4). Section 7 formally defines how paths are used to reference data that is being encapsulated within a protocol message.
これらのアドレス指定可能なエンティティは、階層的である可能性があります（たとえば、テーブル列またはテーブル行内のセル）。階層データに対処するために、パスの概念はモデル[RFC5812]によって導入されます。パスは、通常、ドットノートで表示される32ビットコンポーネントIDのシリーズです（例：1.2.3.4）。セクション7では、プロトコルメッセージ内でカプセル化されているデータを参照するためにパスを使用する方法を正式に定義します。
The ForCES model [RFC5812] defines two ways to address table rows. The standard/common mechanism is to allow table rows to be referenced by a 32-bit index. The secondary mechanism is via keys that allow for content addressing. An example key is a multi-field content key that uses the IP address and prefix length to uniquely reference an IPv4 routing table row. In essence, while the common scheme to address a table row is via its table index, a table row's path could be derived from a key. The KEYINFO-TLV (Section 7) is used to carry the data that is used to do the lookup.
力モデル[RFC5812]は、テーブルの行に対処する2つの方法を定義します。標準/共通のメカニズムは、32ビットインデックスで表の行を参照できるようにすることです。二次メカニズムは、コンテンツアドレス指定を可能にするキーを介して行われます。例キーは、IPアドレスとプレフィックスの長さを使用してIPv4ルーティングテーブル行を一意に参照するマルチフィールドコンテンツキーです。本質的に、テーブルの行に対処する一般的なスキームはそのテーブルインデックスを介して行われますが、テーブル行のパスはキーから導き出されます。KeyInfo-TLV（セクション7）は、ルックアップを行うために使用されるデータを運ぶために使用されます。
Data from or to the FE is carried in two types of TLVs: FULLDATA-TLV and SPARSEDATA-TLV. Responses to operations executed by the FE are carried in RESULT-TLVs.
FEからのデータは、Fulldata-TLVとSparsedata-TLVの2種類のTLVで運ばれます。FEによって実行された操作への応答は、結果TLVで運ばれます。
In FULLDATA-TLV, the data is encoded in such a way that a receiver of such data, by virtue of being armed with knowledge of the path and the LFB definition, can infer or correlate the TLV "Value" contents. This is essentially an optimization that helps reduce the amount of description required for the transported data in the protocol grammar. Refer to Appendix C for an example of FULLDATA-TLVs.
Fulldata-TLVでは、データは、パスとLFBの定義の知識で武装しているため、そのようなデータの受信者がTLVの「値」の内容を推測または相関させるようにエンコードされます。これは、基本的に、プロトコル文法で輸送されたデータに必要な説明の量を減らすのに役立つ最適化です。fulldata-tlvsの例については、付録Cを参照してください。
A number of operations in ForCES will need to reference optional data within larger structures. The SPARSEDATA-TLV encoding is provided to make it easier to encapsulate optionally appearing data components. Refer to Appendix C for an example of SPARSEDATA-TLV.
大規模な構造内のオプションデータを参照する必要があります。Sparsedata-TLVエンコードは、オプションで表示されるデータコンポーネントをオプションでカプセル化しやすくするために提供されます。Sparsedata-TLVの例については、付録Cを参照してください。
RESULT-TLVs carry responses back from the FE based on a config issued by the CE. Refer to Appendix C for examples of RESULT-TLVs and Section 7.1.7 for layout.
Result-TLVは、CEによって発行された構成に基づいて、FEから応答を返します。結果TLVの例については、レイアウトについてはセクション7.1.7については、付録Cを参照してください。
Section 6.4.1 and Section 6.4.2 discuss how to target an entity within an LFB. However, the addressing mechanism used requires that an LFB type and instance are selected first. The LFB selector is used to select an LFB type and instance being targeted. Section 7 goes into more details; for our purpose, we illustrate this concept using Figure 16 below. More examples of layouts can be found reading further into the text (example: Figure 22).
セクション6.4.1およびセクション6.4.2は、LFB内のエンティティをターゲットにする方法について説明します。ただし、使用されたアドレス指定メカニズムでは、LFBタイプとインスタンスが最初に選択される必要があります。LFBセレクターは、ターゲットを絞っているLFBタイプとインスタンスを選択するために使用されます。セクション7は詳細について説明します。私たちの目的のために、以下の図16を使用してこの概念を説明します。レイアウトのより多くの例が、テキストをさらに読んで見つけることができます（例：図22）。
main hdr (Message type: example "config")
|
|
|
+- T = LFBselect
|
+-- LFBCLASSID (unique per LFB defined)
|
|
+-- LFBInstance (runtime configuration)
|
+-- T = An operation TLV describes what we do to an entity
| //Refer to the OPER-TLV values enumerated below
| //the TLVs that can be used for operations
|
|
+--+-- one or more path encodings to target an entity
| // Refer to the discussion on keys and paths
|
|
+-- The associated data, if any, for the entity
// Refer to discussion on FULL/SPARSE DATA TLVs
Figure 16: Entity Addressing
図16：エンティティアドレス指定
A protocol layer PDU consists of a common header (defined in Section 6.1 ) and a message body. The common header is followed by a message-type-specific message body. Each message body is formed from one or more top-level TLVs. A top-level TLV may contain one or more sub-TLVs; these sub-TLVs are described in this document as OPER-TLVs, because they describe an operation to be done.
プロトコル層PDUは、共通のヘッダー（セクション6.1で定義）とメッセージ本文で構成されています。共通のヘッダーの後に、メッセージタイプ固有のメッセージ本文が続きます。各メッセージ本文は、1つ以上のトップレベルTLVから形成されます。トップレベルのTLVには、1つ以上のサブTLVが含まれる場合があります。これらのサブTLVは、このドキュメントでOper-TLVとして説明されています。これは、実行する操作を説明するためです。
+-------------+---------------+---------------------+---------------+
| Message | Top-Level TLV | OPER-TLV(s) | Reference |
| Name | | | |
+-------------+---------------+---------------------+---------------+
| Association | (LFBselect)* | REPORT | Section 7.5.1 |
| Setup | | | |
| Association | ASRresult-TLV | none | Section 7.5.2 |
| Setup | | | |
| Response | | | |
| Association | ASTreason-TLV | none | Section 7.5.3 |
| Teardown | | | |
| Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 |
| | | DEL | COMMIT | | |
| | | TRCOMP)+ | |
| Config | (LFBselect)+ | (SET-RESPONSE | | Section 7.6.2 |
| Response | | SET-PROP-RESPONSE | | |
| | | DEL-RESPONSE | | |
| | | COMMIT-RESPONSE)+ | |
| Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 |
| Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 |
| Response | | GET-PROP-RESPONSE)+ | |
| Event | LFBselect | REPORT | Section 7.8 |
| Notifi- | | | |
| cation | | | |
| Packet | REDIRECT-TLV | none | Section 7.9 |
| Redirect | | | |
| Heartbeat | none | none | Section 7.10 |
+-------------+---------------+---------------------+---------------+
Table 1
表1
The different messages are illustrated in Table 1. The different message type numerical values are defined in Appendix A.1. All the TLV values are defined in Appendix A.2.
さまざまなメッセージを表1に示します。異なるメッセージタイプ数値値を付録A.1に定義します。すべてのTLV値は、付録A.2で定義されています。
An LFBselect TLV (refer to Section 7.1.5) contains the LFB Classid and LFB instance being referenced as well as the OPER-TLV(s) being applied to that reference.
LFBSELECT TLV（セクション7.1.5を参照）には、参照されているLFB ClassIDおよびLFBインスタンス、およびその参照に適用されるOper-TLVが含まれています。
Each type of OPER-TLV is constrained as to how it describes the paths and selectors of interest. The following BNF describes the basic structure of an OPER-TLV and Table 2 gives the details for each type.
Oper-TLVの各タイプは、関心のあるパスとセレクターをどのように説明するかについて制約されています。次のBNFは、Oper-TLVの基本構造を説明し、表2に各タイプの詳細を示します。
OPER-TLV := 1*PATH-DATA-TLV
PATH-DATA-TLV := PATH [DATA]
PATH := flags IDcount IDs [SELECTOR]
SELECTOR := KEYINFO-TLV
DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV /
1*PATH-DATA-TLV
KEYINFO-TLV := KeyID FULLDATA-TLV
FULLDATA-TLV := encoded data component which may nest
further FULLDATA-TLVs
SPARSEDATA-TLV := encoded data that may have optionally
appearing components
RESULT-TLV := Holds result code and optional FULLDATA-TLV
Figure 17: BNF of OPER-TLV
図17：Oper-TLVのBNF
o PATH-DATA-TLV identifies the exact component targeted and may have zero or more paths associated with it. The last PATH-DATA-TLV in the case of nesting of paths via the DATA construct in the case of SET, SET-PROP requests, and GET-RESPONSE/GET-PROP-RESPONSE is terminated by encoded data or response in the form of either FULLDATA-TLV or SPARSEDATA-TLV or RESULT-TLV.
o Path-Data-TLVは、ターゲットを絞った正確なコンポーネントを識別し、それに関連するゼロ以上のパスを持っている可能性があります。セット、セットプロップリクエスト、およびget-response/get-prop-responseの場合、データコンストラクトを介したパスのネストの場合の最後のパスdata-tlvは、エンコードされたデータまたは応答によって終了します。fulldata-tlvまたはsparsedata-tlvまたはresult-tlvのいずれか。
o PATH provides the path to the data being referenced.
o パスは、参照されているデータへのパスを提供します。
* flags (16 bits) are used to further refine the operation to be applied on the path. More on these later.
* フラグ（16ビット）を使用して、パスに適用する操作をさらに改良します。これらについては後で詳しく説明します。
* IDcount (16 bits): count of 32-bit IDs
* idcount（16ビット）：32ビットIDのカウント
* IDs: zero or more 32-bit IDs (whose count is given by IDcount) defining the main path. Depending on the flags, IDs could be field IDs only or a mix of field and dynamic IDs. Zero is used for the special case of using the entirety of the containing context as the result of the path.
* IDS：メインパスを定義するゼロ以上の32ビットID（IDCountによってカウントが与えられます）。フラグによっては、IDはフィールドIDのみまたはフィールドと動的IDの組み合わせである可能性があります。ゼロは、パスの結果としてコンテキスト全体の全体を使用する特別なケースに使用されます。
o SELECTOR is an optional construct that further defines the PATH. Currently, the only defined selector is the KEYINFO-TLV, used for selecting an array entry by the value of a key field. The presence of a SELECTOR is correct only when the flags also indicate its presence.
o セレクターは、パスをさらに定義するオプションの構成要素です。現在、定義された唯一のセレクターは、キーフィールドの値による配列エントリの選択に使用されるKeyInfo-TLVです。セレクターの存在は、フラグがその存在を示している場合にのみ正しいです。
o A KEYINFO-TLV contains information used in content keying.
o KeyINFO-TLVには、コンテンツキーイングで使用される情報が含まれています。
* A 32-bit KeyID is used in a KEYINFO-TLV. It indicates which key for the current array is being used as the content key for array entry selection.
* 32ビットのKeyIDは、KeyInfo-TLVで使用されます。これは、現在の配列のキーが、配列エントリの選択のコンテンツキーとして使用されていることを示します。
* The key's data is the data to look for in the array, in the fields identified by the key field. The information is encoded according to the rules for the contents of a FULLDATA-TLV, and represents the field or fields that make up the key identified by the KeyID.
* キーのデータは、キーフィールドによって識別されたフィールドで、配列で探すデータです。情報は、fulldata-tlvの内容のルールに従ってエンコードされ、KeyIDによって識別されたキーを構成するフィールドまたはフィールドを表します。
o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV, or 1 or more further PATH-DATA selections. FULLDATA-TLV and SPARSEDATA-TLV are only allowed on SET or SET-PROP requests, or on responses that return content information (GET-RESPONSE, for example). PATH-DATA may be included to extend the path on any request.
o データには、fulldata-tlv、Sparsedata-TLV、結果TLV、または1つ以上のパスデータ選択が含まれる場合があります。Fulldata-TLVおよびSparseData-TLVは、セットまたはセットプロップリクエスト、またはコンテンツ情報を返す応答（たとえば、get-response）でのみ許可されます。どのリクエストでパスを拡張するために、Path-Dataを含めることができます。
* Note: Nested PATH-DATA-TLVs are supported as an efficiency measure to permit common subexpression extraction.
* 注：ネストされたパスDATA-TLVは、共通のサブエクスペッション抽出を可能にする効率測定としてサポートされています。
* FULLDATA-TLV and SPARSEDATA-TLV contain "the data" whose path has been selected by the PATH. Refer to Section 7.1 for details.
* fulldata-tlvとSparsedata-tlvには、パスによってパスが選択された「データ」が含まれています。詳細については、セクション7.1を参照してください。
* The following table summarizes the applicability and restrictions of the FULL/SPARSEDATA-TLVs and the RESULT-TLV to the OPER-TLVs.
* 次の表は、完全/Sparsedata-TLVの適用可能性と制限と、Oper-TLVへの結果TLVをまとめたものです。
+-------------------+-------------------------------+---------------+
| OPER-TLV | DATA TLV | RESULT-TLV |
+-------------------+-------------------------------+---------------+
| SET | | none |
| SET-PROP | (FULLDATA-TLV | | none |
| | SPARSEDATA-TLV)+ | |
| SET-RESPONSE | none | (RESULT-TLV)+ |
| SET-PROP-RESPONSE | none | (RESULT-TLV)+ |
| DEL | | none |
| DEL-RESPONSE | none | (RESULT-TLV)+ |
| GET | none | none |
| GET-PROP | none | none |
| GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| REPORT | (FULLDATA-TLV)+ | none |
| COMMIT | none | none |
| COMMIT-RESPONSE | none | (RESULT-TLV)+ |
| TRCOMP | none | none |
+-------------------+-------------------------------+---------------+
Table 2
表2
o RESULT-TLV contains the indication of whether the individual SET or SET-PROP succeeded. RESULT-TLV is included on the assumption that individual parts of a SET request can succeed or fail separately.
o result-tlvには、個々のセットまたはセットプロップが成功したかどうかの表示が含まれています。Result-TLVは、設定された要求の個々の部分が個別に成功または失敗する可能性があるという仮定に含まれています。
In summary, this approach has the following characteristics:
要約すると、このアプローチには次の特性があります。
o There can be one or more LFB class ID and instance ID combinations targeted in a message (batch).
o メッセージ（バッチ）でターゲットにされた1つ以上のLFBクラスIDとインスタンスIDの組み合わせがあります。
o There can one or more operations on an addressed LFB class ID/ instance ID combination (batch).
o アドレス指定されたLFBクラスID/インスタンスIDの組み合わせ（バッチ）に1つ以上の操作ができます。
o There can be one or more path targets per operation (batch).
o 操作ごとに1つ以上のパスターゲット（バッチ）があります。
o Paths may have zero or more data values associated (flexibility and operation specific).
o パスにはゼロ以上のデータ値が関連付けられている場合があります（柔軟性と操作固有）。
It should be noted that the above is optimized for the case of a single LFB class ID and instance ID targeting. To target multiple instances within the same class, multiple LFBselects are needed.
上記は、単一のLFBクラスIDおよびインスタンスIDターゲティングの場合に最適化されていることに注意する必要があります。同じクラス内の複数のインスタンスをターゲットにするには、複数のLFBSelectが必要です。
Section 6.4.3 discusses the two types of DATA encodings (FULLDATA-TLV and SPARSEDATA-TLV) and the justifications for their existence. In this section, we explain how they are encoded.
セクション6.4.3では、2種類のデータエンコーディング（Fulldata-TLVとSparsedata-TLV）とその存在の正当化について説明します。このセクションでは、それらがエンコードされる方法を説明します。
The scheme for encoding data used in this document adheres to the following rules:
このドキュメントで使用されているデータをエンコードするスキームは、次のルールを順守しています。
o The Value ("V" of TLV) of FULLDATA-TLV will contain the data being transported. This data will be as was described in the LFB definition.
o Fulldata-TLVの値（TLVの「V」）には、輸送されるデータが含まれます。このデータは、LFB定義で説明されているとおりです。
o Variable-sized data within a FULLDATA-TLV will be encapsulated inside another FULLDATA-TLV inside the V of the outer TLV. For an example of such a setup, refer to Appendices C and D.
o Fulldata-TLV内の可変サイズのデータは、外側TLVのV内部の別のfulldata-TLV内にカプセル化されます。このようなセットアップの例については、付録CおよびDを参照してください。
o In the case of FULLDATA-TLVs:
o fulldata-tlvsの場合：
* When a table is referred to in the PATH (IDs) of a PATH-DATA-TLV, then the FULLDATA-TLV's "V" will contain that table's row content prefixed by its 32-bit index/subscript. On the other hand, the PATH may contain an index pointing to a row in table; in such a case, the FULLDATA-TLV's "V" will only contain the content with the index in order to avoid ambiguity.
* Path-Data-TLVのパス（IDS）でテーブルが参照されると、Fulldata-TLVの「V」には、32ビットインデックス/サブスクリプトが付いたテーブルの行コンテンツが含まれます。一方、パスには、テーブル内の行を指すインデックスが含まれている場合があります。そのような場合、Fulldata-TLVの「V」には、あいまいさを避けるために、インデックスのコンテンツのみが含まれます。
Only bit 0, the SELECTOR Bit, is currently used in the path flags as illustrated in Figure 18.
現在、図18に示すように、パスフラグでビット0のみがパスフラグで使用されています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
|S| Reserved |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Path Flags
図18：パスフラグ
The semantics of the flag are defined as follows:
フラグのセマンティクスは次のように定義されています。
o SELECTOR Bit: F_SELKEY(set to 1) indicates that a KEY Selector is present following this path information, and should be considered in evaluating the path content.
o セレクタービット：f_selkey（1に設定）は、このパス情報に従ってキーセレクターが存在し、パスコンテンツの評価で考慮する必要があることを示します。
Global flags, such as the execution mode and the atomicity indicators defined in the header, apply to all operations in a message. Global flags provide semantics that are orthogonal to those provided by the operational flags, such as the flags defined in path-data. The scope of operational flags is restricted to the operation.
ヘッダーで定義されている実行モードやAtomicityインジケーターなどのグローバルフラグは、メッセージ内のすべての操作に適用されます。グローバルフラグは、Path-Dataで定義されているフラグなど、運用フラグによって提供されるものに直交するセマンティクスを提供します。運用フラグの範囲は操作に制限されています。
The KEYINFO-TLV describes the KEY as well as associated KEY data. KEYs, used for content searches, are restricted and described in the LFB definition.
KeyINFO-TLVは、キーおよび関連するキーデータを説明します。コンテンツ検索に使用されるキーは制限されており、LFB定義で説明されています。
The LFBselect TLV is an instance of a TLV as defined in Section 6.2. The definition is as follows:
LFBSELECT TLVは、セクション6.2で定義されている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 = LFBselect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER-TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER-TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: PL PDU Layout
図19：PL PDUレイアウト
Type:
タイプ：
The type of the TLV is "LFBselect"
TLVのタイプは「lfbselect」です
Length:
長さ：
Length of the TLV including the T and L fields, in octets.
TLVの長さは、TおよびLフィールドを含むオクテットにあります。
LFB Class ID:
LFBクラスID：
This field uniquely recognizes the LFB class/type.
このフィールドは、LFBクラス/タイプを一意に認識します。
LFB Instance ID:
LFBインスタンスID：
This field uniquely identifies the LFB instance.
このフィールドは、LFBインスタンスを一意に識別します。
OPER-TLV:
Oper-TLV：
It describes an operation nested in the LFBselect TLV. Note that usually there SHOULD be at least one OPER-TLV present for an LFB select TLV.
LFBSelect TLVにネストされた操作について説明しています。通常、LFB Select TLVには少なくとも1つのオペトルフが存在するはずであることに注意してください。
The OPER-TLV is a place holder in the grammar for TLVs that define operations. The different types are defined in Table 3, below.
Oper-TLVは、運用を定義するTLVの文法の所有者です。さまざまなタイプを以下の表3に定義します。
+-------------------+--------+--------------------------------------+
| OPER-TLV | TLV | Comments |
| | "Type" | |
+-------------------+--------+--------------------------------------+
| SET | 0x0001 | From CE to FE. Used to create or |
| | | add or update components |
| SET-PROP | 0x0002 | From CE to FE. Used to create or |
| | | add or update component properties |
| SET-RESPONSE | 0x0003 | From FE to CE. Used to carry |
| | | response of a SET |
| SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry |
| | | response of a SET-PROP |
| DEL | 0x0005 | From CE to FE. Used to delete or |
| | | remove an component |
| DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry |
| | | response of a DEL |
| GET | 0x0007 | From CE to FE. Used to retrieve an |
| | | component |
| GET-PROP | 0x0008 | From CE to FE. Used to retrieve an |
| | | component property |
| GET-RESPONSE | 0x0009 | From FE to CE. Used to carry |
| | | response of a GET |
| GET-PROP-RESPONSE | 0x000A | From FE to CE. Used to carry |
| | | response of a GET-PROP |
| REPORT | 0x000B | From FE to CE. Used to carry an |
| | | asynchronous event |
| COMMIT | 0x000C | From CE to FE. Used to issue a |
| | | commit in a 2PC transaction |
| COMMIT-RESPONSE | 0x000D | From FE to CE. Used to confirm a |
| | | commit in a 2PC transaction |
| TRCOMP | 0x000E | From CE to FE. Used to indicate |
| | | NE-wide success of 2PC transaction |
+-------------------+--------+--------------------------------------+
Table 3
表3
Different messages use OPER-TLV and define how they are used (refer to Table 1 and Table 2).
さまざまなメッセージがOper-TLVを使用し、それらの使用方法を定義します（表1と表2を参照）。
SET, SET-PROP, and GET/GET-PROP requests are issued by the CE and do not carry RESULT-TLVs. On the other hand, SET-RESPONSE, SET-PROP-RESPONSE, and GET-RESPONSE/GET-PROP-RESPONSE carry RESULT-TLVs.
セット、セットプロップ、およびGet/Get-PropリクエストはCEによって発行され、結果TLVを携帯していません。一方、セットレスポンス、セットプロップ応答、およびget-response/get-prop-responseキャリー結果tlv。
A GET-RESPONSE in response to a successful GET will have FULLDATA-TLVs added to the leaf paths to carry the requested data. For GET operations that fail, instead of the FULLDATA-TLV there will be a RESULT-TLV.
成功したGETに応じてゲット応答すると、葉のパスにfulldata-tlvが追加され、要求されたデータが掲載されます。失敗する操作を取得するには、fulldata-tlvの代わりに結果tlvがあります。
For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA-TLV or SPARSEDATA-TLV in the original request will be replaced with a RESULT-TLV in the response. If the request set the FailureACK flag, then only those items that failed will appear in the response. If the request was for AlwaysACK, then all components of the request will appear in the response with RESULT-TLVs.
セットレスポンス/セットプロップ応答の場合、元のリクエストの各fulldata-tlvまたはSparsedata-TLVは、応答の結果TLVに置き換えられます。リクエストがFailureAckフラグを設定した場合、故障したアイテムのみが応答に表示されます。リクエストがAlwaysAckの場合、リクエストのすべてのコンポーネントがRESPOLDにresult-tlvsを使用して表示されます。
Note that if a SET/SET-PROP request with a structure in a FULLDATA-TLV is issued, and some field in the structure is invalid, the FE will not attempt to indicate which field was invalid, but rather will indicate that the operation failed. Note further that if there are multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the FE can select which error it chooses to return. So if a FULLDATA-TLV for a SET/SET-PROP of a structure attempts to write one field that is read only, and attempts to set another field to an invalid value, the FE can return indication of either error.
Fulldata-TLVの構造を持つセット/セットプロップ要求が発行され、構造内の一部のフィールドが無効である場合、FEはどのフィールドが無効であるかを示しようとしないが、操作が失敗したことを示すことを試みることに注意してください。。さらに、単一のリーフパスダタ/fulldata-TLBに複数のエラーがある場合、FEは返すことを選択するエラーを選択できることに注意してください。したがって、構造のセット/セットプロップのfulldata-tlvが、読み取り専用の1つのフィールドを書き込もうとし、別のフィールドを無効な値に設定しようとする場合、Feはいずれかのエラーの表示を返すことができます。
A SET/SET-PROP operation on a variable-length component with a length of 0 for the item is not the same as deleting it. If the CE wishes to delete, then the DEL operation should be used whether the path refers to an array component or an optional structure component.
アイテムの長さ0の可変長コンポーネントのセット/セットプロップ操作は、削除するのと同じではありません。CEが削除を希望する場合、パスが配列コンポーネントまたはオプションの構造コンポーネントを指すかどうかにかかわらず、DEL操作を使用する必要があります。
The RESULT-TLV is an instance of TLV defined in Section 6.2. The definition is as follows:
結果TLVは、セクション6.2で定義されている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 = RESULT-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: RESULT-TLV Defined Result Values
図20：結果-TLV定義結果値
+-----------------------------+-----------+-------------------------+
| Result Value | Value | Definition |
+-----------------------------+-----------+-------------------------+
| E_SUCCESS | 0x00 | Success |
| E_INVALID_HEADER | 0x01 | Unspecified error with |
| | | header. |
| E_LENGTH_MISMATCH | 0x02 | Header length field |
| | | does not match actual |
| | | packet length. |
| E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch |
| | | in versions. |
| E_INVALID_DESTINATION_PID | 0x04 | Destination PID is |
| | | invalid for the message |
| | | receiver. |
| E_LFB_UNKNOWN | 0x05 | LFB Class ID is not |
| | | known by receiver. |
| E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known |
| | | by receiver but not |
| | | currently in use. |
| E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known |
| | | but the specified |
| | | instance of that class |
| | | does not exist. |
| E_INVALID_PATH | 0x08 | The specified path is |
| | | impossible. |
| E_COMPONENT_DOES_NOT_EXIST | 0x09 | The specified path is |
| | | possible but the |
| | | component does not |
| | | exist (e.g., attempt to |
| | | modify a table row that |
| | | has not been created). |
| E_EXISTS | 0x0A | The specified object |
| | | exists but it cannot |
| | | exist for the operation |
| | | to succeed (e.g., |
| | | attempt to add an |
| | | existing LFB instance |
| | | or array subscript). |
| E_NOT_FOUND | 0x0B | The specified object |
| | | does not exist but it |
| | | MUST exist for the |
| | | operation to succeed |
| | | (e.g., attempt to |
| | | delete a non-existing |
| | | LFB instance or array |
| | | subscript). |
| E_READ_ONLY | 0x0C | Attempt to modify a |
| | | read-only value. |
| E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an |
| | | array with an unallowed |
| | | subscript. |
| E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a |
| | | parameter to a value |
| | | outside of its |
| | | allowable range. |
| E_CONTENTS_TOO_LONG | 0x0D | Attempt to write |
| | | contents larger than |
| | | the target object space |
| | | (i.e., exceeding a |
| | | buffer). |
| E_INVALID_PARAMETERS | 0x10 | Any other error with |
| | | data parameters. |
| E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not |
| | | acceptable. |
| E_INVALID_FLAGS | 0x12 | Message flags are not |
| | | acceptable for the |
| | | given message type. |
| E_INVALID_TLV | 0x13 | A TLV is not acceptable |
| | | for the given message |
| | | type. |
| E_EVENT_ERROR | 0x14 | Unspecified error while |
| | | handling an event. |
| E_NOT_SUPPORTED | 0x15 | Attempt to perform a |
| | | valid ForCES operation |
| | | that is unsupported by |
| | | the message receiver. |
| E_MEMORY_ERROR | 0x16 | A memory error occurred |
| | | while processing a |
| | | message (no error |
| | | detected in the message |
| | | itself). |
| E_INTERNAL_ERROR | 0x17 | An unspecified error |
| | | occurred while |
| | | processing a message |
| | | (no error detected in |
| | | the message itself). |
| - | 0x18-0xFE | Reserved |
| E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for |
| | | when the FE cannot |
| | | decide what went |
| | | wrong). |
+-----------------------------+-----------+-------------------------+
Table 4
表4
A FULLDATA-TLV has "T"= FULLDATA-TLV and a 16-bit length followed by the data value/contents. Likewise, a SPARSEDATA-TLV has "T" = SPARSEDATA-TLV, a 16-bit length, followed by the data value/contents. In the case of the SPARSEDATA-TLV, each component in the Value part of the TLV will be further encapsulated in an ILV.
fulldata-tlvには「t」= fulldata-tlvと16ビットの長さに続いてデータ値/コンテンツがあります。同様に、Sparsedata-TLVには「T」= Sparsedata-TLV、16ビットの長さがあり、その後にデータ値/コンテンツが続きます。Sparsedata-TLVの場合、TLVの値部分の各コンポーネントはILVでさらにカプセル化されます。
Below are the encoding rules for the FULLDATA-TLV and SPARSEDATA-TLVs. Appendix C is very useful in illustrating these rules:
以下は、Fulldata-TLVおよびSparsedata-TLVのエンコードルールです。付録Cは、これらのルールを説明するのに非常に役立ちます。
1. Both ILVs and TLVs MUST be 32-bit aligned. Any padding bits used for the alignment MUST be zero on transmission and MUST be ignored upon reception.
1. ILVとTLVの両方が32ビットアライメントする必要があります。アライメントに使用されるパディングビットは、送信時にゼロである必要があり、受信時に無視する必要があります。
2. FULLDATA-TLVs may be used at a particular path only if every component at that path level is present. In example 1(c) of Appendix C, this concept is illustrated by the presence of all components of the structure S in the FULLDATA-TLV encoding. This requirement holds regardless of whether the fields are fixed or variable length, mandatory or optional.
2. Fulldata-TLVは、そのパスレベルのすべてのコンポーネントが存在する場合にのみ、特定のパスで使用できます。付録Cの例1（c）では、この概念は、fulldata-tlvエンコーディングに構造のすべてのコンポーネントが存在することによって示されています。この要件は、フィールドが固定されているか、可変の長さであるか、必須かオプションであるかに関係なく、保持されます。
* If a FULLDATA-TLV is used, the encoder MUST lay out data for each component in the same order in which the data was defined in the LFB specification. This ensures the decoder is able to retrieve the data. To use the example 1 again in Appendix C, this implies the encoder/decoder is assumed to have knowledge of how structure S is laid out in the definition.
* Fulldata-TLVを使用する場合、エンコーダーは、データがLFB仕様で定義されたのと同じ順序で各コンポーネントのデータをレイアウトする必要があります。これにより、デコーダーがデータを取得できるようになります。付録Cで再度例1を使用するために、これは、エンコーダー/デコーダーが定義で構造がどのようにレイアウトされるかについての知識を持っていると想定されることを意味します。
* In the case of a SPARSEDATA-TLV, it does not need to be ordered since the "I" in the ILV uniquely identifies the component. Examples 1(a) and 1(b) in Appendix C illustrate the power of SPARSEDATA-TLV encoding.
* Sparsedata-TLVの場合、ILVの「I」がコンポーネントを一意に識別するため、注文する必要はありません。付録Cの例1（a）および1（b）は、Sparsedata-TLVエンコーディングの能力を示しています。
3. Inside a FULLDATA-TLV
3. fulldata-tlv内
* The values for atomic, fixed-length fields are given without any TLV encapsulation.
* 原子、固定長のフィールドの値は、TLVカプセル化なしで与えられます。
* The values for atomic, variable-length fields are given inside FULLDATA-TLVs.
* アトミック、可変長のフィールドの値は、fulldata-tlv内に与えられます。
* The values for arrays are in the form of index/subscript, followed by value as stated in "Data Packing Rules" (Section 7.1.1) and demonstrated by the examples in the appendices.
* 配列の値はインデックス/サブスクリプトの形式であり、その後に「データパッキングルール」（セクション7.1.1）に記載されている値が続き、付録の例で示されています。
4. Inside a SPARSEDATA-TLV
4. Sparsedata-TLV内
* The values of all fields MUST be given with ILVs (32-bit index, 32-bit length).
* すべてのフィールドの値は、ILV（32ビットインデックス、32ビットの長さ）で指定する必要があります。
5. FULLDATA-TLVs cannot contain an ILV.
5. Fulldata-TLVSにはILVを含めることはできません。
6. A FULLDATA-TLV can also contain a FULLDATA-TLV for variable-sized components. The decoding disambiguation is assumed from rule #3 above.
6. Fulldata-TLVには、可変サイズのコンポーネント用のfulldata-tlvも含めることができます。デコードの分解は、上記のルール＃3から想定されています。
It is expected that a GET-RESPONSE would satisfy the following:
get-responseが以下を満たすことが期待されています。
o It would have exactly the same path definitions as those sent in the GET. The only difference is that a GET-RESPONSE will contain FULLDATA-TLVs.
o GETで送信されたものとまったく同じパス定義があります。唯一の違いは、get-responseにfulldata-tlvが含まれることです。
o It should be possible to take the same GET-RESPONSE and convert it to a SET successfully by merely changing the T in the operational TLV.
o 同じget-responseを取得し、運用上のTLVでTを変更するだけで正常にセットに変換することが可能である必要があります。
o There are exceptions to this rule:
o この規則には例外があります。
1. When a KEY selector is used with a path in a GET operation, that selector is not returned in the GET-RESPONSE; instead, the cooked result is returned. Refer to the examples using KEYS to see this.
1. GET操作のパスでキーセレクターが使用される場合、そのセレクターはget-responseで返されません。代わりに、調理された結果が返されます。これを見るためにキーを使用した例を参照してください。
2. When dumping a whole table in a GET, the GET-RESPONSE that merely edits the T to be SET will end up overwriting the table.
2. テーブル全体をGETにダンプすると、設定されるTを編集するだけのGet-Responseがテーブルを上書きすることになります。
The figure below shows a general layout of the PL PDU. A main header is followed by one or more LFB selections each of which may contain one or more operations.
以下の図は、PL PDUの一般的なレイアウトを示しています。メインヘッダーの後に、それぞれが1つ以上の操作を含む場合がある1つ以上のLFB選択が続きます。
main hdr (Config in this case)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID
| |
| |
| +-- LFBInstance
| |
| +-- T = SET
| | |
| | +-- // one or more path targets
| | // with their data here to be added
| |
| +-- T = DEL
| . |
| . +-- // one or more path targets to be deleted
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID
| |
| |
| +-- LFBInstance
| |
| + -- T= SET
| | .
| | .
| + -- T= DEL
| | .
| | .
| |
| + -- T= SET
| | .
| | .
|
|
+--- T = LFBselect
|
+-- LFBCLASSID
|
+-- LFBInstance
.
.
.
Figure 21: PL PDU Logical Layout
The figure below shows a more detailed example of the general layout of the operation within a targeted LFB selection. The idea is to show the different nesting levels a path could take to get to the target path.
以下の図は、ターゲットを絞ったLFB選択内の操作の一般的なレイアウトのより詳細な例を示しています。アイデアは、ターゲットパスに到達するためにパスがとる可能性のあるさまざまなネストレベルを示すことです。
T = SET
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| + -- T = KEYINFO-TLV
| | + -- KEY_ID
| | + -- KEY_DATA
| |
| + -- T = FULLDATA-TLV
| + -- data
|
|
T = SET
| |
| +- T = Path-data
| | |
| | + -- flags
| | + -- IDCount
| | + -- IDs
| | |
| | + -- T = FULLDATA-TLV
| | + -- data
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| + -- T = FULLDATA-TLV
| + -- data
T = DEL
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
+ -- T = KEYINFO-TLV
| + -- KEY_ID
| + -- KEY_DATA
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
Figure 22: Sample Operation Layout
図22：サンプル操作レイアウト
Appendix D shows a more concise set of use cases on how the data encoding is done.
付録Dは、データのエンコードの完了方法に関するより簡潔なユースケースのセットを示しています。
There are two LFBs that are used to control the operation of the ForCES protocol and to interact with FEs and CEs:
力プロトコルの動作を制御し、FESおよびCEと相互作用するために使用される2つのLFBがあります。
o FE Protocol LFB o FE Object LFB
o FeプロトコルLFB O FEオブジェクトLFB
Although these LFBs have the same form and interface as other LFBs, they are special in many respects. They have fixed well-known LFB Class and Instance IDs. They are statically defined (no dynamic instantiation allowed), and their status cannot be changed by the protocol: any operation to change the state of such LFBs (for instance, in order to disable the LFB) MUST result in an error. Moreover, these LFBs MUST exist before the first ForCES message can be sent or received. All components in these LFBs MUST have pre-defined default values. Finally, these LFBs do not have input or output ports and do not integrate into the intra-FE LFB topology.
これらのLFBには他のLFBと同じフォームとインターフェイスがありますが、多くの点で特別です。彼らは有名なLFBクラスとインスタンスIDを修正しました。それらは静的に定義されており（動的なインスタンス化は許可されていません）、プロトコルによってステータスを変更することはできません。そのようなLFBの状態を変更する操作（たとえば、LFBを無効にするために）はエラーをもたらす必要があります。さらに、これらのLFBは、最初のフォースメッセージを送信または受信する前に存在する必要があります。これらのLFBのすべてのコンポーネントには、事前に定義されたデフォルト値が必要です。最後に、これらのLFBには入力ポートや出力ポートがなく、FE内LFBトポロジに統合されません。
The FE Protocol LFB is a logical entity in each FE that is used to control the ForCES protocol. The FE Protocol LFB Class ID is assigned the value 0x2. The FE Protocol LFB Instance ID is assigned the value 0x1. There MUST be one and only one instance of the FE Protocol LFB in an FE. The values of the components in the FE Protocol LFB have pre-defined default values that are specified here. Unless explicit changes are made to these values using Config messages from the CE, these default values MUST be used for correct operation of the protocol.
FEプロトコルLFBは、力プロトコルを制御するために使用される各FEの論理エンティティです。FEプロトコルLFBクラスIDには、値0x2が割り当てられます。FEプロトコルLFBインスタンスIDには値0x1が割り当てられます。Feには、FeプロトコルLFBの1つのインスタンスが1つだけ存在する必要があります。FEプロトコルLFBのコンポーネントの値には、ここで指定されている事前に定義されたデフォルト値があります。CEからの構成メッセージを使用してこれらの値に明示的な変更が行われない限り、これらのデフォルト値をプロトコルの正しい操作に使用する必要があります。
The formal definition of the FE Protocol Object LFB can be found in Appendix B.
FEプロトコルオブジェクトLFBの正式な定義は、付録Bにあります。
FE Protocol capabilities are read-only.
FEプロトコル機能は読み取り専用です。
ForCES protocol version(s) supported by the FE.
FEでサポートされる力プロトコルバージョン。
FE Protocol components (can be read and set).
FEプロトコルコンポーネント（読み取りおよび設定できます）。
Current running version of the ForCES protocol.
フォースプロトコルの現在の実行バージョン。
FE unicast ID.
FEユニキャストID。
FE multicast ID(s) list - This is a list of multicast IDs to which the FE belongs. These IDs are configured by the CE.
FEマルチキャストID（S）リスト - これは、FEが属するマルチキャストIDのリストです。これらのIDはCEによって構成されています。
CE heartbeat policy - This policy, along with the parameter 'CE Heartbeat Dead Interval (CE HDI)' as described below, defines the operating parameters for the FE to check the CE liveness. The policy values with meanings are listed as follows:
CE Heartbeatポリシー - このポリシーは、以下に説明するように、パラメーター「Ce Heartbeat Dead Interval（CE HDI）」とともに、CEの責任を確認するためのFEの動作パラメーターを定義します。意味のあるポリシー値は次のようにリストされています。
o 0 (default) - This policy specifies that the CE will send a Heartbeat message to the FE(s) whenever the CE reaches a time interval within which no other PL messages were sent from the CE to the FE(s); refer to Section 4.3.3 and Section 7.10 for details. The CE HDI component as described below is tied to this policy.
o 0（デフォルト） - このポリシーは、CEがCEからCEからFe（s）に送信されない時間間隔に達すると、CEがFEにハートビートメッセージを送信することを指定します。詳細については、セクション4.3.3およびセクション7.10を参照してください。以下に説明するCE HDIコンポーネントは、このポリシーに関連付けられています。
o 1 - The CE will not generate any HB messages. This actually means that the CE does not want the FE to check the CE liveness.
o 1 -CEはHBメッセージを生成しません。これは、実際には、CEがFEがCEの責任をチェックすることを望まないことを意味します。
o Others - Reserved.
o その他 - 予約済み。
CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses to check the CE liveness. If FE has not received any messages from CE within this time interval, FE deduces lost connectivity, which implies that the CE is dead or the association to the CE is lost. Default value is 30 s.
Ce Heartbeat Dead Interval（CE HDI） - FEが使用する時間間隔は、CEの責任を確認します。この時間間隔でFEがCEからメッセージを受け取っていない場合、Feは接続性の失われたものを推測します。これは、CEが死んだか、CEとの関連が失われることを意味します。デフォルト値は30秒です。
FE heartbeat policy - This policy, along with the parameter 'FE Heartbeat Interval (FE HI)', defines the operating parameters for how the FE should behave so that the CE can deduce its liveness. The policy values and the meanings are:
Fe Heartbeatポリシー - このポリシーは、パラメーター「FE Heartbeat間隔（FE HI）」とともに、CEがその活性を推測できるように、FEがどのように動作するかについての動作パラメーターを定義します。ポリシーの値と意味は次のとおりです。
o 0 (default) - The FE should not generate any Heartbeat messages. In this scenario, the CE is responsible for checking FE liveness by setting the PL header ACK flag of the message it sends to AlwaysACK. The FE responds to the CE whenever the CE sends such Heartbeat Request messages. Refer to Section 7.10 and Section 4.3.3 for details.
o 0（デフォルト） - FEはハートビートメッセージを生成してはなりません。このシナリオでは、CEは、AlwaysAckに送信されるメッセージのPLヘッダーACKフラグを設定することにより、FEの活性をチェックする責任があります。CEがそのようなハートビートリクエストメッセージを送信するたびに、FEはCEに応答します。詳細については、セクション7.10およびセクション4.3.3を参照してください。
o 1 - This policy specifies that the FE MUST actively send a Heartbeat message if it reaches the time interval assigned by the FE HI as long as no other messages were sent from the FE to the CE during that interval as described in Section 4.3.3.
o 1-このポリシーは、セクション4.3.3で説明されているように、その間隔中にFEからCEに他のメッセージが送信されない限り、FEがFE HIによって割り当てられた時間間隔に到達した場合、FEはハートビートメッセージを積極的に送信する必要があることを指定します。
o Others - Reserved.
o その他 - 予約済み。
FE Heartbeat Interval (FE HI) - The time interval the FE should use to send HB as long as no other messages were sent from the FE to the CE during that interval as described in Section 4.3.3. The default value for an FE HI is 500 ms.
FEハートビート間隔（FE HI） - セクション4.3.3で説明されているように、その間隔中にFEからCEに他のメッセージが送信されない限り、FEはHBを送信するために使用する必要があります。FE HIのデフォルト値は500ミリ秒です。
Primary CEID - The CEID with which the FE is associated.
プライマリCEID- FEが関連付けられているCEID。
Last Primary CEID - The CEID of the last CE with which the FE associated. This CE ID is reported to the new Primary CEID.
最後のプライマリCEID- FEが関連付けられている最後のCEのCEID。このCE IDは、新しいプライマリCEIDに報告されます。
The list of backup CEs an FE can use as backups. Refer to Section 8 for details.
Backup CES an FEのリストは、バックアップとして使用できます。詳細については、セクション8を参照してください。
CE failover policy - This specifies the behavior of the FE when the association with the CE is lost. There is a very tight relation between CE failover policy and Section 7.3.1.1.2.8, Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an association is lost, depending on configuration, one of the policies listed below is activated.
CEフェールオーバーポリシー - これは、CEとの関連が失われた場合のFEの動作を指定します。CEフェイルオーバーポリシーとセクション7.3.1.1.2.8、セクション7.3.1.1.2.10、セクション7.3.1.1.2.12、およびセクション8の間には非常に厳しい関係があります。以下にリストされています。
o 0 (default) - The FE should stop functioning immediately and transition to FE OperDisable.
o 0（デフォルト） - FEはすぐに機能するのを停止し、FE操作可能に移行する必要があります。
o 1 - The FE should continue running and do what it can even without an associated CE. This basically requires that the FE support CE Graceful restart (and defines such support in its capabilities). If the CEFTI expires before the FE re-associates with either the primary CEID (Section 7.3.1.1.2.8) or one of possibly several backup CEs (Section 7.3.1.1.2.10), the FE will go operationally down.
o 1 -FEは実行を続け、関連するCEがなくてもできることを実行する必要があります。これには、基本的に、FEがCEの優雅な再起動をサポートする必要があります（そして、その機能におけるそのようなサポートを定義します）。Feが主要なCEID（セクション7.3.1.1.2.8）またはおそらくいくつかのバックアップCE（セクション7.3.1.1.2.10）のいずれかと再分類する前にCEFTIが期限切れになった場合、FEは操作的にダウンします。
o Others - Reserved.
o その他 - 予約済み。
CE Failover Timeout Interval (CEFTI) - The time interval associated with the CE failover policy case '0' and '1'. The default value is set to 300 seconds. Note that it is advisable to set the CEFTI value much higher than the CE Heartbeat Dead Interval (CE HDI) since the effect of expiring this parameter is devastating to the operation of the FE.
CEフェールオーバータイムアウト間隔（CEFTI） - CEフェールオーバーポリシーケース「0」および「1」に関連する時間間隔。デフォルト値は300秒に設定されています。このパラメーターの期限切れの効果はFEの動作に壊滅的であるため、CEFTI値をCEハートビートデッドインターバル（CE HDI）よりもはるかに高く設定することをお勧めします。
FE restart policy - This specifies the behavior of the FE during an FE restart. The restart may be from an FE failure or other reasons that have made the FE down and then need to restart. The values are defined as follows:
FEの再起動ポリシー - これは、FEの再起動中のFEの動作を指定します。再起動は、FEの障害またはFEを下げて再起動する必要がある他の理由からのものである可能性があります。値は次のように定義されます。
o 0(default)- Restart the FE from scratch. In this case, the FE should start from the pre-association phase.
o 0（デフォルト） - FEをゼロから再起動します。この場合、FEは前協会の段階から開始する必要があります。
o Others - Reserved for future use.
o その他 - 将来の使用のために予約されています。
The FE Object LFB is a logical entity in each FE and contains components relative to the FE itself, and not to the operation of the ForCES protocol.
FEオブジェクトLFBは、各FEの論理エンティティであり、Fe自体に比べてコンポーネントが含まれており、Force Protocolの動作ではありません。
The formal definition of the FE Object LFB can be found in [RFC5812]. The model captures the high-level properties of the FE that the CE needs to know to begin working with the FE. The class ID for this LFB class is also assigned in [RFC5812]. The singular instance of this class will always exist, and will always have instance ID 0x1 within its class. It is common, although not mandatory, for a CE to fetch much of the component and capability information from this LFB instance when the CE begins controlling the operation of the FE.
FEオブジェクトLFBの正式な定義は、[RFC5812]に記載されています。このモデルは、CEがFEの作業を開始するために知る必要があるFEの高レベルの特性をキャプチャします。このLFBクラスのクラスIDは[RFC5812]にも割り当てられています。このクラスの特異なインスタンスは常に存在し、クラス内に常にID 0x1をインスタンスにします。CEがFEの動作を制御し始めたときに、CEがこのLFBインスタンスからコンポーネントおよび機能情報の多くと機能情報を取得することは一般的です。
Recall: The PL provides a master(CE)-slave(FE) relationship. The LFBs reside at the FE and are controlled by CE.
リコール：PLは、マスター（CE） - スレーブ（FE）の関係を提供します。LFBはFEに存在し、CEによって制御されます。
When messages go from the CE, the LFB selector (class and instance) refers to the destination LFB selection that resides in the FE.
メッセージがCEから進むと、LFBセレクター（クラスとインスタンス）は、FEに存在する宛先LFB選択を指します。
When messages go from the FE to the CE, the LFB selector (class and instance) refers to the source LFB selection that resides in the FE.
メッセージがFEからCEに移動すると、LFBセレクター（クラスとインスタンス）は、FEに存在するソースLFB選択を指します。
The ForCES Association messages are used to establish and tear down associations between FEs and CEs.
Force Associationメッセージは、FESとCES間の関連付けを確立および解体するために使用されます。
This message is sent by the FE to the CE to set up a ForCES association between them.
このメッセージは、FEでCEに送信され、それらの間に力の関連性を設定します。
Message transfer direction: FE to CE
メッセージ転送方向：CEへのFE
Message header: The Message Type in the header is set to MessageType= 'AssociationSetup'. The ACK flag in the header MUST be ignored, and the Association Setup message always expects to get a response from the message receiver (CE), whether or not the setup is successful. The correlator field in the header is set, so that FE can correlate the response coming back from the CE correctly. The FE may set the source ID to 0 in the header to request that the CE should assign an FE ID for the FE in the Setup Response message.
メッセージヘッダー：ヘッダーのメッセージタイプは、MessageType = 'AssociationSetup'に設定されています。ヘッダー内のACKフラグは無視する必要があり、Associationのセットアップメッセージは、セットアップが成功したかどうかにかかわらず、メッセージ受信機（CE）から応答を取得することを常に期待しています。ヘッダー内の相関器フィールドが設定されているため、FEはCEから戻ってくる応答を正しく相関させることができます。FEは、ヘッダー内のソースIDを0に設定して、CEがセットアップ応答メッセージのFEのFE IDを割り当てるように要求する場合があります。
Message body: The Association Setup message body optionally consists of zero, one, or two LFBselect TLVs, as described in Section 7.1.5. The Association Setup message only operates on the FE Object and FE Protocol LFBs; therefore, the LFB class ID in the LFBselect TLV only points to these two kinds of LFBs.
メッセージ本文：セクション7.1.5で説明されているように、アソシエーションセットアップメッセージ本文はオプションでゼロ、1つ、または2つのLFBSElect TLVで構成されています。アソシエーションセットアップメッセージは、FEオブジェクトとFEプロトコルLFBでのみ動作します。したがって、LFBSElect TLVのLFBクラスIDは、これら2種類のLFBを指しています。
The OPER-TLV in the LFBselect TLV is defined as a 'REPORT' operation. More than one component may be announced in this message using the REPORT operation to let the FE declare its configuration parameters in an unsolicited manner. These may contain components suggesting values such as the FE HB Interval or the FEID. The OPER-TLV used is defined below.
LFBSElect TLVのオペラスTLVは、「レポート」操作として定義されます。このメッセージでは、レポート操作を使用して複数のコンポーネントが発表される場合があります。これらには、Fe Hb間隔やFeidなどの値を示唆するコンポーネントが含まれている場合があります。使用されているOper-TLVは以下に定義されています。
OPER-TLV for Association Setup:
アソシエーションセットアップ用のオペラシック：
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 = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: OPER-TLV
図23：Oper-TLV
Type: Only one operation type is defined for the Association Setup message:
タイプ：アソシエーションセットアップメッセージに対して定義されている操作タイプは1つだけです。
Type = "REPORT" - This type of operation is for the FE to report something to the CE.
type = "Report" - このタイプの操作は、FEがCEに何かを報告するためのものです。
PATH-DATA-TLV for REPORT: This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA BNF definition. The PATH-DATA-TLV for the REPORT operation MAY contain FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV in the data format. The RESULT-TLV is defined in Section 7.1.7 and the FULLDATA-TLV is defined in Section 7.1.8.
レポート用のpath-data-tlv：これは、一般的にPath-data BNF定義のセクション7で定義されているPath-Data-TLV形式です。レポート操作のPath-Data-TLVにはfulldata-tlv（s）が含まれている場合がありますが、データ形式にresult-tlvを含めてはなりません。結果TLVはセクション7.1.7で定義されており、Fulldata-TLVはセクション7.1.8で定義されています。
To better illustrate the above PDU format, a tree structure for the format is shown below:
上記のPDU形式をよりよく説明するために、形式のツリー構造を以下に示します。
main hdr (type = Association Setup)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID = FE object
| |
| |
| +-- LFBInstance = 0x1
|
+--- T = LFBselect
|
+-- LFBCLASSID = FE Protocol object
|
|
+-- LFBInstance = 0x1
|
+---OPER-TLV = REPORT
|
+-- Path-data to one or more components
Figure 24: PDU Format for Association Setup Message
図24：AssociationセットアップメッセージのPDU形式
This message is sent by the CE to the FE in response to the Setup message. It indicates to the FE whether or not the setup is successful, i.e., whether an association is established.
このメッセージは、セットアップメッセージに応じてCEからFEに送信されます。セットアップが成功したかどうか、つまり協会が確立されているかどうかをFEに示します。
Message transfer direction:
メッセージ転送方向：
CE to FE
CEからFE
Message header:
メッセージヘッダー：
The Message Type in the header is set to MessageType= 'AssociationSetupResponse'. The ACK flag in the header MUST be ignored, and the Setup Response message never expects to get any more responses from the message receiver (FE). The destination ID in the header will be set to the source ID in the corresponding Association Setup message, unless that source ID was 0. If the corresponding source ID was 0, then the CE will assign an FE ID value and use that value for the destination ID.
ヘッダーのメッセージタイプは、MessageType = 'AssocionsetupResponse'に設定されています。ヘッダーのACKフラグは無視する必要があり、セットアップ応答メッセージは、メッセージ受信機（FE）からこれ以上の応答を取得することを決して期待しません。ヘッダーの宛先IDは、そのソースIDが0の場合、対応する関連付けセットアップメッセージのソースIDに設定されます。対応するソースIDが0の場合、CEはFE ID値を割り当て、その値を使用します。宛先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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ASRresult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Setup Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: ASResult OPER-TLV
図25：AsResult Oper-TLV
Type (16 bits):
タイプ（16ビット）：
The type of the TLV is "ASResult".
TLVのタイプは「asResult」です。
Length (16 bits):
長さ（16ビット）：
Length of the TLV including the T and L fields, in octets.
TLVの長さは、TおよびLフィールドを含むオクテットにあります。
Association Setup result (32 bits):
アソシエーションのセットアップ結果（32ビット）：
This indicates whether the Setup message was successful or whether the FE request was rejected by the CE. The defined values are:
これは、セットアップメッセージが成功したかどうか、またはFE要求がCEによって拒否されたかどうかを示します。定義された値は次のとおりです。
0 = success
1 = FE ID invalid
2 = permission denied
To better illustrate the above PDU format, a tree structure for the format is shown below:
上記のPDU形式をよりよく説明するために、形式のツリー構造を以下に示します。
main hdr (type = Association Setup Response)
|
|
+--- T = ASResult-TLV
Figure 26: PDU Format for Association Setup Response Message
図26：アソシエーションセットアップ応答メッセージのPDU形式
This message can be sent by the FE or CE to any ForCES element to end its ForCES association with that element.
このメッセージは、FEまたはCEによって、その要素との力を終わらせるために、あらゆる力要素に送信できます。
Message transfer direction:
メッセージ転送方向：
CE to FE, or FE to CE (or CE to CE)
ceからfe、またはfe to ce（またはce to ce）
Message Header:
メッセージヘッダー：
The Message Type in the header is set to MessageType= "AssociationTeardown". The ACK flag MUST be ignored. The correlator field in the header MUST be set to zero and MUST be ignored by the receiver.
ヘッダーのメッセージタイプは、MessageType = "AssociationTearDown"に設定されています。ACKフラグは無視する必要があります。ヘッダー内の相関器フィールドはゼロに設定する必要があり、受信機は無視する必要があります。
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 = ASTreason | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Teardown Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: ASTreason-TLV
図27：Astrason-TLV
Type (16 bits):
タイプ（16ビット）：
The type of the TLV is "ASTreason".
TLVのタイプは「Astreason」です。
Length (16 bits):
長さ（16ビット）：
Length of the TLV including the T and L fields, in octets.
TLVの長さは、TおよびLフィールドを含むオクテットにあります。
Teardown reason (32 bits):
分解理由（32ビット）：
This indicates the reason why the association is being terminated. Several reason codes are defined as follows.
これは、協会が終了している理由を示しています。いくつかの理由コードは次のように定義されています。
0 - normal teardown by administrator
0-管理者による通常の裂け目
1 - error - loss of heartbeats
1-エラー - ハートビートの喪失
2 - error - out of bandwidth
2-エラー - 帯域幅から
3 - error - out of memory
3-エラー - メモリ外
4 - error - application crash
4-エラー - アプリケーションクラッシュ
255 - error - other or unspecified
255-エラー - その他または不特定
To better illustrate the above PDU format, a tree structure for the format is shown below:
上記のPDU形式をよりよく説明するために、形式のツリー構造を以下に示します。
main hdr (type = Association Teardown)
|
|
+--- T = ASTreason-TLV
Figure 28: PDU Format for Association Teardown Message
図28：Association TeardownメッセージのPDU形式
The ForCES Configuration messages are used by CE to configure the FEs in a ForCES NE and report the results back to the CE.
Force ConfigurationメッセージはCEによって使用され、FESを力NEで構成し、結果をCEに報告します。
This message is sent by the CE to the FE to configure LFB components in the FE. This message is also used by the CE to subscribe/ unsubscribe to LFB events.
このメッセージは、FEでLFBコンポーネントを構成するためにCEからFEに送信されます。このメッセージは、CEによってもLFBイベントを購読/登録解除するために使用されます。
As usual, a Config message is composed of a common header followed by a message body that consists of one or more TLV data formats. Detailed description of the message is as follows:
いつものように、構成メッセージは共通のヘッダーで構成され、その後に1つ以上のTLVデータ形式で構成されるメッセージ本文が続きます。メッセージの詳細な説明は次のとおりです。
Message transfer direction:
メッセージ転送方向：
CE to FE
CEからFE
Message header:
メッセージヘッダー：
The Message Type in the header is set to MessageType= 'Config'. The ACK flag in the header can be set to any value defined in Section 6.1, to indicate whether or not a response from the FE is expected by the message.
ヘッダーのメッセージタイプは、MessageType = 'Config'に設定されています。ヘッダーのACKフラグは、セクション6.1で定義された任意の値に設定して、メッセージによってFEからの応答が予想されるかどうかを示します。
OPER-TLV for Config:
config：oper-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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OPER-TLV for Config
図29：設定用のオペ-TLV
Type:
タイプ：
The operation type for Config message. Two types of operations for the Config message are defined:
構成メッセージの操作タイプ。構成メッセージの2種類の操作が定義されています。
Type = "SET" - This operation is to set LFB components
type = "set" - この操作はLFBコンポーネントを設定することです
Type = "SET-PROP" - This operation is to set LFB component properties.
type = "set -prop" - この操作は、LFBコンポーネントプロパティを設定することです。
Type = "DEL" - This operation is to delete some LFB components.
type = "del" - この操作は、いくつかのLFBコンポーネントを削除することです。
Type = "COMMIT" - This operation is sent to the FE to commit in a 2pc transaction. A COMMIT TLV is an empty TLV, i.e., it has no "V"alue. In other words, there is a length of 4 (which is for the header only).
type = "commit" - この操作は、2pcトランザクションでコミットするためにFEに送信されます。コミットTLVは空のTLVです。つまり、「V」Alueはありません。言い換えれば、4の長さ（ヘッダー専用です）があります。
Type = "TRCOMP" - This operation is sent to the FE to mark the success from an NE perspective of a 2pc transaction. A TRCOMP TLV is an empty TLV, i.e., it has no "V"alue. In other words, there is a length of 4 (which is for the header only).
type = "TRCOMP" - この操作はFEに送信され、2PCトランザクションのNEの観点から成功をマークします。TRCOMP TLVは空のTLVです。つまり、「V」Alueはありません。言い換えれば、4の長さ（ヘッダー専用です）があります。
PATH-DATA-TLV:
Path-data-tlv：
This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The restriction on the use of PATH-DATA-TLV for SET/SET-PROP operation is that it MUST contain either FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The restriction on the use of PATH-DATA-TLV for DEL operation is it MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The RESULT-TLV is defined in Section 7.1.7 and FULLDATA-TLVs and SPARSEDATA-TLVs are defined in Section 7.1.8.
これは一般的に、Path-Data-TLV BNF定義のセクション7で定義されているPath-Data-TLV形式です。セット/セットプロップ操作のためのPath-Data-TLVの使用に関する制限は、fulldata-tlvまたはSparsedata-tlv（s）を含める必要があるが、結果tlvを含めてはならないことです。del操作のためのPath-data-tlvの使用に関する制限は、fulldata-tlvまたはsparsedata-tlv（s）が含まれている可能性がありますが、結果tlvを含めてはなりません。結果TLVはセクション7.1.7で定義されており、Fulldata-TLVとSparseData-TLVはセクション7.1.8で定義されています。
Note: For Event subscription, the events will be defined by the individual LFBs.
注：イベントサブスクリプションの場合、イベントは個々のLFBによって定義されます。
To better illustrate the above PDU format, a tree structure for the format is shown below:
上記のPDU形式をよりよく説明するために、形式のツリー構造を以下に示します。
main hdr (type = Config)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { SET }
| |
| +-- // one or more path targets
| // associated with FULLDATA-TLV or SPARSEDATA-TLV(s)
|
+-- T = operation { DEL }
| |
| +-- // one or more path targets
|
+-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV
.
.
Figure 30: PDU Format for Configuration Message
図30：構成メッセージのPDU形式
This message is sent by the FE to the CE in response to the Config message. It indicates whether or not the Config was successful on the FE and also gives a detailed response regarding the configuration result of each component.
このメッセージは、構成メッセージに応じて、FEでCEに送信されます。構成がFEで成功したかどうかを示し、各コンポーネントの構成結果に関する詳細な応答も提供します。
Message transfer direction:
メッセージ転送方向：
FE to CE Message header:
FE TO CEメッセージヘッダー：
The Message Type in the header is set to MessageType= 'Config Response'. The ACK flag in the header is always ignored, and the Config Response message never expects to get any further response from the message receiver (CE).
ヘッダーのメッセージタイプは、MessageType = 'Config Response'に設定されています。ヘッダーのACKフラグは常に無視され、構成応答メッセージはメッセージ受信機（CE）からさらなる応答を取得することを決して期待しません。
OPER-TLV for Config Response:
設定応答用のオペラス：
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: OPER-TLV for Config Response
図31：構成応答のオペラス-TLV
Type: The operation type for Config Response message. Two types of operations for the Config Response message are defined:
タイプ：構成応答メッセージの操作タイプ。構成応答メッセージの2種類の操作が定義されています。
Type = "SET-RESPONSE" - This operation is for the response of the SET operation of LFB components.
type = "set -response" - この操作は、LFBコンポーネントのセット操作の応答用です。
Type = "SET-PROP-RESPONSE" - This operation is for the response of the SET-PROP operation of LFB component properties.
type = "set-prop-response" - この操作は、LFBコンポーネントプロパティのセットプロップ操作の応答用です。
Type = "DEL-RESPONSE" - This operation is for the response of the DELETE operation of LFB components.
type = "del -response" - この操作は、LFBコンポーネントの削除操作の応答用です。
Type = "COMMIT-RESPONSE" - This operation is sent to the CE to confirm a commit success in a 2pc transaction. A COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating success or failure.
type = "commit -response" - この操作はCEに送信され、2PCトランザクションでのコミットの成功を確認します。コミットレスポンスTLVには、成功または失敗を示す結果TLVが含まれている必要があります。
PATH-DATA-TLV:
Path-data-tlv：
This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The restriction on the use of PATH-DATA-TLV for SET-RESPONSE operation is that it MUST contain RESULT-TLV(s). The restriction on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also MUST contain RESULT-TLV(s). The RESULT-TLV is defined in Section 7.1.7.
これは一般的に、Path-Data-TLV BNF定義のセクション7で定義されているPath-Data-TLV形式です。セットレスポンス操作のためのPath-Data-TLVの使用に関する制限は、結果TLVを含める必要があることです。Del-Response操作のためのPath-Data-TLVの使用に関する制限は、結果TLVを含める必要があることです。結果TLVは、セクション7.1.7で定義されています。
To better illustrate the above PDU format, a tree structure for the format is shown below:
上記のPDU形式をよりよく説明するために、形式のツリー構造を以下に示します。
main hdr (type = ConfigResponse)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { SET-RESPONSE }
| |
| +-- // one or more path targets
| // associated with FULL or SPARSEDATA-TLV(s)
|
+-- T = operation { DEL-RESPONSE }
| |
| +-- // one or more path targets
|
+-- T = operation { COMMIT-RESPONSE }
| |
| +-- RESULT-TLV
Figure 32: PDU Format for Config Response Message
図32：構成応答メッセージのPDU形式
The ForCES Query messages are used by the CE to query LFBs in the FE for information like LFB components, capabilities, statistics, etc. Query messages include the Query message and the Query Response message.
フォースクエリメッセージは、LFBコンポーネント、機能、統計などなどの情報について、FEのLFBSを照会するためにCEによって使用されます。クエリメッセージには、クエリメッセージとクエリ応答メッセージが含まれます。
A Query message is composed of a common header and a message body that consists of one or more TLV data formats. Detailed description of the message is as follows:
クエリメッセージは、1つ以上のTLVデータ形式で構成される共通のヘッダーとメッセージ本文で構成されています。メッセージの詳細な説明は次のとおりです。
Message transfer direction:
メッセージ転送方向：
from CE to FE Message header:
CEからFEメッセージヘッダーまで：
The Message Type in the header is set to MessageType= 'Query'. The ACK flag in the header is always ignored, and a full response for a Query message is always expected. The Correlator field in the header is set, so that the CE can locate the response back from FE correctly.
ヘッダーのメッセージタイプは、MessageType = 'query'に設定されています。ヘッダーのACKフラグは常に無視され、クエリメッセージの完全な応答が常に予想されます。ヘッダー内の相関器フィールドが設定されているため、CEはFEから正しく応答を戻すことができます。
OPER-TLV for Query:
クエリ用のオペラシック：
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 = GET/GET-PROP | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET/GET-PROP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: TLV for Query
図33：クエリのTLV
Type:
タイプ：
The operation type for query. Two operation types are defined:
クエリの操作タイプ。2つの操作タイプが定義されています。
Type = "GET" - This operation is to request to get LFB components.
type = "get" - この操作は、LFBコンポーネントの取得を要求することです。
Type = "GET-PROP" - This operation is to request to get LFB component properties.
type = "get -prop" - この操作は、LFBコンポーネントプロパティの取得を要求することです。
PATH-DATA-TLV for GET/GET-PROP:
get/get-prop用のpath-data-tlv：
This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The restriction on the use of PATH-DATA-TLV for GET/GET-PROP operation is it MUST NOT contain any SPARSEDATA-TLV or FULLDATA- TLV and RESULT-TLV in the data format.
これは一般的に、Path-Data-TLV BNF定義のセクション7で定義されているPath-Data-TLV形式です。Get/Get-Prop操作のためのPath-Data-TLVの使用に関する制限は、データ形式にSparsedata-TLVまたはfulldata-TLVおよびresult-TLVを含めてはなりません。
To better illustrate the above PDU format, a tree structure for the format is shown below:
上記のPDU形式をよりよく説明するために、形式のツリー構造を以下に示します。
main hdr (type = Query)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { GET }
| |
| +-- // one or more path targets
|
+-- T = operation { GET }
. |
. +-- // one or more path targets
.
Figure 34: PDU Format for Query Message
図34：クエリメッセージのPDU形式
When receiving a Query message, the receiver should process the message and come up with a query result. The receiver sends the query result back to the message sender by use of the Query Response message. The query result can be the information being queried if the query operation is successful, or can also be error codes if the query operation fails, indicating the reasons for the failure.
クエリメッセージを受信するとき、受信者はメッセージを処理し、クエリの結果を出す必要があります。レシーバーは、クエリ応答メッセージを使用して、クエリ結果をメッセージ送信者に送り返します。クエリの結果は、クエリ操作が成功した場合に照会される情報になる可能性があります。また、クエリ操作に障害が発生した場合はエラーコードになり、失敗の理由を示します。
A Query Response message is also composed of a common header and a message body consisting of one or more TLVs describing the query result. Detailed description of the message is as follows:
クエリ応答メッセージは、クエリの結果を説明する1つ以上のTLVで構成される共通ヘッダーとメッセージ本文で構成されています。メッセージの詳細な説明は次のとおりです。
Message transfer direction:
メッセージ転送方向：
from FE to CE
FからCEまで
Message header:
メッセージヘッダー：
The Message Type in the header is set to MessageType= 'QueryResponse'. The ACK flag in the header is ignored. As a response itself, the message does not expect a further response.
ヘッダーのメッセージタイプは、MessageType = 'queryResponse'に設定されています。ヘッダーのACKフラグは無視されます。応答自体として、メッセージはさらなる応答を期待していません。
OPER-TLV for Query Response:
クエリ応答用のオペラス-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 = GET-RESPONSE/GET-PROP-RESPONSE| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35: TLV for Query Response
図35：クエリ応答のためのTLV
Type:
タイプ：
The operation type for query response. One operation type is defined:
クエリ応答の操作タイプ。1つの操作タイプが定義されています。
Type = "GET-RESPONSE" - This operation is for the response of the GET operation of LFB components.
type = "get -response" - この操作は、LFBコンポーネントのGET操作の応答用です。
Type = "GET-PROP-RESPONSE" - This operation is for the response of the GET-PROP operation of LFB components.
type = "Get-Prop-Response" - この操作は、LFBコンポーネントのGet-Prop操作の応答用です。
PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE:
get-response/get-prop-response用のpath-data-tlv：
This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The PATH-DATA- TLV for the GET-RESPONSE operation MAY contain SPARSEDATA-TLV, FULLDATA-TLV, and/or RESULT-TLV(s) in the data encoding. The RESULT-TLV is defined in Section 7.1.7 and the SPARSEDATA-TLVs and FULLDATA-TLVs are defined in Section 7.1.8.
これは一般的に、Path-Data-TLV BNF定義のセクション7で定義されているPath-Data-TLV形式です。Get-Response操作のパスデータTLVには、データエンコーディングのSparsedata-TLV、Fulldata-TLV、および/またはresult-TLVが含まれている場合があります。結果TLVはセクション7.1.7で定義されており、Sparsedata-TLVとFulldata-TLVはセクション7.1.8で定義されています。
To better illustrate the above PDU format, a tree structure for the format is shown below:
上記のPDU形式をよりよく説明するために、形式のツリー構造を以下に示します。
main hdr (type = QueryResponse)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { GET-RESPONSE }
| |
| +-- // one or more path targets
|
+-- T = operation { GET-PROP-RESPONSE }
. |
. +-- // one or more path targets
.
Figure 36: PDU Format for Query Response Message
図36：クエリ応答メッセージのPDU形式
Event Notification message is used by the FE to asynchronously notify the CE of events that happen in the FE.
イベント通知メッセージは、FEでFEで使用され、FEで発生したイベントについてCEにCEに通知します。
All events that can be generated in an FE are subscribable by the CE. The CE can subscribe to an event via a Config message with the SET-PROP operation, where the included path specifies the event, as defined by the LFB Library and described by the FE Model.
FEで生成できるすべてのイベントは、CEによって購読可能です。CEは、LFBライブラリで定義され、FEモデルで記述されているように、インストールパスがイベントを指定したSET-PROP操作を備えた構成メッセージを介してイベントを購読できます。
As usual, an Event Notification message is composed of a common header and a message body that consists of one or more TLV data formats. Detailed description of the message is as follows:
いつものように、イベント通知メッセージは、1つ以上のTLVデータ形式で構成される共通ヘッダーとメッセージ本文で構成されています。メッセージの詳細な説明は次のとおりです。
Message transfer direction:
メッセージ転送方向：
FE to CE Message header:
FE TO CEメッセージヘッダー：
The Message Type in the message header is set to MessageType = 'EventNotification'. The ACK flag in the header MUST be ignored by the CE, and the Event Notification message does not expect any response from the receiver.
メッセージヘッダーのメッセージタイプは、messageType = 'eventNotification'に設定されています。ヘッダーのACKフラグはCEによって無視される必要があり、イベント通知メッセージではレシーバーからの応答は期待されません。
OPER-TLV for Event Notification:
イベント通知用のオペラス：
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 = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37: TLV for Event Notification
図37：イベント通知のためのTLV
Type:
タイプ：
Only one operation type is defined for the Event Notification message:
イベント通知メッセージに対して定義されている操作タイプは1つだけです。
Type = "REPORT" - This type of operation is for the FE to report something to the CE.
type = "Report" - このタイプの操作は、FEがCEに何かを報告するためのものです。
PATH-DATA-TLV for REPORT:
レポート用のpath-data-tlv：
This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The PATH-DATA- TLV for the REPORT operation MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s) but MUST NOT contain any RESULT-TLV in the data format.
これは一般的に、Path-Data-TLV BNF定義のセクション7で定義されているPath-Data-TLV形式です。レポート操作のPath-Data-TLVには、fulldata-tlvまたはSparsedata-tlvが含まれている場合がありますが、データ形式にresult-tlvを含めてはなりません。
To better illustrate the above PDU format, a tree structure for the format is shown below:
上記のPDU形式をよりよく説明するために、形式のツリー構造を以下に示します。
main hdr (type = Event Notification)
|
|
+--- T = LFBselect
|
+-- LFBCLASSID = target LFB class
|
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { REPORT }
| |
| +-- // one or more path targets
| // associated with FULL/SPARSE DATA TLV(s)
+-- T = operation { REPORT }
. |
. +-- // one or more path targets
. // associated with FULL/SPARSE DATA TLV(s)
Figure 38: PDU Format for Event Notification Message
図38：イベント通知メッセージのPDU形式
A Packet Redirect message is used to transfer data packets between the CE and FE. Usually, these data packets are control packets, but they may be just data path packets that need further (exception or high-touch) processing. It is also feasible that this message carries no data packets and rather just meta data.
パケットリダイレクトメッセージは、CEとFEの間にデータパケットを転送するために使用されます。通常、これらのデータパケットはコントロールパケットですが、さらに（例外またはハイタッチ）処理が必要なデータパスパケットのみである場合があります。また、このメッセージにはデータパケットが含まれておらず、むしろメタデータを搭載していることも可能です。
The Packet Redirect message data format is formatted as follows:
パケットリダイレクトメッセージデータ形式は、次のようにフォーマットされます。
Message transfer direction:
メッセージ転送方向：
CE to FE or FE to CE
CEからFEまたはFEへのCE
Message header:
メッセージヘッダー：
The Message Type in the header is set to MessageType= 'PacketRedirect'.
ヘッダーのメッセージタイプは、MessageType = 'packetRedirect'に設定されています。
Message body:
メッセージ本文：
This consists of one or more TLVs that contain or describe the packet being redirected. The TLV is specifically a Redirect TLV (with the TLV Type="Redirect"). Detailed data format of a Redirect TLV for a Packet Redirect message is as follows:
これは、リダイレクトされているパケットを含むか説明する1つ以上のTLVで構成されています。TLVは特にリダイレクトTLVです（TLV Type = "Redirect"を使用）。パケットリダイレクトメッセージのリダイレクト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 = Redirect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirect Data TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 39: Redirect_Data TLV
図39：Redirect_Data TLV
Meta Data TLV:
メタデータTLV：
This is a TLV that specifies meta data associated with followed redirected data. The TLV is as follows:
これは、フォローされたリダイレクトデータに関連付けられたメタデータを指定するTLVです。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 = METADATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 40: METADATA-TLV
図40：メタデータTLV
Meta Data ILV:
メタデータILV：
This is an Identifier-Length-Value format that is used to describe one meta data. The ILV has the format as:
これは、1つのメタデータを記述するために使用される識別子長値形式です。ILVには次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data Value |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41: Meta Data ILV
図41：メタデータILV
where Meta Data ID is an identifier for the meta data, which is statically assigned by the LFB definition.
ここで、メタデータIDは、LFB定義によって静的に割り当てられているメタデータの識別子です。
Redirect Data TLV:
データをリダイレクトするTLV：
This is a TLV describing one packet of data to be directed via the redirect operation. The TLV format is as follows:
これは、リダイレクト操作を介して指示されるデータの1つのパケットを記述するTLVです。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 = REDIRECTDATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirected Data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 42: Redirect Data TLV
図42：データTLVをリダイレクトします
Redirected Data:
リダイレクトデータ：
This field contains the packet that is to be redirected in network byte order. The packet should be 32 bits aligned as is the data for all TLVs. The meta data infers what kind of packet is carried in value field and therefore allows for easy decoding of data encapsulated.
このフィールドには、ネットワークバイトの順序でリダイレクトされるパケットが含まれています。すべてのTLVのデータと同様に、パケットは32ビットアライメントする必要があります。メタデータは、どのような種類のパケットが値フィールドに携帯されているかを誘導し、したがって、カプセル化されたデータの簡単な解読を可能にします。
To better illustrate the above PDU format, a tree structure for the format is shown below:
上記のPDU形式をよりよく説明するために、形式のツリー構造を以下に示します。
main hdr (type = PacketRedirect)
|
|
+--- T = Redirect
. |
. +-- T = METADATA-TLV
| |
| +-- Meta Data ILV
| |
| +-- Meta Data ILV
| .
| .
|
+-- T = REDIRECTDATA-TLV
|
+-- // Redirected Data
Figure 43: PDU Format for Packet Redirect Message
図43：パケットリダイレクトメッセージのPDU形式
The Heartbeat (HB) message is used for one ForCES element (FE or CE) to asynchronously notify one or more other ForCES elements in the same ForCES NE on its liveness. Section 4.3.3 describes the traffic-sensitive approach used.
ハートビート（HB）メッセージは、1つの力要素（FEまたはCE）に使用され、同じ力の1つまたは複数の他の力要素を非同期に通知します。セクション4.3.3では、使用される交通に敏感なアプローチについて説明します。
A Heartbeat message is sent by a ForCES element periodically. The parameterization and policy definition for heartbeats for an FE are managed as components of the FE Protocol Object LFB, and can be set by CE via a Config message. The Heartbeat message is a little different from other protocol messages in that it is only composed of a common header, with the message body left empty. A detailed description of the message is as follows:
ハートビートメッセージは、定期的に力要素によって送信されます。FEのハートビートのパラメーター化とポリシー定義は、FEプロトコルオブジェクトLFBのコンポーネントとして管理され、CEによって設定メッセージを介して設定できます。ハートビートメッセージは、他のプロトコルメッセージとは少し異なります。これは、一般的なヘッダーのみで構成されており、メッセージ本文が空のままになっています。メッセージの詳細な説明は次のとおりです。
Message transfer direction:
メッセージ転送方向：
FE to CE or CE to FE
ceまたはce to fe
Message header:
メッセージヘッダー：
The Message Type in the message header is set to MessageType = 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. The ACK flag in the header MUST be set to either 'NoACK' or 'AlwaysACK' when the HB is sent.
メッセージヘッダーのメッセージタイプは、messageType = 'heartbeat'に設定されています。セクション4.3.3では、使用されるHBメカニズムについて説明します。ヘッダーのACKフラグは、HBが送信されたときに「NOACK」または「AlwaysAck」のいずれかに設定する必要があります。
* When set to 'NoACK', the HB is not soliciting for a response.
* 「noack」に設定すると、HBは応答を求めていません。
* When set to 'AlwaysACK', the HB Message sender is always expecting a response from its receiver. According to the HB policies defined in Section 7.3.1, only the CE can send such an HB message to query FE liveness. For simplicity and because of the minimal nature of the HB message, the response to an HB message is another HB message, i.e., no specific HB Response message is defined. Whenever an FE receives an HB message marked with 'AlwaysACK' from the CE, the FE MUST send an HB message back immediately. The HB message sent by the FE in response to the 'AlwaysACK' MUST modify the source and destination IDs so that the ID of the FE is the source ID and the CE ID of the sender is the destination ID, and MUST change the ACK information to 'NoACK'. A CE MUST NOT respond to an HB message with 'AlwaysACK' set.
* 「AlwaysAck」に設定すると、HBメッセージ送信者は常に受信機からの応答を期待しています。セクション7.3.1で定義されているHBポリシーによると、CEのみがそのようなHBメッセージを送信することができます。簡単にし、HBメッセージの性質が最小限であるため、HBメッセージへの応答は別のHBメッセージです。つまり、特定のHB応答メッセージは定義されていません。FEがCEから「AlwaysAck」でマークされたHBメッセージを受信するたびに、FEはすぐにHBメッセージを返送する必要があります。FEが「AlwaysAck」に応じてFEが送信したHBメッセージは、FEのIDがソースIDであり、送信者のCE IDが宛先IDであり、ACK情報を変更する必要があるように、ソースと宛先IDを変更する必要があります。「noack」へ。CEは、「AlwaysAck」セットを使用してHBメッセージに応答してはなりません。
* When set to anything else other than 'NoACK' or 'AlwaysACK', the HB message is treated as if it was a 'NoACK'.
* 「noack」または「Alwaysack」以外の他のものに設定すると、HBメッセージは「noack」であるかのように扱われます。
The correlator field in the HB message header SHOULD be set accordingly when a response is expected so that a receiver can correlate the response correctly. The correlator field MAY be ignored if no response is expected.
HBメッセージヘッダーの相関フィールドは、応答が予想される場合にそれに応じて設定する必要があり、レシーバーが応答を正しく相関させることができます。応答が予想されない場合、相関器フィールドは無視される場合があります。
Message body:
メッセージ本文：
The message body is empty for the Heartbeat message.
メッセージ本文は、ハートビートメッセージのために空です。
The ForCES protocol provides mechanisms for CE redundancy and failover, in order to support High Availability as defined in [RFC3654]. FE redundancy and FE to FE interaction is currently out of scope of this document. There can be multiple redundant CEs and FEs in a ForCES NE. However, at any one time only one primary CE can control the FEs though there can be multiple secondary CEs. The FE and the CE PL are aware of the primary and secondary CEs. This information (primary, secondary CEs) is configured in the FE and in the CE PLs during pre-association by the FEM and the CEM respectively. Only the primary CE sends control messages to the FEs.
[RFC3654]で定義されているように、高可用性をサポートするために、Force Protocolは、CE冗長性とフェールオーバーのメカニズムを提供します。FEの冗長性とFEへのFEへの相互作用は現在、このドキュメントの範囲外です。力NEには複数の冗長CEとFESが存在する可能性があります。ただし、複数の二次CESが存在する可能性がありますが、一度にFESを制御できるのは一度に1つのプライマリCEのみです。FeとCe PLは、一次および二次CEを認識しています。この情報（プライマリ、セカンダリCE）は、FEとCEEMによる事前関連時にFEおよびCE PLSでそれぞれ構成されます。プライマリCEのみが制御メッセージをFESに送信します。
High Availability parameterization in an FE is driven by configuring the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1). The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE Heartbeat policy help in detecting connectivity problems between an FE and CE. The CE failover policy defines the reaction on a detected failure.
FEの高可用性パラメーター化は、FEプロトコルオブジェクトLFBの構成によって駆動されます（付録Bおよびセクション7.3.1を参照）。FEハートビート間隔、CEハートビートデッドインターバル、およびCEハートビートポリシーは、FEとCEの間の接続性の問題の検出に役立ちます。CEフェールオーバーポリシーは、検出された障害に関する反応を定義します。
Figure 44 extends the state machine illustrated in Figure 4 to allow for new states that facilitate connection recovery.
図44は、図4に示す状態マシンを拡張して、接続回復を促進する新しい状態を可能にします。
(CE issues Teardown || +-----------------+
Lost association) && | Pre-association |
CE failover policy = 0 | (Association |
+------------>-->-->| in +<----+
| | progress) | |
| CE issues +--------+--------+ |
| Association | | CFTI
| Setup V | timer
| ___________________+ | expires
| | |
| V ^
+-+-----------+ +-------+-----+
| | | Not |
| | (CE issues Teardown || | Associated |
| | Lost association) && | |
| Associated | CE failover policy = 1 | (May |
| | | Continue |
| |---------->------->------>| Forwarding)|
| | | |
+-------------+ +-------------+
^ V
| |
| CE issues |
| Association |
| Setup |
+_________________________________________+
Figure 44: FE State Machine Considering HA
図44：HAを考慮したFEステートマシン
Section 4.2 describes transitions between the pre-association, associated, and not associated states.
セクション4.2では、関連する状態、関連状態、および関連状態の事前協会間の遷移について説明します。
When communication fails between the FE and CE (which can be caused by either the CE or link failure but not FE related), either the TML on the FE will trigger the FE PL regarding this failure or it will be detected using the HB messages between FEs and CEs. The communication failure, regardless of how it is detected, MUST be considered as a loss of association between the CE and corresponding FE.
通信がFEとCEの間で失敗した場合（CEまたはリンク障害によって引き起こされる可能性がありますが、FE関連ではありません）、FEのTMLはこの障害に関してFE PLをトリガーするか、HBメッセージを使用して検出されます。FESおよびCES。通信障害は、それがどのように検出されたかに関係なく、CEと対応するFEの間の関連性の喪失と見なされる必要があります。
If the FE's FEPO CE failover policy is configured to mode 0 (the default), it will immediately transition to the pre-association phase. This means that if association is again established, all FE state will need to be re-established.
FEのFEPO CEフェールオーバーポリシーがモード0（デフォルト）に構成されている場合、すぐに前協会の段階に移行します。これは、関連性が再び確立された場合、すべてのFe状態を再確立する必要があることを意味します。
If the FE's FEPO CE failover policy is configured to mode 1, it indicates that the FE is capable of HA restart recovery. In such a case, the FE transitions to the not associated state and the CEFTI timer is started. The FE MAY continue to forward packets during this state. It MAY also recycle through any configured secondary CEs in a round-robin fashion. It first adds its primary CE to the tail of backup CEs and sets its primary CE to be the first secondary. It then attempts to associate with the CE designated as the new primary CE. If it fails to re-associate with any CE and the CEFTI expires, the FE then transitions to the pre-association state.
FEのFEPO CEフェールオーバーポリシーがモード1に構成されている場合、FEがHAの再起動回復が可能であることを示します。そのような場合、FEは関連していない状態に遷移し、CEFTIタイマーが開始されます。FEは、この状態の間に引き続きパケットを転送し続ける可能性があります。また、構成されたセカンダリCESを介してラウンドロビンの方法でリサイクルする場合があります。最初にバックアップCEの尾に主要なCEを追加し、主要なCEを最初のセカンダリに設定します。次に、新しいプライマリCEとして指定されたCEとの関連付けを試みます。CEとの再アソシブに失敗し、CEFTIが期限切れになった場合、FEは前協会前の状態に移行します。
If the FE, while in the not associated state, manages to reconnect to a new primary CE before CEFTI expires, it transitions to the associated state. Once re-associated, the FE tries to recover any state that may have been lost during the not associated state. How the FE achieves this is out of scope for this document.
FEが関連していない状態である間、CEFTIが期限切れになる前に新しいプライマリCEに再接続することができた場合、関連状態に移行します。再関連すると、FEは、関連していない状態で失われた可能性のある状態を回復しようとします。FEがこれを達成する方法は、このドキュメントの範囲外です。
Figure 45 below illustrates the ForCES message sequences that the FE uses to recover the connection.
以下の図45は、FEが接続を回復するために使用する力メッセージシーケンスを示しています。
FE CE Primary CE Secondary
| | |
| Asso Estb,Caps exchg | |
1 |<--------------------->| |
| | |
| All msgs | |
2 |<--------------------->| |
| | |
| | |
| FAILURE |
| |
| Asso Estb,Caps exchange |
3 |<------------------------------------------>|
| |
| Event Report (pri CE down) |
4 |------------------------------------------->|
| |
| All Msgs |
5 |<------------------------------------------>|
Figure 45: CE Failover for Report Primary Mode
図45：レポートプライマリモードのCEフェールオーバー
A CE-to-CE synchronization protocol would be needed to support fast failover as well as to address some of the corner cases; however, this will not be defined by the ForCES protocol as it is out of scope for this specification.
高速フェールオーバーをサポートするだけでなく、コーナーケースの一部に対処するために、CE-CE-CE-CY-CYNCHRONIZATIONプロトコルが必要です。ただし、これは、この仕様の範囲外であるため、Force Protocolによって定義されません。
An explicit message (a Config message setting primary CE component in the FE Protocol Object) from the primary CE can also be used to change the primary CE for an FE during normal protocol operation.
プライマリCEからの明示的なメッセージ（FEプロトコルオブジェクトのプライマリCEコンポーネントを設定する構成メッセージ設定）を使用して、通常のプロトコル操作中にFEのプライマリCEを変更することもできます。
Also note that the FEs in a ForCES NE could also use a multicast CE ID, i.e., they could be associated with a group of CEs (this assumes the use of a CE-CE synchronization protocol, which is out of scope for this specification). In this case, the loss of association would mean that communication with the entire multicast group of CEs has been lost. The mechanisms described above will apply for this case as well during the loss of association. If, however, the secondary CE was also using the multicast CE ID that was lost, then the FE will need to form a new association using a different CE ID. If the capability exists, the FE MAY first attempt to form a new association with the original primary CE using a different non-multicast CE ID.
また、力のFESはマルチキャストCE IDを使用する可能性があることに注意してください。つまり、CESのグループに関連付けられる可能性があります（これは、この仕様の範囲外であるCE-CE同期プロトコルの使用を想定しています）。この場合、関連性の喪失は、CESのマルチキャストグループ全体とのコミュニケーションが失われたことを意味します。上記のメカニズムは、関連性の喪失中にこのケースにも適用されます。ただし、セカンダリCEが失われたマルチキャストCE IDも使用していた場合、FEは別のCE IDを使用して新しい関連付けを形成する必要があります。機能が存在する場合、FEは最初に、異なる非マルチカストCE IDを使用して、元のプライマリCEとの新しい関連性を形成しようとすることができます。
TML level:
TMLレベル：
1. The TML controls logical connection availability and failover.
1. TMLは、論理接続の可用性とフェールオーバーを制御します。
2. The TML also controls peer HA management.
2. TMLは、ピアハ管理も制御します。
At this level, control of all lower layers, for example, transport level (such as IP addresses, MAC addresses, etc.) and associated links going down are the role of the TML.
このレベルでは、たとえば、輸送レベル（IPアドレス、MACアドレスなど）およびダウンする関連リンクなど、すべての下層の制御がTMLの役割です。
PL level:
PLレベル：
All other functionality, including configuring the HA behavior during setup, the CE IDs used to identify primary and secondary CEs, protocol messages used to report CE failure (Event Report), Heartbeat messages used to detect association failure, messages to change the primary CE (Config), and other HA-related operations described before, are the PL responsibility.
セットアップ中のHA動作の構成、プライマリおよびセカンダリCEの識別に使用されるCE ID、CE障害の報告に使用されるプロトコルメッセージ（イベントレポート）、関連性障害を検出するために使用されるハートビートメッセージ、プライマリCEを変更するためのメッセージ（構成）、および前述のその他のHA関連操作は、PLの責任です。
To put the two together, if a path to a primary CE is down, the TML would take care of failing over to a backup path, if one is available. If the CE is totally unreachable, then the PL would be informed and it would take the appropriate actions described earlier.
2つをまとめるために、プライマリCEへのパスがダウンしている場合、TMLは、使用可能な場合、バックアップパスに失敗することになります。CEがまったく到達できない場合、PLは通知され、前述の適切なアクションが必要になります。
The ForCES framework document [RFC3746], Section 8, goes into extensive detail on a variety of security threats, the possible effects of those threats on the protocol, and responses to those threats. This document does not repeat that discussion; the reader is referred to the ForCES framework document [RFC3746] for those details and how the ForCES architecture addresses them.
Force Framework Document [RFC3746]、セクション8は、さまざまなセキュリティの脅威、プロトコルに対する脅威の可能な影響、およびそれらの脅威に対する応答について広範囲に詳細に説明します。この文書はその議論を繰り返しません。読者は、これらの詳細とフォースアーキテクチャがそれらにどのように対処するかについて、Force Framework Document [RFC3746]を参照されます。
ForCES PL uses security services provided by the ForCES TML. The TML provides security services such as endpoint authentication service, message authentication service, and confidentiality service. Endpoint authentication service is invoked at the time of the pre-association connection establishment phase and message authentication is performed whenever the FE or CE receives a packet from its peer.
Forces PLは、Force TMLが提供するセキュリティサービスを使用しています。TMLは、エンドポイント認証サービス、メッセージ認証サービス、機密保持サービスなどのセキュリティサービスを提供しています。Endpoint認証サービスは、Pre-Association接続の確立フェーズの時点で呼び出され、FEまたはCEがピアからパケットを受け取るたびにメッセージ認証が実行されます。
The following are the general security mechanisms that need to be in place for ForCES PL.
以下は、部隊PLのために導入する必要がある一般的なセキュリティメカニズムです。
o Security mechanisms are session controlled -- that is, once the security is turned on depending upon the chosen security level (No Security, Authentication, Confidentiality), it will be in effect for the entire duration of the session.
o セキュリティメカニズムはセッション制御されています。つまり、選択したセキュリティレベル（セキュリティ、認証、機密性なし）に応じてセキュリティがオンになると、セッション全体で有効になります。
o An operator should configure the same security policies for both primary and backup FEs and CEs (if available). This will ensure uniform operations and avoid unnecessary complexity in policy configuration.
o オペレーターは、プライマリとバックアップの両方のFESとCESの両方に対して同じセキュリティポリシーを構成する必要があります（利用可能な場合）。これにより、均一な操作が保証され、ポリシー構成の不必要な複雑さを回避できます。
When "No Security" is chosen for ForCES protocol communication, both endpoint authentication and message authentication service needs to be performed by ForCES PL. Both these mechanism are weak and do not involve cryptographic operation. An operator can choose "No Security" level when the ForCES protocol endpoints are within a single box, for example.
「セキュリティなし」がフォースプロトコル通信に選択されている場合、エンドポイント認証とメッセージ認証サービスの両方をフォースPLによって実行する必要があります。これらのメカニズムは両方とも弱く、暗号化の操作は含まれません。たとえば、フォースプロトコルのエンドポイントが単一のボックス内にある場合、オペレーターは「セキュリティなし」レベルを選択できます。
In order to have interoperable and uniform implementation across various security levels, each CE and FE endpoint MUST implement this level.
さまざまなセキュリティレベルにわたって相互運用可能で均一な実装を行うには、各CEおよびFEエンドポイントがこのレベルを実装する必要があります。
What is described below (in Section 9.1.1 and Section 9.1.2) are error checks and not security procedures. The reader is referred to Section 9.2 for security procedures.
以下に説明するのは、セキュリティ手順ではなく、エラーチェックです。読者は、セキュリティ手順についてはセクション9.2を参照されます。
Each CE and FE PL maintains a list of associations as part of its configuration. This is done via the CEM and FEM interfaces. An FE MUST connect to only those CEs that are configured via the FEM; similarly, a CE should accept the connection and establish associations for the FEs which are configured via the CEM. The CE should validate the FE identifier before accepting the connections during the pre-association phase.
各CEとFE PLは、その構成の一部としてアソシエーションのリストを維持しています。これは、CEMおよびFEMインターフェイスを介して行われます。FEは、FEMを介して構成されているCESのみに接続する必要があります。同様に、CEは接続を受け入れ、CEMを介して構成されたFESの関連付けを確立する必要があります。CEは、前協会の段階で接続を受け入れる前に、FE識別子を検証する必要があります。
When a CE or FE initiates a message, the receiving endpoint MUST validate the initiator of the message by checking the common header CE or FE identifiers. This will ensure proper protocol functioning. This extra processing step is recommended even when the underlying TML layer security services exist.
CEまたはFEがメッセージを開始する場合、受信エンドポイントは、共通ヘッダーCEまたはFE識別子をチェックすることにより、メッセージの開始者を検証する必要があります。これにより、適切なプロトコル機能が確保されます。この追加の処理ステップは、基礎となるTMLレイヤーセキュリティサービスが存在する場合でも推奨されます。
This section is applicable if an operator wishes to use the TML security services. A ForCES TML MUST support one or more security services such as endpoint authentication service, message authentication service, and confidentiality service, as part of TML security layer functions. It is the responsibility of the operator to select an appropriate security service and configure security policies accordingly. The details of such configuration are outside the scope of the ForCES PL and are dependent on the type of transport protocol and the nature of the connection.
このセクションは、オペレーターがTMLセキュリティサービスの使用を希望する場合に適用されます。Force TMLは、TMLセキュリティレイヤー関数の一部として、Endpoint認証サービス、メッセージ認証サービス、機密保持サービスなどの1つ以上のセキュリティサービスをサポートする必要があります。適切なセキュリティサービスを選択し、それに応じてセキュリティポリシーを構成することは、オペレーターの責任です。このような構成の詳細は、Force PLの範囲外であり、輸送プロトコルの種類と接続の性質に依存しています。
All these configurations should be done prior to starting the CE and FE.
これらのすべての構成は、CEおよびFEを開始する前に実行する必要があります。
When certificates-based authentication is being used at the TML, the certificate can use a ForCES-specific naming structure as certificate names and, accordingly, the security policies can be configured at the CE and FE.
証明書ベースの認証がTMLで使用されている場合、証明書は証明書名として力固有の命名構造を使用でき、それに応じてセキュリティポリシーをCEおよびFEで構成できます。
The reader is asked to refer to specific TML documents for details on the security requirements specific to that TML.
読者は、そのTMLに固有のセキュリティ要件の詳細については、特定のTMLドキュメントを参照するよう求められます。
When TML security services are enabled, the ForCES TML performs endpoint authentication. Security association is established between CE and FE and is transparent to the ForCES PL.
TMLセキュリティサービスが有効になっている場合、Force TMLはエンドポイント認証を実行します。セキュリティ協会はCEとFEの間に確立され、部隊PLに透明です。
This is a TML-specific operation and is transparent to the ForCES PL. For details, refer to Section 5.
これはTML固有の操作であり、力PLに透過的です。詳細については、セクション5を参照してください。
This is a TML-specific operation and is transparent to the ForCES PL. For details, refer to Section 5.
これはTML固有の操作であり、力PLに透過的です。詳細については、セクション5を参照してください。
The authors of this document would like to acknowledge and thank the ForCES Working Group and especially the following: Furquan Ansari, Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M. Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Zsolt Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their contributions. We would also like to thank David Putzolu and Patrick Droz for their comments and suggestions on the protocol and for their infinite patience. We would also like to thank Sue Hares and Alia Atlas for extensive reviews of the document.
この文書の著者は、フォースワーキンググループ、特に以下に、フォースワーキンググループに感謝し、感謝します。Haraszti、Fenggen Jia、John C. Lin、Alistair Munro、Jeff Pickering、T。Sridhlar、Guangming Wang、Chaoping Wu、およびLily L. Yangの貢献。また、David PutzoluとPatrick Drozに、プロトコルに関するコメントと提案、そして彼らの無限の忍耐についても感謝したいと思います。また、ドキュメントの広範なレビューについては、Sue HaresとAlia Atlasに感謝します。
Alia Atlas did a wonderful job of shaping the document to make it more readable by providing the IESG feedback.
Alia Atlasは、IESGのフィードバックを提供することで、ドキュメントを形成して読みやすくするという素晴らしい仕事をしました。
Ross Callon was instrumental in getting us over major humps to getting this document published.
ロスコロンは、この文書を公開するために、私たちを主要なこぶを乗り越えるのに役立ちました。
The editors have used the xml2rfc [RFC2629] tools in creating this document and are very grateful for the existence and quality of these tools. The editor is also grateful to Elwyn Davies for his help in correcting the XML source of this document.
編集者は、このドキュメントの作成にXML2RFC [RFC2629]ツールを使用しており、これらのツールの存在と品質に非常に感謝しています。編集者は、このドキュメントのXMLソースを修正する際の彼の助けをしてくれたElwyn Daviesにも感謝しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, December 2008.
[RFC5390] Rosenberg、J。、「セッション開始プロトコルにおける過負荷の管理の要件」、RFC 5390、2008年12月。
[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.
[RFC5811] Hadi Salim、J。およびK. ogawa、「SCTPベースの輸送マッピング層（TML）の転送および制御要素分離（Force）プロトコルのための」、RFC 5811、2010年3月。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.
[RFC5812] Halpern、J。およびJ. Hadi Salim、「転送および制御要素分離（Force）転送要素モデル」、RFC 5812、2010年3月。
[2PCREF] Gray, J., "Notes on database operating systems", in "Operating Systems: An Advanced Course" Lecture Notes in Computer Science, Vol. 60, pp. 394-481, Springer-Verlag, 1978.
[2pcref] Gray、J。、「データベースオペレーティングシステムに関するノート」、「オペレーティングシステム：高度なコース」講義ノートのコンピューターサイエンス、Vol。60、pp。394-481、Springer-verlag、1978。
[ACID] Haerder, T. and A. Reuter, "Principles of Transaction-Orientated Database Recovery", 1983.
[酸] Haerder、T。およびA. Reuter、「トランザクション指向のデータベース回復の原則」、1983。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629] Rose、M。、「XMLを使用したI-DSおよびRFCの書き込み」、RFC 2629、1999年6月。
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3654] Khosravi、H。およびT. Anderson、「IP制御と転送の分離の要件」、RFC 3654、2003年11月。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004.
[RFC3746] Yang、L.、Dantu、R.、Anderson、T。、およびR. Gopal、「転送および制御要素分離（Forces）フレームワーク」、RFC 3746、2004年4月。
Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following namespaces are defined in ForCES.
「RFCSでIANAの考慮事項セクションを作成するためのガイドライン」（RFC 5226 [RFC5226]）で概説されているポリシーに続いて、次の名前空間が力で定義されています。
o Message Type Namespace, Section 7
o メッセージタイプ名空間、セクション7
o Operation Type Namespace, Section 7.1.6
o 操作タイプの名前空間、セクション7.1.6
o Header Flags, Section 6.1
o ヘッダーフラグ、セクション6.1
o TLV Type, Section 7
o TLVタイプ、セクション7
o TLV Result Values, Section 7.1.7
o TLV結果値、セクション7.1.7
o LFB Class ID, Section 7.1.5 (resolved by model document, [RFC5812].
o LFBクラスID、セクション7.1.5（モデルドキュメント、[RFC5812]によって解決されました。
o Result: Association Setup Response, Section 7.5.2
o 結果：アソシエーションのセットアップ応答、セクション7.5.2
o Reason: Association Teardown Message, Section 7.5.3
o 理由：協会の分解メッセージ、セクション7.5.3
The Message Type is an 8-bit value. The following is the guideline for defining the Message Type namespace:
メッセージタイプは8ビット値です。以下は、メッセージタイプ名空間を定義するためのガイドラインです。
Message Types 0x00 - 0x1F Message Types in this range are part of the base ForCES protocol. Message Types in this range are allocated through an IETF consensus action [RFC5226].
メッセージタイプこの範囲のメッセージタイプ0x00-0x1fメッセージタイプは、基本力プロトコルの一部です。この範囲のメッセージタイプは、IETFコンセンサスアクション[RFC5226]によって割り当てられます。
Values assigned by this specification:
この仕様によって割り当てられた値：
0x00 Reserved
0x01 AssociationSetup
0x02 AssociationTeardown
0x03 Config
0x04 Query
0x05 EventNotification
0x06 PacketRedirect
0x07 - 0x0E Reserved
0x0F Hearbeat
0x11 AssociationSetupResponse
0x12 Reserved
0x13 ConfigResponse
0x14 QueryResponse
Message Types 0x20 - 0x7F Message Types in this range are Specification Required [RFC5226]. Message Types using this range MUST be documented in an RFC or other permanent and readily available reference.
メッセージタイプこの範囲のメッセージタイプ0x20-0x7fメッセージタイプは、仕様が必要です[RFC5226]。この範囲を使用するメッセージタイプは、RFCまたはその他の永続的で容易に利用可能な参照に文書化する必要があります。
Message Types 0x80 - 0xFF Message Types in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Message Type namespace is unnecessary.
メッセージタイプこの範囲のメッセージタイプ0x80-0xffメッセージタイプは、ベンダーのプライベートエクステンション用に予約されており、個々のベンダーの責任です。この範囲のメッセージタイプ名空間のIANA管理は不要です。
The Operation Selection (OPER-TLV) namespace is 16 bits long. The following is the guideline for managing the OPER-TLV namespace.
操作選択（Oper-TLV）名前空間の長さは16ビットです。以下は、Oper-TLVネームスペースを管理するためのガイドラインです。
OPER-TLV Type 0x0000-0x0FF OPER-TLV Types in this range are allocated through an IETF consensus process [RFC5226].
この範囲のOper-TLV Type 0x0000-0X0FFFFFFOPTLVタイプは、IETFコンセンサスプロセス[RFC5226]を通じて割り当てられています。
Values assigned by this specification:
この仕様によって割り当てられた値：
0x0000 Reserved
0x0001 SET
0x0002 SET-PROP
0x0003 SET-RESPONSE
0x0004 SET-PROP-RESPONSE
0x0005 DEL
0x0006 DEL-RESPONSE
0x0007 GET
0x0008 GET-PROP
0x0009 GET-RESPONSE
0x000A GET-PROP-RESPONSE
0x000B REPORT
0x000C COMMIT
0x000D COMMIT-RESPONSE
0x000E TRCOMP
OPER-TLV Type 0x0100-0x7FFF OPER-TLV Types using this range MUST be documented in an RFC or other permanent and readily available reference [RFC5226].
この範囲を使用したOper-TLVタイプ0x0100-0x7FFFオペ-TLVタイプは、RFCまたはその他の永続的で容易に利用可能な参照[RFC5226]で文書化する必要があります。
OPER-TLV Type 0x8000-0xFFFF OPER-TLV Types in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the OPER-TLV Type namespace is unnecessary.
この範囲のOper-TLVタイプ0x8000-0xffffオペラ型タイプは、ベンダーのプライベートエクステンション用に予約されており、個々のベンダーの責任です。Oper-TLVタイプの名前空間のこの範囲のIANA管理は不要です。
The Header flag field is 32 bits long. Header flags are part of the ForCES base protocol. Header flags are allocated through an IETF consensus action [RFC5226].
ヘッダーフラグフィールドの長さは32ビットです。ヘッダーフラグは、フォースベースプロトコルの一部です。ヘッダーフラグは、IETFコンセンサスアクション[RFC5226]によって割り当てられます。
The TLV Type namespace is 16 bits long. The following is the guideline for managing the TLV Type namespace.
TLVタイプの名前空間の長さは16ビットです。以下は、TLVタイプの名前空間を管理するためのガイドラインです。
TLV Type 0x0000-0x01FF TLV Types in this range are allocated through an IETF consensus process [RFC5226].
この範囲のTLVタイプ0x0000-0x01FF TLVタイプは、IETFコンセンサスプロセス[RFC5226]を通じて割り当てられています。
Values assigned by this specification:
この仕様によって割り当てられた値：
0x0000 Reserved
0x0001 REDIRECT-TLV
0x0010 ASResult-TLV
0x0011 ASTreason-TLV
0x1000 LFBselect-TLV
0x0110 PATH-DATA-TLV
0x0111 KEYINFO-TLV
0x0112 FULLDATA-TLV
0x0113 SPARSEDATA-TLV
0x0114 RESULT-TLV
0x0115 METADATA-TLV
0x0116 REDIRECTDATA-TLV
TLV Type 0x0200-0x7FFF TLV Types using this range MUST be documented in an RFC or other permanent and readily available reference [RFC5226].
この範囲を使用したTLVタイプ0x0200-0x7FFF TLVタイプは、RFCまたはその他の永続的で容易に利用可能な参照[RFC5226]で文書化する必要があります。
TLV Type 0x8000-0xFFFF TLV Types in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the TLV Type namespace is unnecessary.
この範囲のTLVタイプ0x8000-0xffff TLVタイプは、ベンダーのプライベートエクステンション専用であり、個々のベンダーの責任です。TLVタイプの名前空間のこの範囲のIANA管理は不要です。
The RESULT-TLV RTesult Value is an 8-bit value.
結果-TLV rtesult値は8ビット値です。
0x00 E_SUCCESS 0x01 E_INVALID_HEADER 0x02 E_LENGTH_MISMATCH 0x03 E_VERSION_MISMATCH 0x04 E_INVALID_DESTINATION_PID 0x05 E_LFB_UNKNOWN 0x06 E_LFB_NOT_FOUND 0x07 E_LFB_INSTANCE_ID_NOT_FOUND 0x08 E_INVALID_PATH 0x09 E_COMPONENT_DOES_NOT_EXIST 0x0A E_EXISTS 0x0B E_NOT_FOUND 0x0C E_READ_ONLY 0x0D E_INVALID_ARRAY_CREATION 0x0E E_VALUE_OUT_OF_RANGE 0x0F E_CONTENTS_TOO_LONG 0x10 E_INVALID_PARAMETERS 0x11 E_INVALID_MESSAGE_TYPE 0x12 E_E_INVALID_FLAGS 0x13 E_INVALID_TLV 0x14 E_EVENT_ERROR 0x15 E_NOT_SUPPORTED 0x16 E_MEMORY_ERROR 0x17 E_INTERNAL_ERROR 0x18-0xFE Reserved 0xFF E_UNSPECIFIED_ERROR
0xfe予約済み0xff e_unspecified_error
All values not assigned in this specification are designated as Assignment by Expert Review.
この仕様で割り当てられていないすべての値は、専門家のレビューにより割り当てとして指定されます。
The Association Setup Response namespace is 32 bits long. The following is the guideline for managing the Association Setup Response namespace.
Association Setup Response NameSpaceの長さは32ビットです。以下は、Association Setup Response Namespaceを管理するためのガイドラインです。
Association Setup Response 0x0000-0x00FF Association Setup Responses in this range are allocated through an IETF consensus process [RFC5226].
アソシエーションのセットアップ応答0x0000-0x00FFアソシエーションのセットアップ応答は、IETFコンセンサスプロセス[RFC5226]によって割り当てられます。
Values assigned by this specification:
この仕様によって割り当てられた値：
0x0000 Success 0x0001 FE ID Invalid 0x0002 Permission Denied
0x0000成功0x0001 FE ID無効0x0002許可が拒否されました
Association Setup Response 0x0100-0x0FFF Association Setup Responses in this range are Specification Required [RFC5226]. Values using this range MUST be documented in an RFC or other permanent and readily available reference [RFC5226].
アソシエーションセットアップ応答0x0100-0x0FFFアソシエーションのセットアップこの範囲の応答は、仕様が必要です[RFC5226]。この範囲を使用した値は、RFCまたは他の永続的で容易に利用可能な参照[RFC5226]に文書化する必要があります。
Association Setup Response 0x1000-0xFFFF Association Setup Responses in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Association Setup Response namespace is unnecessary.
協会のセットアップ応答0x1000-0xffffアソシエーションのセットアップ応答この範囲は、ベンダーのプライベートエクステンション用に予約されており、個々のベンダーの責任です。Associationセットアップ応答名のこの範囲のIANA管理は不要です。
The Association Teardown Message namespace is 32 bits long. The following is the guideline for managing the Association Teardown Message namespace.
協会の分解メッセージ名空間の長さは32ビットです。以下は、アソシエーションの分解メッセージ名空間を管理するためのガイドラインです。
Association Teardown Message 0x00000000-0x0000FFFF Association Teardown Messages in this range are allocated through an IETF consensus process [RFC5226].
協会の分解メッセージ0x00000000-0X0000FFFFFASTARSAITIONこの範囲での分解メッセージは、IETFコンセンサスプロセス[RFC5226]を通じて割り当てられています。
Values assigned by this specification:
この仕様によって割り当てられた値：
0x00000000 Normal - teardown by administrator 0x00000001 Error - loss of heartbeats 0x00000002 Error - loss of bandwidth 0x00000003 Error - out of Memory 0x00000004 Error - application crash 0x000000FF Error - unspecified
0x00000000ノーマル - 管理者による分解0x00000001エラー - ハートビートの損失0x00000002エラー - 帯域幅の損失0x00000003エラー - メモリ外0x00000004エラー - アプリケーションクラッシュ0x000000ffエラー
Association Teardown Message 0x00010000-0x7FFFFFFF Association Teardown Messages in this range are Specification Required [RFC5226]. Association Teardown Messages using this range MUST be documented in an RFC or other permanent and readily available references. [RFC5226].
協会の分解メッセージ0x00010000-0x7FFFFFFFアソシエーションこの範囲の分解メッセージは、仕様が必要です[RFC5226]。この範囲を使用した協会の分解メッセージは、RFCまたはその他の永続的で容易に利用可能な参照に文書化する必要があります。[RFC5226]。
Association Teardown Message 0x80000000-0xFFFFFFFFF Association Teardown Messages in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Association Teardown Message namespace is unnecessary.
協会の分解メッセージ0x80000000-0xffffffffff Associationこの範囲での断片的なメッセージは、ベンダーのプライベートエクステンションのために予約されており、個々のベンダーの責任です。協会のこの範囲のIANA管理断片化メッセージ名空間は不要です。
The schema described below conforms to the LFB schema described in the ForCES model [RFC5812].
以下に説明するスキーマは、力モデル[RFC5812]に記載されているLFBスキーマに準拠しています。
Section 7.3.1 describes the details of the different components defined in this definition.
セクション7.3.1では、この定義で定義されているさまざまなコンポーネントの詳細について説明します。
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
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 heartbeat policy 0
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEHBPolicy1</name>
<synopsis>
The CE heartbeat policy 1
</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 heartbeat policy 0
</synopsis>
</specialValue>
<specialValue value="1">
<name>FEHBPolicy1</name>
<synopsis>
The FE heartbeat policy 1
</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 restart policy 0
</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 CE failover policy 0
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEFailoverPolicy1</name>
<synopsis>
The CE failover policy 1
</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>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="2">
<name>FEPO</name>
<synopsis>
The FE Protocol Object
</synopsis>
<version>1.0</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 millisecs
</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 millisecs
</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 millisecs
</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>
</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>
</capabilities>
<events baseID="61">
<event eventID="1">
<name>PrimaryCEDown</name>
<synopsis>
The pimary CE has changed
</synopsis>
<eventTarget>
<eventField>LastCEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>LastCEID</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
Supportable Versions enumerates all ForCES versions that an FE supports.
サポート可能なバージョンは、FEがサポートするすべての力バージョンを列挙します。
FEHACapab enumerates the HA capabilities of the FE. If the FE is not capable of graceful restarts or HA, then it will not be able to participate in HA as described in Section 8.1.
Fehacapabは、FeのHA機能を列挙しています。FEが優雅な再起動またはHAができない場合、セクション8.1で説明されているようにHAに参加することはできません。
All components are explained in Section 7.3.1.
すべてのコンポーネントについては、セクション7.3.1で説明しています。
In this section a few examples of data encoding are discussed. These example, however, do not show any padding.
このセクションでは、データエンコードの例について説明します。ただし、これらの例にはパディングは表示されません。
==========
Example 1:
==========
Structure with three fixed-lengthof, mandatory fields.
3つの固定長の必須フィールドを持つ構造。
struct S {
uint16 a
uint16 b
uint16 c
}
(a) Describing all fields using SPARSEDATA-TLV
(a) Sparsedata-TLVを使用してすべてのフィールドを記述します
PATH-DATA-TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
(b) Describing a subset of fields
(b) フィールドのサブセットを説明します
PATH-DATA-TLV Path to an instance of S ... SPARSEDATA-TLV ComponentIDof(a), lengthof(a), valueof(a) ComponentIDof(c), lengthof(c), valueof(c)
sのインスタンスへのpath-data-tlvパス... sparsedata-tlv componentidof（a）、lengthof（a）、valueof（a）componentidof（c）、lengthof（c）、valueof（c）
Note: Even though there are non-optional components in structure S, since one can uniquely identify components, one can selectively send components of structure S (e.g., in the case of an update from CE to FE).
注：構造Sには非感受性コンポーネントがありますが、コンポーネントを一意に識別できるため、構造Sのコンポーネントを選択的に送信できます（たとえば、CEからFEへの更新の場合）。
(c) Describing all fields using a FULLDATA-TLV
(c) fulldata-tlvを使用してすべてのフィールドを記述します
PATH-DATA-TLV Path to an instance of S ... FULLDATA-TLV valueof(a) valueof(b) valueof(c)
sのインスタンスへのpath-data-tlvパス... fulldata-tlv値（a）（b）値の値（c）
==========
Example 2:
==========
Structure with three fixed-lengthof fields, one mandatory, two optional.
3つの固定長、1つの必須、2つのオプションを備えた構造。
struct T {
uint16 a
uint16 b (optional)
uint16 c (optional)
}
This example is identical to example 1, as illustrated below.
この例は、以下に示すように、例1と同じです。
(a) Describing all fields using SPARSEDATA-TLV
(a) Sparsedata-TLVを使用してすべてのフィールドを記述します
PATH-DATA-TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
(b) Describing a subset of fields using SPARSEDATA-TLV
(b) Sparsedata-TLVを使用してフィールドのサブセットを記述します
PATH-DATA-TLV Path to an instance of S ... SPARSEDATA-TLV ComponentIDof(a), lengthof(a), valueof(a) ComponentIDof(c), lengthof(c), valueof(c)
sのインスタンスへのpath-data-tlvパス... sparsedata-tlv componentidof（a）、lengthof（a）、valueof（a）componentidof（c）、lengthof（c）、valueof（c）
(c) Describing all fields using a FULLDATA-TLV
(c) fulldata-tlvを使用してすべてのフィールドを記述します
PATH-DATA-TLV Path to an instance of S ... FULLDATA-TLV valueof(a) valueof(b) valueof(c)
sのインスタンスへのpath-data-tlvパス... fulldata-tlv値（a）（b）値の値（c）
Note: FULLDATA-TLV _cannot_ be used unless all fields are being described.
注：すべてのフィールドが記載されていない限り、fulldata-tlv _cannot_使用します。
==========
Example 3:
==========
Structure with a mix of fixed-lengthof and variable-lengthof fields, some mandatory, some optional. Note in this case, b is variable sized.
固定長と可変長のフィールドが混在している構造、いくつかの必須、いくつかのオプション。注この場合、Bは可変サイズです。
struct U {
uint16 a
string b (optional)
uint16 c (optional)
}
(a) Describing all fields using SPARSEDATA-TLV
(a) Sparsedata-TLVを使用してすべてのフィールドを記述します
Path to an instance of U ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
(b) Describing a subset of fields using SPARSEDATA-TLV
(b) Sparsedata-TLVを使用してフィールドのサブセットを記述します
Path to an instance of U ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)
(c) Describing all fields using FULLDATA-TLV
(c) fulldata-tlvを使用してすべてのフィールドを記述します
Path to an instance of U ... FULLDATA-TLV valueof(a) FULLDATA-TLV valueof(b) valueof(c)
uのインスタンスへのパス... fulldata-tlv値（a）fulldata-tlv値（b）valueof（c）
Note: The variable-length field requires the addition of a FULLDATA-TLV within the outer FULLDATA-TLV as in the case of component b above.
注：可変長フィールドには、上記のコンポーネントBの場合のように、外側のfulldata-tlv内にfulldata-tlvを追加する必要があります。
==========
Example 4:
==========
Structure containing an array of another structure type.
別の構造タイプの配列を含む構造。
struct V {
uint32 x
uint32 y
struct U z[]
}
(a) Encoding using SPARSEDATA-TLV, with two instances of z[], also described with SPARSEDATA-TLV, assuming only the 10th and 15th subscripts of z[] are encoded.
(a) Sparsedata-TLVを使用して、Z []の2つのインスタンスを使用してエンコードします。これは、Z []の10番目と15番目のサブスクリプトのみがエンコードされていると仮定して、Sparsedata-TLVでも記述されています。
path to instance of V ...
SPARSEDATA-TLV
ComponentIDof(x), lengthof(x), valueof(x)
ComponentIDof(y), lengthof(y), valueof(y)
ComponentIDof(z), lengthof(all below)
ComponentID = 10 (i.e index 10 from z[]), lengthof(all below)
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentID = 15 (index 15 from z[]), lengthof(all below)
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)
Note the holes in the components of z (10 followed by 15). Also note the gap in index 15 with only components a and c appearing but not b.
Zのコンポーネントの穴に注意してください（10に続いて15）。また、コンポーネントAとCのみが表示されますが、bではなく、インデックス15のギャップに注意してください。
Assume LFB with the following components for the following use cases.
次のユースケースについて、次のコンポーネントを使用してLFBを仮定します。
foo1, type u32, ID = 1
FOO1、タイプU32、ID = 1
foo2, type u32, ID = 2
FOO2、タイプU32、ID = 2
table1: type array, ID = 3
components are:
t1, type u32, ID = 1
t2, type u32, ID = 2 // index into table2
KEY: nhkey, ID = 1, V = t2
table2: type array, ID = 4
components are:
j1, type u32, ID = 1
j2, type u32, ID = 2
KEY: akey, ID = 1, V = { j1,j2 }
table3: type array, ID = 5 components are: someid, type u32, ID = 1 name, type string variable sized, ID = 2
表3：タイプ配列、id = 5コンポーネントは次のとおりです。someid、type u32、id = 1 name、type string variableサイズ、id = 2
table4: type array, ID = 6
components are:
j1, type u32, ID = 1
j2, type u32, ID = 2
j3, type u32, ID = 3
j4, type u32, ID = 4
KEY: mykey, ID = 1, V = { j1}
table5: type array, ID = 7 components are: p1, type u32, ID = 1 p2, type array, ID = 2, array components of type-X
表5：タイプ配列、ID = 7コンポーネントは次のとおりです。P1、タイプU32、ID = 1 P2、タイプ配列、ID = 2、タイプXの配列コンポーネント
Type-X:
x1, ID 1, type u32
x2, ID2 , type u32
KEY: tkey, ID = 1, V = { x1}
All examples will use valueof(x) to indicate the value of the referenced component x. In the case where F_SEL** are missing (bits equal to 00) then the flags will not show any selection.
すべての例では、値（x）を使用して、参照されるコンポーネントxの値を示します。f_sel **が欠落している場合（ビット00に等しい）、フラグには選択が表示されません。
All the examples only show use of FULLDATA-TLV for data encoding; although SPARSEDATA-TLV would make more sense in certain occasions, the emphasis is on showing the message layout. Refer to Appendix C for examples that show usage of both FULLDATA-TLV and SPARSEDATA-TLV.
すべての例は、データエンコーディングにFulldata-TLVの使用のみを示しています。Sparsedata-TLVは特定の場合にはより理にかなっていますが、メッセージレイアウトを表示することに重点が置かれています。fulldata-tlvとSparsedata-tlvの両方の使用を示す例については、付録Cを参照してください。
1. To get foo1
1. foo1を取得します
OPER = GET-TLV
PATH-DATA-TLV: IDCount = 1, IDs = 1
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags=0, IDCount = 1, IDs = 1
FULLDATA-TLV L = 4+4, V = valueof(foo1)
2. To set foo2 to 10
2. FOO2を10に設定します
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV: L = 4+4, V=10
Result: OPER = SET-RESPONSE-TLV PATH-DATA-TLV: flags = 0, IDCount = 1, IDs = 2 RESULT-TLV
結果：oper = set-response-tlv path-data-tlv：flags = 0、idcount = 1、ids = 2 result-tlv
3. To dump table2
3. Table2をダンプするには
OPER = GET-TLV
PATH-DATA-TLV:
IDCount = 1, IDs = 4
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV: L = XXX, V=
a series of: index, valueof(j1), valueof(j2)
representing the entire table
Note: One should be able to take a GET-RESPONSE-TLV and convert it to a SET-TLV. If the result in the above example is sent back in a SET-TLV (instead of a GET-RESPONSE_TLV), then the entire contents of the table will be replaced at that point.
注：get-response-tlvを取得して、それをset-tlvに変換できるはずです。上記の例の結果が（get-response_tlvの代わりに）set-tlvで送信される場合、その時点でテーブルの内容全体が交換されます。
4. Multiple operations example. To create entry 0-5 of table2 (Error conditions are ignored)
4. 複数の操作の例。Table2のエントリ0-5を作成するには（エラー条件は無視されます）
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV valueof(j1), valueof(j2) of entry 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV valueof(j1), valueof(j2) of entry 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV valueof(j1), valueof(j2) of entry 2
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV valueof(j1), valueof(j2) of entry 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV valueof(j1), valueof(j2) of entry 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
FULLDATA-TLV valueof(j1), valueof(j2) of entry 5
Result:
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
RESULT-TLV
5. Block operations (with holes) example. Replace entry 0,2 of table2.
5. ブロック操作（穴付き）例。表2のエントリ0,2を交換します。
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV containing valueof(j1), valueof(j2) of 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV containing valueof(j1), valueof(j2) of 2
Result:
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
6. Getting rows example. Get first entry of table2.
6. 行の例。Table2の最初のエントリを取得します。
OPER = GET-TLV PATH-DATA-TLV: IDCount = 2, IDs = 4.0
oper = get-tlv path-data-tlv：idcount = 2、ids = 4.0
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
IDCount = 2, IDs = 4.0
FULLDATA-TLV containing valueof(j1), valueof(j2)
7. Get entry 0-5 of table2.
7. 表2のエントリ0-5を取得します。
OPER = GET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
FULLDATA-TLV containing valueof(j1), valueof(j2)
8. Create a row in table2, index 5.
8. Table2、インデックス5に行を作成します。
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 2, IDs = 4.5
FULLDATA-TLV containing valueof(j1), valueof(j2)
Result: OPER = SET-RESPONSE-TLV PATH-DATA-TLV: flags = 0, IDCount = 1, IDs = 4.5 RESULT-TLV
結果：oper = set-response-tlv path-data-tlv：flags = 0、idcount = 1、ids = result-tlv
9. Dump contents of table1.
9. テーブル1のコンテンツをダンプします。
OPER = GET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 3
Result: OPER = GET-RESPONSE-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 3 FULLDATA-TLV, Length = XXXX (depending on size of table1) index, valueof(t1),valueof(t2) index, valueof(t1),valueof(t2) . . .
結果：oper = get-response-tlv path-data-tlv flags = 0、idcount = 1、ids = 3 fulldata-tlv、length = xxxx（table1のサイズに依存）index、valueof（t1）、valueof（t2）index、valueof（t1）、valueof（t2）。。。
10. Using keys. Get row entry from table4 where j1=100. Recall, j1 is a defined key for this table and its KeyID is 1.
10. キーを使用します。J1 = 100ここで、表4から行エントリを取得します。思い出してください、J1はこのテーブルの定義されたキーであり、そのキーIDは1です。
OPER = GET-TLV
PATH-DATA-TLV:
flags = F_SELKEY IDCount = 1, IDs = 6
KEYINFO-TLV = KeyID=1, KEY_DATA=100
Result:
If j1=100 was at index 10
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 6.10
FULLDATA-TLV containing
valueof(j1), valueof(j2),valueof(j3),valueof(j4)
11. Delete row with KEY match (j1=100, j2=200) in table2. Note that the j1,j2 pair is a defined key for the table2.
11. 表2のキーマッチ（J1 = 100、J2 = 200）で行を削除します。J1、J2ペアは、Table2の定義鍵であることに注意してください。
OPER = DEL-TLV
PATH-DATA-TLV:
flags = F_SELKEY IDCount = 1, IDs = 4
KEYINFO-TLV: {KeyID =1 KEY_DATA=100,200}
Result:
If (j1=100, j2=200) was at entry 15:
OPER = DELETE-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0 IDCount = 2, IDs = 4.15
RESULT-TLV
12. Dump contents of table3. It should be noted that this table has a column with a component name that is variable sized. The purpose of this use case is to show how such a component is to be encoded.
12. 表3のコンテンツをダンプします。このテーブルには、可変サイズのコンポーネント名が付いた列があることに注意する必要があります。このユースケースの目的は、そのようなコンポーネントがどのようにエンコードされるかを示すことです。
OPER = GET-TLV
PATH-DATA-TLV:
flags = 0 IDCount = 1, IDs = 5
Result: OPER = GET-RESPONSE-TLV PATH-DATA-TLV: flags = 0 IDCount = 1, IDs = 5 FULLDATA-TLV, Length = XXXX index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), V = valueof(v) index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), V = valueof(v) index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), V = valueof(v) index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), V = valueof(v) . . .
結果：oper = get-response-tlv path-data-tlv：flags = 0 idcount = 1、ids = 5 fulldata-tlv、length = xxxx index、someidv、tlv：t = fulldata-tlv、l = 4 strlen（namev）、v = valueof（v）index、someidv、tlv：t = fulldata-tlv、l = 4 strlen（namev）、v = valueof（v）index、someidv、tlv：t = fulldata-tlv、l = 4 strlen（namev）、v = valueof（v）index、someidv、tlv：t = fulldata-tlv、l = 4 strlen（namev）、v = valueof（v）。。。
13. Multiple atomic operations.
13. 複数の原子操作。
Note 1: This emulates adding a new nexthop entry and then atomically updating the L3 entries pointing to an old NH to point to a new one. The assumption is that both tables are in the same LFB.
注1：これにより、新しいNexthopエントリを追加してから、古いNHを指すL3エントリを原子的に更新して、新しいNHを指し示します。仮定は、両方のテーブルが同じLFBにあることです。
Note: Observe the two operations on the LFB instance; both are SET operations.
注：LFBインスタンスで2つの操作を観察します。どちらも設定操作です。
//Operation 1: Add a new entry to table2 index #20.
OPER = SET-TLV
Path-TLV:
flags = 0, IDCount = 2, IDs = 4.20
FULLDATA-TLV, V= valueof(j1),valueof(j2)
// Operation 2: Update table1 entry which
// was pointing with t2 = 10 to now point to 20
OPER = SET-TLV
PATH-DATA-TLV:
flags = F_SELKEY, IDCount = 1, IDs = 3
KEYINFO-TLV = KeyID=1 KEY_DATA=10
PATH-DATA-TLV
flags = 0 IDCount = 1, IDs = 2
FULLDATA-TLV, V= 20
Result:
//first operation, SET
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 3, IDs = 4.20
RESULT-TLV code = success
FULLDATA-TLV, V = valueof(j1),valueof(j2)
// second operation SET - assuming entry 16 was updated
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs = 3.16
PATH-DATA-TLV
flags = 0 IDCount = 1, IDs = 2
RESULT-TLV code = success
FULLDATA-TLV, Length = XXXX v=20
14. Selective setting. On table4 -- for indices 1, 3, 5, 7, and 9. Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is.
14. 選択的設定。表4では、インデックス1、3、5、7、および9の場合。J1を100に、J2から200、J3から300に置き換えます。J4をそのまま残します。
PER = SET-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 6
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 7
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 9
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
response:
応答：
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 6
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 7
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 9
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
15. Manipulation of table of table examples. Get x1 from table10 row with index 4, inside table5 entry 10.
15. 表のテーブルの操作。Table5エントリ10内のインデックス4を備えたTable10行からx1を取得します。
operation = GET-TLV PATH-DATA-TLV flags = 0 IDCount = 5, IDs=7.10.2.4.1
Operation = get-tlv path-data-tlv flags = 0 idcount = 5、ids = 7.10.2.4.1
Results:
operation = GET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 5, IDs=7.10.2.4.1
FULLDATA-TLV: L=XXXX, V = valueof(x1)
16. From table5's row 10 table10, get X2s based on the value of x1 equaling 10 (recall x1 is KeyID 1).
16. Table5の行10 Table10から、10のx1の値に基づいてx2sを取得します（x1はkeyid 1です）。
operation = GET-TLV
PATH-DATA-TLV
flag = F_SELKEY, IDCount=3, IDS = 7.10.2
KEYINFO-TLV, KeyID = 1, KEYDATA = 10
PATH-DATA-TLV
IDCount = 1, IDS = 2 //select x2
Results:
If x1=10 was at entry 11:
operation = GET-RESPONSE-TLV
PATH-DATA-TLV
flag = 0, IDCount=5, IDS = 7.10.2.11
PATH-DATA-TLV
flags = 0 IDCount = 1, IDS = 2
FULLDATA-TLV: L=XXXX, V = valueof(x2)
17. Further example of manipulating a table of tables
17. テーブルのテーブルを操作するさらなる例
Consider table6, which is defined as: table6: type array, ID = 8 components are: p1, type u32, ID = 1 p2, type array, ID = 2, array components of type type-A
次のように定義されている表6を考えてみましょう：table6：タイプ配列、ID = 8コンポーネントは次のとおりです。
type-A: a1, type u32, ID 1, a2, type array ID2 ,array components of type type-B
タイプA：A1、タイプU32、ID 1、A2、タイプアレイID2、タイプタイプ-Bの配列コンポーネント
type-B: b1, type u32, ID 1 b2, type u32, ID 2
タイプB：B1、タイプU32、ID 1 B2、タイプU32、ID 2
If for example one wanted to set by replacing: table6.10.p1 to 111 table6.10.p2.20.a1 to 222 table6.10.p2.20.a2.30.b1 to 333
たとえば、Table6.10.p1から111 table6.10.p2.20.a1から222 table6.10.p2.20.a220.b1から333を交換して設定したい場合
in one message and one operation.
1つのメッセージと1つの操作。
There are two ways to do this: a) using nesting b) using a flat path data
これを行うには2つの方法があります。a）ネスティングの使用b）フラットパスデータの使用
A. Method using nesting in one message with a single operation
A.単一の操作で1つのメッセージでネストを使用する方法
operation = SET-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=6.10
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
FULLDATA-TLV: L=XXXX,
V = {111}
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=2.20
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
FULLDATA-TLV: L=XXXX,
V = {222}
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=2.30.1
FULLDATA-TLV: L=XXXX,
V = {333}
Result:
operation = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=6.10
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
RESULT-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=2.20
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
RESULT-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=2.30.1
RESULT-TLV
B. Method using a flat path data in one message with a single operation
B.単一の操作で1つのメッセージにフラットパスデータを使用する方法
operation = SET-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=6.10.1
FULLDATA-TLV: L=XXXX,
V = {111}
PATH-DATA-TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1
FULLDATA-TLV: L=XXXX,
V = {222}
PATH-DATA-TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
FULLDATA-TLV: L=XXXX,
V = {333}
Result:
operation = SET-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=6.10.1
RESULT-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1
RESULT-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
RESULT-TLV
18. Get a whole LFB (all its components, etc.).
18. LFB全体（すべてのコンポーネントなど）を取得します。
For example: At startup a CE might well want the entire FE Object LFB. So, in a request targeted at class 1, instance 1, one might find:
たとえば、スタートアップでは、CEはFEオブジェクトLFB全体が必要になる場合があります。したがって、クラス1、インスタンス1をターゲットにしたリクエストでは、次のことを見つけるかもしれません。
operation = GET-TLV PATH-DATA-TLV flags = 0 IDCount = 0
操作= get-tlv path-data-tlvフラグ= 0 idcount = 0
result: operation = GET-RESPONSE-TLV PATH-DATA-TLV flags = 0 IDCount = 0 FULLDATA-TLV encoding of the FE Object LFB
結果：operation = get-response-tlv path-data-tlv flags = 0 idcount = 0 fulldata-tlv feオブジェクトのエンコーディングlfb
Authors' Addresses
著者のアドレス
Avri Doria (editor) Lulea University of Technology Rainbow Way Lulea SE-971 87 Sweden
Avri Doria（編集者）ルレア工科大学レインボーウェイルレアSE-971 87スウェーデン
Phone: +46 73 277 1788
EMail: avri@ltu.se
Jamal Hadi Salim (editor) Znyx Ottawa, Ontario Canada
ジャマル・ハディ・サリム（編集者）ZNYXオタワ、オンタリオカナダ
Phone: EMail: hadi@mojatatu.com
電話：メール：hadi@mojatatu.com
Robert Haas (editor) IBM Saumerstrasse 4 8803 Ruschlikon Switzerland
ロバート・ハース（編集者）IBM Saumerstrasse 4 8803 Ruschlikon Switzerland
Phone: EMail: rha@zurich.ibm.com
電話：メール：rha@zurich.ibm.com
Hormuzd M Khosravi (editor) Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
Hormuzd M Khosravi（編集者）Intel 2111 NE 25th Avenue Hillsboro、または97124 USA
Phone: +1 503 264 0334 EMail: hormuzd.m.khosravi@intel.com Weiming Wang (editor) Zhejiang Gongshang University 18, Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China
電話：1 503 264 0334メール：hormuzd.m.khosravi@intel.com Weiming Wang（編集者）Zhejiang Gongshang University 18、Xuezheng Str。、Xiasha University Town Hangzhou 310018 P.R. China
Phone: +86-571-28877721
EMail: wmwang@zjgsu.edu.cn
Ligang Dong Zhejiang Gongshang University 18, Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China
Ligang Dong Zhejiang Gongshang University 18、Xuezheng Str。、Xiasha University Town Hangzhou 310018 P.R. China
Phone: +86-571-28877751
EMail: donglg@zjgsu.edu.cn
Ram Gopal Nokia 5, Wayside Road Burlington, MA 310035 USA
Ram Gopal Nokia 5、Wayside Road Burlington、MA 310035 USA
Phone: +1-781-993-3685
EMail: ram.gopal@nsn.com
Joel Halpern P.O. Box 6049 Leesburg, VA 20178 USA
Joel Halpern P.O.Box 6049 Leesburg、VA 20178 USA
Phone: +1-703-371-3043
EMail: jmh@joelhalpern.com