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).
この文書では、転送と制御素子分離（のForCES）プロトコルを指定します。 ForCESプロトコルは、のForCESネットワーク要素（NEのForCES）における制御要素（CES）および転送要素（FE）との間の通信のために使用されます。この仕様は、のForCESプロトコルに加えRFC 3654.に定義されているのForCESプロトコル要件を満たすように意図され、本明細書はまた、トランスポート・マッピング・レイヤー（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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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ネットワーク要素（NEのForCES）における制御プレーンと転送プレーン間の情報交換を標準化します。 RFC 3654は、のForCESの要件を定義しており、およびRFC 3746のForCESフレームワークを定義しています。全体のForCESアーキテクチャ内で使用される複数のプロトコルが存在してもよいが、本文書で使用される用語「のForCESプロトコル」および「プロトコル」は、制御要素（CES）および転送要素（FE）との間の情報交換を標準化するために使用されるプロトコルを参照しますのみ。
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.
ForCES FEモデル[RFC5812]はXMLを使用してFEの論理機能ブロック（LFBs）を定義するための正式な方法を提示しています。 LFBが正式に作成されたときLFB構成コンポーネント、機能、および関連するイベントが定義されています。 FE内LFBsそれに応じのForCESプロトコルによって標準化された方法で制御されます。
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.
この文書はのForCESプロトコルの仕様を定義します。 FEは、スレーブおよびCEされたマスタ・スレーブモードの力プロトコル作品がマスターです。プロトコルは、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.
ForCESプロトコルは、すべてのプロトコルメッセージの共通ヘッダを定義します。プロトコルメッセージは、セクション7で定義されている間ヘッダは、セクション6.1で定義されています。
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"
（値）+ ....「値の1つの以上のインスタンス」を意味します
(value)* .... means "0 or more instances of value"
（値）* ...「の値の0以上のインスタンス」を意味します
All integers are to be coded as unsigned binary integers of appropriate length.
すべての整数は、適切な長さの符号なし2進整数として符号化されるべきです。
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.
ForCESのプロトコルを実装しパケットを処理する方法の一の以上のFEを指示するためにそれを使用する論理エンティティ。 CEは、このような制御およびシグナリングプロトコルの実行などの機能を扱います。
CE Manager (CEM):
ECマネージャ（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の管理タスクを担当する論理エンティティ。特にれるFE（S）CEは、通信すべきかを決定するために予め関連付け段階中に使用されます。このプロセスは、FEの発見と呼ばれ、利用できるのFEの機能を学習CEマネージャを含むことができます。
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.
ForCESプロトコルを実装する論理エンティティ。 FEは、のForCESプロトコルを介して1つのまたは複数のCEによって制御/指示されるように、パケット単位の処理および取り扱いを提供するために、基礎となるハードウェアを使用します。
FE Model:
モデルでは：
A model that describes the logical processing functions of an FE. The FE model is defined using Logical Function Blocks (LFBs).
FEの論理的な処理機能を記述するモデル。 FEモデルは、論理機能ブロック（LFBs）を使用して定義されます。
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管理タスクを担当する論理エンティティ。 CE（S）FEが通信すべきであると決定するために、事前関連付け段階中に使用されます。このプロセスは、CEの発見と呼ばれ、利用可能なCEの機能を学習FEマネージャを含むことができます。 FEマネージャが使用するCE（S）を決定するために（下記参照）プレ会合相プロトコル静的構成のものを用いることができます。論理エンティティである、FEマネージャは、物理的に複数のFEのような他の論理エンティティのいずれかと組み合わせることがあります。
ForCES Network Element (NE):
ForCESネットワーク要素（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と一の以上のFEで構成される。 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:
インター-FEトポロジ：
See FE Topology.
FEトポロジを参照してください。
Intra-FE Topology:
イントラ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.
ForCESプロトコルによって操作された基本的なビルディングブロック。 LFBはFEに存在する、強制的プロトコルを介してCEによって制御され、明確に定義され、論理的に分離可能な機能ブロックです。 LFBはFEのデータパスおよびプロセスパケットに存在し得るか、または純粋にCEによって操作されたFE制御または構成エンティティであってもよいです。 LFBは、機能的に正確なFEの処理能力の抽象化ではなく、FE実装のハードウェア、正確な表現であることに注意してください。
FE Topology:
トポロジカルには：
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トポロジ（すなわち、LFBトポロジー）と区別するために、インターFEトポロジと呼ばれています。
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.
LFBsは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からパケット単位の状態を通信するために使用されるが、ネットワークを介して送信されていません。 FEモデルは、メタデータは、識別された生成、及びLFBsによって消費される方法を定義します。これは、機能を定義ではなく、どのようにメタデータは、実装内でエンコードされます。
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).
CEに見えなければならないLFBsの動作パラメータは、LFB成分としてFEモデルで概念化されます。 LFB成分（下記参照）、例えば、フラグ、単一のパラメータ、引数、複雑な引数、及びCEは、読み取り及び/又はのForCESプロトコルを介して書き込むことができるテーブルを含みます。
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トポロジと区別するために、内-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:
ForCESプロトコル：
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.
全体のForCESアーキテクチャ内で使用される複数のプロトコルが存在してもよいが、用語「のForCESプロトコル」および「プロトコル」は、[RFC3746]の力の枠組みの中のFP基準点を指します。このプロトコルは、CE-に-CE通信、FE-に-FE通信、またはFEとCEマネージャ間の通信には適用されません。基本的に、複数のFEは、スレーブおよびCEされたマスタ・スレーブモードの力プロトコル作品はマスターです。この文書では、こののForCESプロトコルの仕様を定義します。
ForCES Protocol Layer (ForCES PL):
ForCESプロトコルレイヤ（の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.
ForCESプロトコルメッセージ、プロトコル状態転送方式、及び（以下に示すようのForCES TMLの要件を含む）のForCESプロトコルアーキテクチャ自体を定義するのForCESプロトコルアーキテクチャのレイヤ。 ForCES PLの仕様は、この文書で定義されています。
ForCES Protocol Transport Mapping Layer (ForCES TML):
ForCESプロトコルトランスポートマッピング・レイヤー（のForCES 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、イーサネット（登録商標）、など）そのようなプロトコル・メッセージは、異なる輸送媒体にマッピングされる方法のようなプロトコル・メッセージの輸送の問題に対処するために、既存のトランスポートプロトコルの機能を使用するのForCESプロトコルアーキテクチャのレイヤ、及び方法など、実現性と信頼性を実現する、マルチキャスト、発注に力TMLの仕様は、別のForCES文書、各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
Figure 1: ForCES Architectural Diagram
図1：のForCESアーキテクチャダイアグラム
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.
ForCESプロトコルドメインはFpの基準点に見出されます。プロトコル要素の構成基準点は、FcとFFは、またのForCESプロトコルのブートアップ中に役割を果たしています。 （[RFC3746]での基準点のFc、Ffと、とflで示す）プロトコル要素の構成は、のForCESプロトコルの範囲外であるが、それはプロトコルの不可欠な部分であるので、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.
PLおよびTML：図2に示されているのForCESインタフェースは、二つの部分を構成しています。
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：のForCESインタフェース
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は、実際の力のプロトコルです。その意味とメッセージのレイアウトは、この文書で定義されています。 TML層は、上記の図3に示すように、二つの力PLSのを接続する必要があります。 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によって標準化されています。一つだけPLが定義されている間、別のTMLsは標準化されることが期待されます。相互運用するには、CEでTMLとFEは、同じ定義に準拠することが期待されます。
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は、NEにFEまたはCEを関連付けるための責任があります。また、このような団体を解体する責任があります。 FEは、CE PLに様々なサブスクライブ-にイベントを送信するだけでなく、CE PLから発行された各種ステータス要求に応答するためにPLを使用しています。 CEは、FEとPLを使用して、関連するLFBs'動作パラメータの両方を設定します。また、CEは、詳細は7章で見つけることができるなど、有効または無効にし、それを、そのHAのパラメータを再設定し、特定のイベントをサブスクライブするFEにさまざまなリクエストを送信することができます。
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は標準化されることが期待されます。様々な可能性のあるTMLsは、基礎となるメディアや輸送の能力に基づいて、その実装を変化させることができます。各TMLが標準化されているので、相互運用性は、両方のエンドポイントが同じTMLをサポートしている限り保証されています。全てTMLsこの文書で定義されたトップエッジセマンティクスを持たなければならないので、すべての力のプロトコル層の実装は、すべてのTMLs間で移植していなければなりません。
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の両方のセットアップおよび構成に価値が、のForCESプロトコルの範囲外です。構成は/ 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
D。接続関連パラメータ
An example of connection association parameters might be:
接続関連パラメータの例は次のようになります。
o simple parameters: send up to 3 association messages every 1 second
簡単なパラメータ○：3つの関連メッセージごとに1秒まで送ります
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.
TMLとPL層の構成/初期化/起動が起こる前会合相、強制的プロトコルのFEのパラメータを操作するように動作後会合相：力は、NEに関連して、二つの相を含みます。
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.
義務付けられた場合に、関連付けられた後、FEは、その特定LFBsの構成に応じてパケットを転送することができます。 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]で定義されているFEオブジェクトLFB FEState成分、セクション5.1によって制御され、また、セクション7.3.2で説明されています。
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はFEState OperDisableで初期化します。 FEは、データパス内のパケットを処理する準備ができている場合、それはOperEnable状態に自分自身を移行します。
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.
それはすでにOperEnableとして思い付いた後、CEは、FEを一時停止するように決定することができます。それはAdminDisableにFEStateを設定することでこれを行います。それが明示的にCEで構成されているまで、FEはOperEnable状態に遷移するAdminDisable状態のままです。
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が適切AdminDisable状態への移行を完了するためには、パケットの転送を停止する必要があり、これは複数LFBSに影響を与える可能性があります。どのようにこれが達成され、この仕様の範囲外です。
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.
ForCESインタフェースは事前関連付け段階中に構成されています。簡単なセットアップでは、構成が静的であり、一般的に保存した設定ファイルから読み込まれます。事前会合フェーズが完了した後に会合相のためのすべてのパラメータは、よく知られています。 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
<-----------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：フロリダ基準点以上のメッセージ交換の例
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成分との接触を確立しているであろう。 ForCESインターフェースの初期化が完了しているだろう、と認証だけでなく、機能の発見は完全なものがあります。 FEおよびCEの両方が設定、アカウンティング、識別、および認証のために相互に接続するために必要な情報を有することになります。要約すると、この段階の完了時に両側が等タイマー、などのすべての必要なプロトコル・パラメータは、FL基準点は、関連付け段階中に動作し続けることができるおり、FEまたはCEの解離を強制するために使用することができます。事前会合相の一部であるCEM及び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成分がのForCESプロトコル（TML上PL）を使用して互いに通信します。三つのサブフェーズがあります。
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.
TMLs間の接続の損失は、それぞれ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.
種々のセマンティクスはトランザクション機能、トランザクションのアトミック性、二相コミット、バッチ/並列化、高可用性、およびフェイルオーバーならびにコマンドパイプラインを含む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.
EM（実行モード）フラグ、AT（アトミックトランザクション）フラグ、TP（トランザクション相）フラグ共通ヘッダ（セクション6.1）で定義されるように、これらの機構に関連しています。
In the master-slave relationship, the CE instructs one or more FEs on how to execute operations and how to report the results.
主従関係において、CEは、操作を実行してどのように結果を報告するために方法の一の以上のFEを指示します。
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.
このセクションでは、CEは、セクション4.3.1.1で定義されるように、実行するためにFE（単数または複数）を注文することができ、実行の異なるモードを詳述します。また、CEが要求などの操作を処理した後の応答をフォーマットするために使用するFE（複数可）を求めることができ、異なるモードを説明しています。これらのモードは、トランザクション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:
一つ以上のLFBセレクタにまたがる操作のバッチを要求することができる3つの実行モードがあり、プロトコルメッセージに（セクション7.1.5参照）。共通ヘッダ（セクション6.1）で定義されたEMフラグは以下のように、プロトコルメッセージのための実行モードを選択します。
a. execute-all-or-none
A。実行-全か無か
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.
このモードでは、すべての操作が最初の故障までFE順次に実行されます。操作の残りの部分は実行されませんが、すでに完了した操作が取り消されていません。つまり、この動作モードにはロールバックはありません。
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:
トランザクションは、次のように定義酸性特性を満たさなければならない一つ以上のPLメッセージ内の1つ以上の力操作のコレクション[酸]、次のように定義されます。
Atomicity: In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are.
原子性：情報の2つの以上の個別の部分を含むトランザクションでは、どちらかの作品のすべてがコミットまたはnoneですがあります。
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-CEペアが緊密に結合されているのと同じベンダーからFE-CEペアの場合と同様にFEの正確なメモリおよび実装の詳細を知っている場合があります。このような場合には、トランザクションの動作が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だけでは例の中で：相互に依存する複数のテーブルを更新します。更新1が失敗した場合、すでに更新されたそのいずれかが取り消されなければなりません。
b. Distributed across the NE Example: updating table(s) that are inter-dependent across several FEs (such as L3 forwarding-related tables).
B。 NE例に分散（例えばL3転送関連のテーブルのような）いくつかのFEを横切る相互依存している更新テーブル（単数または複数）。
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で定義されるように、プロトコルは、一スタンドアロンメッセージ内にトランザクション操作するための機構を提供しています。 「すべての実行か無か」モードは、ACID要件を満たすことができます。
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).
1 FE内又はフェス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.
共通ヘッダ（セクション6.1）でATとTPフラグと一緒にCOMMITと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（中止）
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.
COMMIT操作がトランザクションをコミットするFE（複数可）に知らせるためにCEによって使用されます。 ABT TPフラグと一緒に使用すると、COMMIT操作（すなわち、未コミット）以前にコミットされたトランザクションをロールバックするFE（複数可）信号。
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は、それらがコミットされているトランザクションが終わっ今であることをFE（複数可）に知らせるためにCEによって送信されます。これは、（それが必要となった場合）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で通知任意の失敗は、トランザクションに関与するすべてのFE上の取引を中止するCEの原因となります。これは、ABTフラグとCOMMIT操作でConfigメッセージを送信することによって達成されます。
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によって失敗がなければ、トランザクションのコミット・フェーズは、COMMIT操作でトランザクションの終了（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がトランザクションをアボートしなければならない二つの可能な障害シナリオがあります。
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.
すべての参加のFEは、想定された時間内に成功インジケーターで応答した場合は、CEは、すべての参加のFEに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.
トランザクショナルオペレーションは一般的にアトミックであることに注意してください。したがって、それは、トランザクション操作のすべてのメッセージの実行モードが常に同じに維持されなければならないと「 - 全か無かを実行しない」に設定されている必要があります。 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.
参加のFEまたはCEまたはそれらの間の関係のいずれかがEOT応答メッセージは、FEにより送信された後失敗することがありますがEOT応答がCEに到達したことがない場合は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に示されているように、関連性を失うFEは、再アソシエーション時に新たに関連付けられたCEから完全に新しい状態を取得するために必要とされるであろう。このアプローチは単純化され、データパスのトラフィックを失うのしやすを提供しますが、優雅な再起動を管理するための追加的な複雑さを避けるために、設計上の選択です。 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.
このセクションでは、2つの相がCEとFEとの間でコミット成功したが、単純な場合にどのように見えるかの例を示しています。
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：二相の例は、コミット
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またはSETのような選択の操作とConfigメッセージを発行します。トランザクションフラグがトランザクションの開始（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と同様の構築物と同じ種類のトランザクション（MOT）の途中に変更し、トランザクションフラグとCEによって繰り返されます。
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は、コミットを発行します。コミットコミットタイプの動作とConfigメッセージです。トランザクションフラグは、トランザクションの終了（EOT）に設定されています。基本的に、これはトランザクション（メッセージ＃1）の初めから集まったすべての操作を実行するためにFEを求めて「空」のメッセージです。
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.
この時点でFE Oが完全なトランザクションを実行します。その後、バックCOMMIT-RESPONSEを含有するステップ（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は、ステップFEにTRCOMP動作（N + 2）を発行する簡単なタスクを有します。
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つのメカニズムがこれを達成するために提供されています。最初のものは、バッチ処理であり、もう一つはコマンドパイプラインです。
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.
バッチ処理は、一つのプロトコルデータユニット（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は、一つ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.
FEとCE間のハートビート（HBS）は、トラフィック敏感です。 HBは何のPLトラフィックが設定された間隔内のCEとFEとの間で送信されていない場合にのみ送信されます。これは、忙しい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ピングプロトコルと同様に）要求することができます。 FEは、CEによってそうするように構成された場合でのHBsを生成することができます。 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の構文で動作します。これは、メンテナンスとのFEのコンフィギュラ、NE、、強制的プロトコル自体がこのLFBアーキテクチャで表さなければならないことを意味します。このため、特別なLFBsは、このニーズに対応するために作成されます。
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転送、フィルタリングなどの機能を制御するために使用するのForCESプロトコル自体は、構造（LFBs）の非常に同じ種類によって制御することができる方法を示して
To achieve this, the following specialized LFBs are introduced:
これを実現するために、以下の特殊なLFBsが導入されています。
o FE Protocol LFB, which is used to control the ForCES protocol.
ForCESプロトコルを制御するために使用されるFEプロトコルLFB、O。
o FE Object LFB, which is used to control components relative to the FE itself. Such components include FEState [RFC5812], vendor, etc.
O FEはFE自体に対して構成要素を制御するために使用されるLFBを、オブジェクト。このような成分は、等FEState [RFC5812]、ベンダーを含みます
These LFBs are detailed in Section 7.3.
これらのLFBsは、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.
CEとFE間の関連付けはFEから協会セットアップメッセージを介して開始されています。セットアップ要求は、CEによって付与されている場合は、成功したセットアップ応答メッセージは、FEに送信されます。 CEとFEが安全でない環境で動作している場合は、セキュリティアソシエーションは、任意の関連メッセージを交換することができる前に、それらの間に確立する必要があります。 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]参照）とCEにレポートを設定する等の機能クエリ、トポロジ・クエリ、続いてそれが最初に照会されたとき。典型的には、FEは、それが関連付け前にデータパスを処理する準備ができると予想されるが、それは時間がいくつかの前処理を行う必要があるまれな場合がある - そのような場合には、FEがOperDisable状態で開始するときOperEnable状態に移行します準備ができています。 FEは、次にOperEnableに移行OperDisableに出発の例は、CEは、任意の時点でもAdminDisableにFEStateを設定することにより、FEのデータパスの動作を無効に可能性が図8に示されています。 CEが戻っOperEnableに状態を設定しない限り、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：CEとFE間のメッセージ交換NEアソシエーションを確立します
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
図9：定常通信時にCEとFE間のメッセージ交換
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).
同図に示すメッセージのシーケンスは例としてのみ機能し、メッセージ交換シーケンスが図示されているものとは異なることができることに留意されたいです。また、このセクションで説明したプロトコルシナリオは、フェールオーバー中に行われるすべての異なるメッセージ交換が含まれていないことに注意してください。それは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又は複数のFEに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は、それが記載されているのForCES要件の達成にどのように寄与するかを説明しなければなりません。何らかの理由で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.
ForCESプロトコル仕様をサポートする実装は、[RFC5811]を実装しなければなりません。追加TMLsが、将来的に指定されるかもしれないことに注意してください、とここに記載されている要件を満たし、将来的に定義された新しいTMLが優れていることが判明した場合、その後、再定義することができる「TML実装しなければなりません」。
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.
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要件に準拠しながら）厳密に信頼できないメカニズムを使用するように定義することができます。
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.
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ストリームに偽のメッセージを注入する位置に、攻撃者は、として報告されたイベント、または応答を変更することによって（またはCE自体（例えば、制御CEから来るように報告されたデータを改竄することによって）データパスのFEの治療のいずれかに影響を与えることができ）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は、不正のCE、強制的にNEの制御及びデータパス処理における不正のFEの参加を防ぐために、のForCESのCEとFEを認証するためのメカニズムを提供しなければなりません。
* 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メッセージに不正なデータの注入を防止するために、FE（およびその逆）にCEから転送された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-レベル情報の開示を防止するために強制しPLから転送されたデータの機密性を確保するためのメカニズムを提供しなければなりません。
The TML SHOULD provide these services by employing TLS or IPsec.
TMLは、TLSやIPsecを使用することにより、これらのサービスを提供しなければなりません。
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.
If there is any mapping between PL- and TML-level uni/multi/
broadcast addressing, it needs to be defined.
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.
Please refer to Section 8 for details.
詳細については、セクション8を参照してください。
Different types of TMLs will encapsulate the PL messages on
different types of headers. The TML needs to specify the
encapsulation used.
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.
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つの優先度レベルをサポートしている場合4-7は、他に行くことができる一方で、例えば、0-3は、1つのTML優先レベルに行くことができます。
The TML MUST NOT re-order config packets with the same priority.
TMLは、同じ優先度の設定パケットの順序を変更してはなりません。
The TML MUST define mechanisms it uses to help prevent node
overload.
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.
ForCESのNEの運転容量を減少ノード計算サイクルおよび/または帯域幅リソースの飢餓に過負荷をもたらします。 NEノードの過負荷は、故意のForCES NEを攻撃し、サービス拒否（DoS）を作成するために、敵対的なノードによって扇動することができます。それはまた、結果的にFEまたはCEを移行FEテーブルの更新、HAのフェイルオーバー、またはコンポーネントの障害に対するCEの高周波を引き起こす大きな制御プロトコルの更新（例えば、BGPフラップ）のような他のさまざまな理由により作成することができますSIPと力が動作する環境下では異なるが、新しいCEまたはFE等を圧倒負荷、[RFC5390]は一つのために保護する必要がある一般的なノードの要件に良いガイドを提供します。
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.
このような場合には、ノードのトランスポートキューが成長し、交通渋滞が、その後、次の - のForCESノードCPUは、着信パケットレートが、それはついていくことができるよりも高くなっているので、圧倒かもしれません。 ForCESノードのCPUにも悪影響を非常に少数のパケット、すなわち、全く交通渋滞（例えば、テーブルをオーバーフローおよび/またはCPU忙しくテーブルのハッシュアルゴリズムに対するDoS攻撃では、それがないように、プロセスで過負荷にすることができます他のタスク）。指定された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
PL ID O
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がよい巣他のTLVセクション6.2.1一つ以上のTLV 6.2、続いて共通ヘッダセクション6.1で始まります。すべてのフィールドは、ネットワークバイト順です。
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):
送信元ID（32ビット）：
Dest ID (32 bits):
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のそれぞれは、固有のNE-ワイドであり、それはのForCES PLメッセージの終端点を識別する32ビットのIDです。
* 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.
b. The address space allows up to 2^30 (over a billion) CEs and the same amount of FEs.
B。アドレス空間は、2 ^ 30（億以上）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：のForCES IDのフォーマット
c. The 2 most significant bits called Type Switch (TS) are used to split the ID space as follows:
C。次のように2つの最上位ビットと呼ばれるタイプのスイッチ（TS）は、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は、（例えば、CEとFEなど）グループエンドポイントに使用されます。一例として、一つは、マルチキャストIDを割り当てることにより、いくつかの官能基のグループのFE、できました。同様に、バックアップモードでは、例えば、行動CEのサブグループはFEからそれらを隠すために、マルチキャストIDを割り当ててもよいです。
+ Multicast IDs can be used for both source or destination
IDs.
+ 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が与えられたグループに関連付けられている方法については説明しません。 IDのリストFEは、所有しているか、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)
- ACK：ACKインジケータ（2ビット）
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.
応答が送信者によって必要とされているか否かをメッセージ受信機に指示するためにConfigメッセージ（セクション7.6.1）又はHBメッセージ（7.10）を送信する場合、ACKインジケータフラグはCEによって使用されます。 Configメッセージや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.
「SuccessACK」（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:
また、コンフィグとHBメッセージ以外の、メッセージの応答のための要件はすべてデフォルトで仕方なく、ACKフラグによって与えられている、ということに注意してください。これらのメッセージと予想される応答のデフォルトの要件は以下のとおりです。詳細な説明は、個々のメッセージ定義に見つけることができます：
+ Association Setup message always expects a response.
+協会セットアップメッセージは、常に応答を期待しています。
+ 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)
- ぷり：優先度（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.
ForCESプロトコルは、優先順位（0-7）の8つの異なるレベルを定義します。優先レベルは、異なるプロトコルメッセージタイプ間ならびに同じメッセージタイプを区別するために使用することができます。優先度の値が高いほど、より重要なPDUです。例えば、REDIRECTパケットメッセージはFEから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)
`実行-NONE`全かを.......（0B01）
`execute-until-failure` ..... (0b10)
`実行-まで-failure` .....（0b10と）
`continue-execute-on-failure` (0b11)
`継続実行オン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)
2PCトランザクションメッセージ.....（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.
トランザクション内のFEへのCEからのメッセージは、トランザクションが中にある異なる相の指標である可能性があります。詳細については、セクション4.3.1.2.2を参照してください。
SOT (start of transaction) ..... (0b00)
SOT（トランザクションの開始）.....（0b00と）
MOT (middle of transaction) .... (0b01)
MOT（トランザクションの途中）....（0B01）
EOT (end of transaction) ........(0b10)
EOT（トランザクションの終了）........（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が広範囲のForCESプロトコルによって使用されています。 TLVがそれらLFBクラスモデルのXML定義をエンコードするための良い候補にするいくつかの非常に素晴らしい特性を有しています。これらは：
o Providing for binary type-value encoding that is close to the XML string tag-value scheme.
XML文字列タグ値のスキームに近いバイナリタイプ値の符号化を提供するO。
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。これはつまり、古いアプリケーションが新しいTLVを無視することができますし、新しいアプリケーションは、古いTLVを無視することができ、XMLのアプローチに相当します。
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つのオクテット）、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ビットの倍数ではなく、32ビットの倍数にTLVをもたらすために必要なオクテット数の最小値である場合のパディングが必要です。パディング前の値の長さは、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を導入することにより、新しい拡張機能を追加することがある）プロトコルの柔軟性の利点を提供します。ネスティング機能は、（ネストのTLVで表される）は、バイナリPL表現にXMLのLFB定義と概念の最適化を可能にします。
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のためのものであり、2番目の名前スコープ外OPER-のTLVであり、セクションA.2に定義されているのに対し、A.4で定義されています。
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のわずかな変化です。これは、（セクション6.4.1を参照）のForCESコンポーネントIDを指す32ビットのローカル索引であるとタイプ（「T」）を設定します。
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オクテットの整数であり、ILV型（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定義からデータ宣言によって定義されることに留意されたいです。 ILVsの使用に関する議論については、セクション7.1.8を参照してください。
In this section, we review a few encapsulation concepts that are used by the ForCES protocol for its operations.
このセクションでは、我々はその操作のためのForCESプロトコルによって使用されているいくつかのカプセル化の概念を確認します。
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]を再導入。読者はより細かい細部の多くのために[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、その結果-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.
ForCESモデル[RFC5812]はLFBsの正式な定義を可能にするXMLベースの言語を定義します。これは、ASN.1やSNMP MIB定義（MIBはLFBに類似しているとASN.1は、XMLモデル言語に類似している）との間の関係に似ています。 CEは、FEに設定する任意のエンティティが正式にLFBで定義する必要があります。これらのエンティティは、スカラー（例えば、32ビットのIPv4アドレス）または（例えばネクストホップテーブルのような）ベクターであってもよいです。 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]によって導入されます。経路は、典型的には、ドット表記（例えば、1.2.3.4）に提示されている32ビットコンポーネントIDの系列です。セクション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.
ForCESモデル[RFC5812]は表の行をアドレス指定する2つの方法を定義します。標準/一般的なメカニズムは、テーブルの行は、32ビットのインデックスにより参照することができるようにすることです。第二のメカニズムは、コンテンツのアドレス指定を可能とするキーです。例えば、キーが一意のIPv4ルーティングテーブルの行を参照するIPアドレスとプレフィックス長を使用してマルチフィールドのコンテンツ鍵です。表の行をアドレス指定するための一般的なスキームは、そのテーブルインデックスを介してであるが本質的に、テーブルの行のパスは、鍵から導出することができます。 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.
FULLDATA-TLVとSPARSEDATA-TLV：FEからかへのデータは、のTLVの2種類で運ばれます。 FEが実行する操作に応答がRESULT-の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-のTLVの例については、付録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からの応答を運びます。 RESULT-の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で定義された）共通ヘッダとメッセージ本体で構成されています。共通ヘッダは、メッセージ・タイプ固有のメッセージ本体が続きます。各メッセージの本体は、一つ以上の最上位の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（s）は、その参照に適用されて含まれています。
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は、標的の正確なコンポーネントを識別し、それに関連付けられたゼロ個以上の経路を有することができます。データを介してパスの入れ子の場合には最後のパス-DATA-TLVは、SETの場合に構築要求-PROPセット、GET-RESPONSE / GET-PROP-RESPONSEはの形で符号化されたデータ又は応答によって終了されますFULLDATA-TLVまたはSPARSEDATA-TLVまたは結果-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.
* IDは：（そのカウントIDCOUNTによって与えられる）は、ゼロ又はそれ以上の32ビットIDの主経路を画定します。フラグによって、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です。フラグはまた、その存在を示すときにのみSELECTORの存在が正しいです。
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、RESULT-TLV、または1以上のさらなるPATH-DATAの選択を含んでいてもよいです。 FULLDATA-TLVとSPARSEDATA-TLVはSETまたはSET-PROPのリクエストで許可されている、または（例えば、GET-RESPONSE）コンテンツ情報を返す応答にされています。 PATH-DATAは、任意の要求に応じて経路を拡張するために含まれてもよいです。
* Note: Nested PATH-DATA-TLVs are supported as an efficiency measure to permit common subexpression extraction.
*注：ネストされたPATH-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は、そのパスPATHによって選択された「データ」を含んでいます。詳細については、7.1節を参照してください。
* The following table summarizes the applicability and restrictions of the FULL/SPARSEDATA-TLVs and the RESULT-TLV to the OPER-TLVs.
*以下の表は、OPER-のTLVへの適用およびFULL / SPARSEDATA-のTLVとRESULT-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は、個々のSETまたはSET-PROPが成功したかどうかの表示を含みます。 RESULT-TLVは、SET要求の個々の部分が成功するか、別々に失敗する可能性があることを前提に含まれています。
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メッセージ（バッチ）において標的一つ以上の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の場合のために最適化されていることに留意すべきです。同じクラス内の複数のインスタンスをターゲットにするには、複数のLFBselectsが必要とされています。
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項では、DATAエンコーディング（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.
FULLDATA-TLVの値（TLVの「V」）が搬送されるデータを含むであろうO。 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:
FULLDATA-のTLVの場合○：
* 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のPATH（IDS）で言及された場合*、次いでFULLDATA-TLVの「V」は、32ビットのインデックス/添字で始まるそのテーブルの行の内容を含むことになります。一方、PATHは、テーブル内の行を指すインデックスを含むことができます。このような場合には、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 SELECTORビット：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.
そのような実行モードとヘッダで定義された原子数指標としてグローバルフラグは、メッセージ内のすべての操作に適用されます。グローバルフラグは、パスデータに定義されたフラグなどのフラグ演算により提供される、直交するセマンティクスを提供します。操作フラグの範囲は、操作に制限されています。
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は、KEYだけでなく、関連する鍵データを記述する。コンテンツの検索に使用するキーは、LFBの定義に制限され、説明されています。
The LFBselect TLV is an instance of a TLV as defined in Section 6.2. The definition is as follows:
セクション6.2で定義されるようLFBselect 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 = 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.
オクテット内TとLフィールドを含むTLVの長さ。
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:
OPERA-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にネスト操作について説明しています。通常TLVを選択LFBための少なくとも一つのOPER-TLVが存在すべきであることに注意してください。
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.
SET、SET-PROPは、およびGET / GET-PROP要求はCEによって発行され、結果-TLVを運びません。一方、SET-RESPONSE、SET-PROP-RESPONSE、およびGET-RESPONSE / GET-PROP-RESPONSEキャリーRESULT-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に応じて、GET-RESPONSEはFULLDATA-のTLVが要求されたデータを運ぶために葉のパスに追加されます。失敗GET操作の場合、代わりに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.
SET-RESPONSE / SET-PROP-RESPONSEのために、オリジナルの要求における各FULLDATA-TLVまたはSPARSEDATA-TLVはRESULT-TLV応答に置き換えられます。リクエストがFailureACKフラグを設定すると、失敗した項目のみが応答に表示されます。リクエストがAlwaysACKのためだった場合、その要求のすべてのコンポーネントがRESULT-のTLVで応答に表示されます。
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で構成されたSET / SET-PROP要求が発行され、構造体のいくつかのフィールドが無効である場合は、FEが無効だったフィールドを示すしようとしませんが、むしろ操作が失敗したことを示すことに注意してください。単一の葉PATH-DATA / FULLDATA-TLB内に複数のエラーがある場合、FEは、それが戻ることを選択したエラーを選択できることにさらに注意してください。構造のSET / SET-PROPためFULLDATA-TLVが読み取り専用である一つのフィールドを書き込もうとし、無効な値に別のフィールドを設定しようとするので、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の長さの可変長成分にSET / SET-PROP操作は、それを削除すると同じではありません。 CEは削除したい場合には、DEL操作は、パスは、アレイ成分又は任意構成成分を意味するかどうかを使用すべきです。
The RESULT-TLV is an instance of TLV defined in Section 6.2. The definition is as follows:
RESULT-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
図20：RESULT-TLV
Defined Result Values
定義された結果の値
+-----------------------------+-----------+-------------------------+
| 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.両方ILVsとの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符号化における構造体Sのすべてのコンポーネントが存在することによって示されています。この要件は必須またはオプションに関係なく、フィールドは固定されているか否かに可変長を保持しています。
* 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.
* 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.
「私は」ILVで一意にコンポーネントを識別するので* SPARSEDATA-TLVの場合は、注文する必要はありません。付録Cに、実施例1（a）及び図1（b）はSPARSEDATA-TLVエンコーディングのパワーを示しています。
* The values for atomic, fixed-length fields are given without
any TLV encapsulation.
* 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）に記載されていると付録の例によって示されるように値が続くインデックス/添字の形態です。
* The values of all fields MUST be given with ILVs (32-bit
index, 32-bit length).
6. A FULLDATA-TLV can also contain a FULLDATA-TLV for variable-sized components. The decoding disambiguation is assumed from rule #3 above.
6. A 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.
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.
GETでテーブル全体をダンプする場合2.は、単に設定する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つまたは複数の操作を含むことができるそれぞれが一つ以上の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
| + - 旗| + - IDCOUNT | + - IDS | | | + - T = FULLDATA-TLV | + - データT = DEL | + - T =パスデータ| + - +旗 - IDCOUNT + - IDS | + - T =パスデータ| + - +旗 - IDCOUNT + - IDS | + - T =パスデータ| + - +旗 - IDCOUNT + - のID + - T =のKeyInfo-TLV | + - KEY_ID | + - + KEY_DATA - T =パスデータ| + - +旗 - IDCOUNT + - のID
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:
ForCESプロトコルの動作を制御するとのFEとCEとのやり取りに使用される2つのLFBsがあります。
o FE Protocol LFB o FE Object LFB
FEオブジェクトLFB〇〇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.
これらLFBsが他のLFBsと同じ形式とのインタフェースを持っているが、それらは多くの点で特別なものです。彼らは、よく知られたLFBクラスとインスタンスIDを修正しました。これらは、静的（動的なインスタンス化が許可されていない）が定義され、そしてそれらの状態は、プロトコルによって変更することはできません。（LFBを無効にするために、例えば）そのようなLFBsの状態を変更する任意の動作エラーが発生しなければなりません。また、これらLFBsは最初のForCESメッセージが送信または受信することができる前に存在しなければなりません。これらLFBsのすべてのコンポーネントは、事前定義されたデフォルト値を持たなければなりません。最後に、これらのLFBsは、入力または出力ポートを持っていないとイントラ-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はのForCESプロトコルを制御するために使用される各FE内の論理エンティティです。 FEプロトコルLFBクラスIDは、値を0x2に割り当てられています。 FEプロトコルLFBインスタンスIDは、値は0x1が割り当てられます。 1とFEでFE議定LFBのインスタンスは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でサポートされているのForCESプロトコルバージョン（S）。
FE Protocol components (can be read and set).
FEプロトコルコンポーネント（読み取りおよび設定することができます）。
Current running version of the ForCES protocol.
ForCESプロトコルの現在の実行バージョン。
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ハートビートポリシー - FEは、CEの生存性を確認するために、このポリシーは、後述するようにパラメータ「CEハートビートデッドインターバル（CE HDI）」と一緒に、動作パラメータを定義します。次のような意味を持つポリシーの値が記載されています：
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.
0（デフォルト） - このポリシーは、CEは、他のPLメッセージがFE（複数可）にCEから送信されなかったその中の時間間隔に達するたびにCEは、FE（S）にハートビートメッセージを送信することを指定します。 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.
1 O - 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ハートビートデッドインターバル（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ハートビートポリシー - このポリシーは、パラメータと一緒に「FEハートビート間隔（FE HI）」は、FEはCEがその生存性を推測することができるように振る舞うべきかの動作パラメータを定義します。ポリシーの値と意味は以下のとおりです。
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.
0（デフォルト） - FEは、任意のハートビートメッセージを生成してはなりません。このシナリオでは、CEは、AlwaysACKに送信するメッセージのPLヘッダのACKフラグを設定することにより、FEの生存性を確認する責任があります。 FEは、CEは、このようなハートビート要求メッセージを送信するたびに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.
1 O - このポリシーは、その間隔の間であれば他のメッセージをCEにFEから送信されなかったとしてFE HIによって割り当てられた時間間隔に到達した場合、セクション4.3.3に記載したように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） - FEは、セクション4.3.3に記載したように他のメッセージがそのインターバル中に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.
バックアップCEのリスト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.
0（デフォルト）O - FEは、FE OperDisableに直ちに移行機能を停止すべきです。
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グレースフルリスタートをサポートしている必要が（とその能力のようなサポートを定義します）。 CEFTIは、プライマリCEID（セクション7.3.1.1.2.8）または多分、いくつかのバックアップCEの1（節7.3.1.1.2.10）とFEの再関連付けする前に期限切れになった場合、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の動作に破壊的であるので、CEハートビートデッドインターバル（CE HDI）よりもはるかに高いCEFTI値を設定することが望ましいことに留意されたいです。
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.
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自体に対してではなく、構成要素を含んでいます。
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）-slave（FE）の関係を提供します。 LFBsは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.
メッセージは、CEにFEから行く場合、LFBセレクタ（クラスおよびインスタンス）はFEに存在するソースLFB選択を指します。
The ForCES Association messages are used to establish and tear down associations between FEs and CEs.
ForCES協会メッセージがのFEとCE間の関連付けを確立し、解体するために使用されています。
This message is sent by the FE to the CE to set up a ForCES association between them.
このメッセージは、それらの間の力の関連付けを設定するためにCEにFEにより送信されます。
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フラグは無視しなければなりません、そして協会セットアップメッセージは常にセットアップが成功したか否か、メッセージ受信（CE）からの応答を得ることを期待します。 FEが正しくCEから戻ってくる応答を相関させることができるように、ヘッダ内の相関フィールドは、設定されています。 FEは、CEは、セットアップ応答メッセージにFE FE用IDを割り当てる必要があることを要求するために、ヘッダに0にソース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プロトコルLFBs上で動作します。従って、LFBselect TLVにLFBクラスIDのみLFBsのこの2種類を指します。
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.
OPER-TLV LFBselect TLVでは、「REPORT」操作として定義されます。複数のコンポーネントは、FEが求められていないようにして、その設定パラメータを宣言できるようにREPORT操作を使用して、このメッセージに発表されてもよいです。これらは、FE HB間隔またはFEIDなどの値を示唆している成分を含んでいてもよいです。使用OPER-TLVは以下に定義されます。
OPER-TLV for Association Setup:
協会のセットアップのための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 = 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.
タイプ=「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形式です。 REPORT操作のためのPATH-DATA-TLVはFULLDATA-TLV（複数可）を含有してもよいが、データ形式のいずれかのRESULT-TLVを含んではなりません。 RESULT-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：協会セットアップメッセージのための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.
このメッセージは、セットアップメッセージに応答してFEにCEによって送信されます。これは、関連付けが成立しているか否か、すなわち、セットアップが成功したか否かをFEに示します。
Message transfer direction:
メッセージ転送方向：
CE to FE
FEへのCE
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 =「AssociationSetupResponse」に設定されています。ヘッダ内のACKフラグは無視されなければならない、とセットアップ応答メッセージは、メッセージ受信者（FE）から任意のより多くの回答を得ることを期待することはありません。ヘッダ内の宛先IDは、対応するソースIDは、次に、CEは、FE ID値を割り当て、ためにその値が使用され、0であった場合、その送信元IDが0でない限り、対応するアソシエーションのセットアップメッセージのソース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：OPERのasResult-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.
オクテット内TとLフィールドを含むTLVの長さ。
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
0 =成功
1 = FE ID invalid
1 = FE ID無効
2 = permission denied
2 =許可拒否
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.
このメッセージは、その要素と軍事力の関連付けを終了する任意のForCES要素にFEまたはCEによって送信することができます。
Message transfer direction:
メッセージ転送方向：
CE to FE, or FE to CE (or CE to CE)
（CEまたはCE）CEのFE、またはFEへの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.
ヘッダ内のメッセージタイプは=「AssociationTeardownを」のMessageTypeに設定されています。 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：ASTreason-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.
オクテット内TとLフィールドを含むTLVの長さ。
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：協会ティアダウンメッセージの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.
ForCES設定メッセージはのForCES NE内のFEを設定し、バックCEに結果を報告するために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コンポーネントを構成するためにFEにCEによって送信されます。このメッセージは、/サブスクライブLFBイベントに解除するCEによって使用されます。
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:
いつものように、構成メッセージは、一つ以上のTLVデータ形式で構成され、メッセージ本体に続く共通ヘッダで構成されています。次のようにメッセージの詳細な説明は次のとおりです。
Message transfer direction:
メッセージ転送方向：
CE to FE
FEへのCE
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するように設定されています。ヘッダ内のACKフラグがFEからの応答がメッセージが期待されているか否かを示すために、セクション6.1で定義された任意の値に設定することができます。
OPER-TLV for 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：コンフィグためのOPER-TLV
Type:
タイプ：
The operation type for Config message. Two types of operations for the Config message are defined:
Configメッセージのための操作タイプ。 Configメッセージのための操作の二つのタイプが定義されています。
Type = "SET" - This operation is to set LFB components
タイプ=「SET」 - この操作は、LFBのコンポーネントを設定することです
Type = "SET-PROP" - This operation is to set LFB component properties.
タイプ= "SET-PROPを" - この操作は、LFBのコンポーネントのプロパティを設定することです。
Type = "DEL" - This operation is to delete some LFB components.
タイプ=「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に送信されます。それには、「V」ALUEを有していない、すなわち、TLVが空TLVコミット。換言すれば、（ヘッダのみのためのものである）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).
=「TRCOMP」type - この操作は、2PCトランザクションのNEの観点から成功をマークするFEに送信されます。 TRCOMP TLV、すなわち、それは「V」ALUEを有していない、空のTLVです。換言すれば、（ヘッダのみのためのものである）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形式です。 SET / SET-PROP動作のためPATH-DATA-TLVの使用に関する制限は、それがFULLDATA-TLVまたはSPARSEDATA-TLV（S）のいずれかを含まなければならないが、任意のRESULT-TLVが含まれていなければならないということです。 DEL操作のためのPATH-DATA-TLVの使用上の制限は、それがFULLDATA-TLVまたはSPARSEDATA-TLV（複数可）を含んでいてもよいが、任意のRESULT-TLVを含んでいてはならないです。 RESULT-TLVは、7.1.7項で定義され、FULLDATA-のTLVとSPARSEDATA-のTLVは、セクション7.1.8で定義されています。
Note: For Event subscription, the events will be defined by the
individual LFBs.
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.
このメッセージは、Configメッセージに応答してCEにFEによって送信されます。これは、構成がFEに成功したか否かを示し、また、各成分の構成結果に関する詳細な応答を与えます。
Message transfer direction:
メッセージ転送方向：
FE to CE
CEのFE
Message header:
メッセージヘッダ：
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 =「コンフィグ応答」に設定されています。ヘッダ内のACKフラグは常に無視され、構成応答メッセージは、メッセージレシーバ（CE）からの任意のさらなる応答を得ることを期待されることはありません。
OPER-TLV for Config Response:
コンフィグ応答のための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 31: OPER-TLV for Config Response
図31：コンフィグ応答のためのOPER-TLV
Type: The operation type for Config Response message. Two types of operations for the Config Response message are defined:
タイプ：コンフィグ応答メッセージの操作タイプ。コンフィグ応答メッセージのための操作の二つのタイプが定義されています。
Type = "SET-RESPONSE" - This operation is for the response of the
SET operation of LFB components.
Type = "SET-PROP-RESPONSE" - This operation is for the response of the SET-PROP operation of LFB component properties.
タイプ= "SET-PROP-RESPONSE" - この操作はLFBコンポーネントのプロパティのSET-PROP操作の応答のためのものです。
Type = "DEL-RESPONSE" - This operation is for the response of the DELETE operation of LFB components.
タイプ=「DEL-RESPONSE」 - この操作はLFB成分のDELETE操作の応答のためのものです。
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を」 - この操作は、2PCトランザクションでコミットの成功を確認するためにCEに送信されます。 COMMIT-RESPONSE 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形式です。 SET-RESPONSE動作のためPATH-DATA-TLVの使用に関する制限は、それがRESULT-TLV（単数または複数）を含んでいなければならないことです。 DEL-RESPONSE動作のためPATH-DATA-TLVの使用に関する制限は、それがまたRESULT-TLV（単数または複数）を含まなければなりませんです。 RESULT-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.
ForCESクエリメッセージは、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:
Queryメッセージは、共通ヘッダおよび1つまたは複数のTLVデータ形式で構成され、メッセージ本体で構成されています。次のようにメッセージの詳細な説明は次のとおりです。
Message transfer direction:
メッセージ転送方向：
from CE to FE
CEからFEへ
Message header:
メッセージヘッダ：
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 =「クエリ」に設定されています。ヘッダ内のACKフラグは常に無視され、クエリメッセージの完全な応答が常に期待されています。 CEが正しく戻ってFEからの応答を見つけることができるように、ヘッダ内の相関フィールドは、設定されています。
OPER-TLV for Query:
クエリのための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 = 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-PROP" - This operation is to request to get LFB component properties.
TYPE = "-PROPをGET" - この操作は、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、結果-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.
Queryメッセージを受信すると、受信者はメッセージを処理し、クエリ結果を考え出す必要があります。受信機は、クエリ応答メッセージを使用してバックメッセージの送信者への問い合わせ結果を送信します。クエリ結果は、クエリ操作が成功した場合に照会される情報であってもよく、またはクエリ操作が失敗した場合、エラー・コードとすることができ、失敗の理由を示します。
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
FEから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:
クエリ応答のための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 = 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:
クエリ応答のための操作タイプ。一つの操作タイプが定義されます。
Type = "GET-RESPONSE" - This operation is for the response of the
GET operation of LFB components.
Type = "GET-PROP-RESPONSE" - This operation is for the response of the GET-PROP operation of LFB components.
タイプは、= "GET-PROP-RESPONSE" - この操作は、LFBコンポーネントのGET-PROPの操作の応答のためです。
PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE:
PATH-DATA-TLV GET-RESPONSE / GET-PROP-RESPONSEのために：
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形式です。 PATH-DATA- TLV GET応答動作のためには、データ符号化にSPARSEDATA-TLV、FULLDATA-TLV、および/または結果-TLV（S）を含んでいてもよいです。 RESULT-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に発生するイベントのCEに通知するためにFEによって使用されます。
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動作とConfigメッセージを介してイベントをサブスクライブすることができます。
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
CEのFE
Message header:
メッセージヘッダ：
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:
イベント通知のための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 = 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:
唯一の操作タイプは、イベント通知メッセージ用に定義されています。
Type = "REPORT" - This type of operation is for the FE to report something to the CE.
タイプ=「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形式です。 REPORT操作のための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です。次のようにパケットリダイレクトメッセージのリダイレクト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：METADATA-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:
これは、リダイレクト動作を介して導かれるデータの一つのパケットを記述する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）メッセージは非同期そのライブネスに同一のForCESのNE内の1つまたは複数の他の力の要素を通知するために、1つのForCES要素（FEまたはCE）のために使用されます。 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:
ハートビートメッセージは、定期的のForCES要素によって送信されます。 FEのためのハートビートのためのパラメータとポリシー定義は、FEプロトコルオブジェクトLFBのコンポーネントとして管理され、Configメッセージを介してCEによって設定することができます。ハートビートメッセージは、メッセージ本体が空のままで、それが唯一、共通ヘッダで構成されているという点で他のプロトコルメッセージとは少し異なっています。次のようにメッセージの詳細な説明は次のとおりです。
Message transfer direction:
メッセージ転送方向：
FE to CE or CE to FE
FEへのCEまたはCEの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 =「ハートビート」に設定されています。 4.3.3を使用HBのメカニズムについて説明します。 HBが送信されたとき、ヘッダ内のACKフラグが「ノアック」または「AlwaysACK」のいずれかに設定しなければなりません。
* When set to 'NoACK', the HB is not soliciting for a response.
「ノアック」に設定した場合*、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は、FEの生存性を照会するために、このようなHBメッセージを送ることができます。簡略化のため及びためHBメッセージの最小の性質のため、HBメッセージに対する応答は、別のHBメッセージ、すなわち、特別なHB応答メッセージが定義されていませんです。 FEは、CEから「AlwaysACK」が付くHBメッセージを受信するたびに、FEはすぐに戻ってHBメッセージを送らなければなりません。 「AlwaysACK」に応答して、FEによって送信されたHBメッセージはFEのIDがソースIDであり、送信側のCEのIDが宛先IDとなるように、ソースと宛先のIDを変更する必要があり、及びACK情報を変更する必要があります「ノアック」へ。 CEは、「AlwaysACK」を設定してHBメッセージに応じてはいけません。
* When set to anything else other than 'NoACK' or 'AlwaysACK', the HB message is treated as if it was a 'NoACK'.
「ノアック」または「AlwaysACK」以外の何かに設定されている場合、それは「ノアック」だったかのように*、HBメッセージが処理されます。
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.
ForCESプロトコルは、[RFC3654]で定義されるように高可用性をサポートするために、CEの冗長性およびフェイルオーバーのためのメカニズムを提供します。 FEの冗長性とFE FEへの相互作用は、この文書の範囲の外に現在あります。 ForCES NEで複数の冗長CEとFEが存在する場合があります。複数の二次のCEが存在し得るもののしかし、一度に1つのプライマリCEは複数のFEを制御することができます。 FEおよびCE PLは、プライマリとセカンダリのCEを認識しています。この情報（一次、二次のCE）はそれぞれFEMおよびCEMによって予め関連付け中FEおよびCE用のPLに構成されています。唯一の主要CEフェズに制御メッセージを送信します。
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
FEでの高可用性のパラメータはFEプロトコルオブジェクトLFBを（付録Bおよび7.3.1項を参照）の設定によって駆動されます。 FEハートビート間隔、CEハートビートデッドインターバル、および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と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：FEステートマシンは、HAを考えます
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にFEおよびCE（CEまたはリンクの障害ではなく、FEは、関連のいずれかによって引き起こされ得る）、のいずれかTMLの間に失敗した場合、この失敗に関するFE PLをトリガするか、間HBメッセージを使用して検出されますFEおよびCEの。通信障害は関係なく、それが検出される方法の、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は、この状態の間にパケットを転送し続けることができます。また、ラウンドロビン方式で任意の設定されたセカンダリのCEを通じてリサイクルしてもよい（MAY）。これは、最初のバックアップ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が接続を回復するために使用するのForCESメッセージシーケンスを示す図です。
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同期プロトコルは、高速フェイルオーバーをサポートするだけでなく、コーナーケースの一部に対処するために必要とされるであろう。それは本明細書の範囲外であり、しかし、これはのForCESプロトコルによって定義されることはありません。
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からの明示的なメッセージ（Configメッセージ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.
また、（これは本明細書の範囲外であるCE-CE同期プロトコルの使用を想定している）のForCESのNEでのFEはまた、マルチキャストCEのIDを使用することができ、すなわち、それらはCEのグループに関連付けることができることに注意してください。この場合には、関連の損失は、CEの全マルチキャストグループとの通信が失われたことを意味します。上記機構は、関連の損失時にも、この場合に適用されます。しかし、二次CEはまた、失われたマルチキャストCEのIDを使用していた場合、FEは異なるCEのIDを使用して、新しいアソシエーションを形成する必要があります。能力が存在する場合、FEは、第異なる非マルチキャストCEのIDを使用して、元の一次CEとの新たな関連付けを形成することを試みることができます。
TML level:
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の失敗（イベントレポート）を報告するために使用されるプロトコルメッセージ、関連の障害を検出するために使用されるハートビートメッセージを識別するために使用されるCEのIDは、主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.
主CEへのパスがダウンしている場合は、1つが利用可能な場合一緒に2を入れて、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.
ForCESフレームワークドキュメント[RFC3746]、セクション8には、セキュリティ上の脅威、プロトコル上でこれらの脅威の可能性のある影響、およびそれらの脅威に対する応答の様々な大規模なディテールに入ります。この文書では、その議論を繰り返しません。読者はこれらの詳細についてのForCESフレームワークドキュメント[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はのForCES TMLが提供するセキュリティ・サービスを使用しています。 TMLは、エンドポイントの認証サービス、メッセージ認証サービス、および機密性サービスなどのセキュリティサービスを提供します。エンドポイント認証サービスは、FEまたはCEがピアからパケットを受信するたびに実行されるプリ関連コネクション確立フェーズとメッセージ認証時に呼び出されます。
The following are the general security mechanisms that need to be in place for ForCES PL.
次のForCES 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オペレータは、プライマリおよびバックアップのFEおよびCEの両方に同じセキュリティポリシーを設定する必要があります。これは、均一な運用を確保し、ポリシー設定に不必要な複雑さを避けることができます。
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.
「セキュリティなし」とのForCESプロトコル通信のために選択される場合、両方のエンドポイント認証とメッセージ認証サービスのForCES PLによって実行される必要があります。これらの両方のメカニズムが弱く、暗号操作を伴いません。 ForCESプロトコルエンドポイントは、例えば、単一のボックス内にあるとき、オペレータは、「セキュリティなし」レベルを選択することができます。
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.1.1項および9.1.2項に）、以下に説明されるどのようなエラーチェックではなく、セキュリティの手順があります。読者は、セキュリティ手順については、セクション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を介して構成されているだけのCEに接続する必要があります。同様に、CEは接続を受け入れ、CEMを介して構成されているのFEのためのアソシエーションを確立すべきです。 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のセキュリティ・サービスを使用したい場合は、このセクションでは、適用されます。 ForCES TMLはTMLセキュリティレイヤ機能の一部として、そのようなエンドポイントの認証サービス、メッセージ認証サービス、および機密性サービスなどの1つまたは複数のセキュリティ・サービスをサポートしなければなりません。適切なセキュリティサービスを選択し、それに応じてセキュリティポリシーを設定するには、オペレータの責任です。このような構成の詳細のForCES 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で使用されている場合、証明書は、証明書の名前としてのForCES固有の命名構造を使用することができ、従って、セキュリティポリシーは、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のセキュリティサービスが有効になっている場合は強制し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.
このドキュメントの作者は感謝し、強制的にワーキンググループ、特に以下の感謝ます：Furquanアンサリ、アレックスAudu、スティーブ・ブレイク、Shuchiチャウラ、アランDeKok、エレンM. Deleganes、Xiaoyi郭、Yunfei郭、Evangelos Haleplidis、ジョルトを彼らの貢献のためHaraszti、Fenggen嘉、ジョンC.林、アリステア・マンロー、ジェフ・ピカリング、T. Sridhlar、光明王、Chaoping呉、とリリーL.ヤン、。また、プロトコル上の彼らのコメントや提案をし、彼らの無限の忍耐のためのデビッドPutzoluとパトリックドローに感謝したいと思います。また、文書の大規模なレビューのためにスーノウサギとアリアアトラスに感謝したいと思います。
Alia Atlas did a wonderful job of shaping the document to make it more readable by providing the IESG feedback.
アリアアトラスは、IESGのフィードバックを提供することによって、それを読みやすくするために文書を整形する素晴らしい仕事をしました。
Ross Callon was instrumental in getting us over major humps to getting this document published.
ロスCallonは公表され、この文書を取得する主要なこぶの上に私たちを得ることに尽力しました。
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ソースの補正に彼の助けのためのエルウィン・デイヴィスに感謝です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、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]ハディサリム、J.及びK.小川、 "転送および制御素子分離用SCTPベースのトランスポート・マッピング・レイヤ（TML）（のForCES）プロトコル"、RFC 5811、2010年月。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.
[RFC5812]アルペルン、J.およびJ.ハディサリム、 "転送および制御素子分離（のForCES）転送要素モデル"、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]グレー、J.は、「上級コースオペレーティングシステム」で、「データベース・オペレーティング・システム上での注意事項」。 60頁394から481、シュプリンガー・フェアラーク、1978。
[ACID] Haerder, T. and A. Reuter, "Principles of Transaction-Orientated Database Recovery", 1983.
[ACID]ハーダー、T.とA.ロイター、「トランザクション指向データベースの回復の原則」、1983年。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]ローズ、M.、 "ライティングI-DSおよびXMLを使用している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.アンダーソン、 "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]ヤン、L.、Dantu、R.、アンダーソン、T.、およびR.ゴパル、 "転送および制御素子分離（のForCES）フレームワーク"、RFC 3746、2004年4月。
Appendix A. IANA Considerations
付録A. IANAの考慮事項
Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following namespaces are defined in ForCES.
「RFCでIANA問題部に書くためのガイドライン」（RFC 5226 [RFC5226]）で概説された方針に続いて、次の名前空間は、力の定義されています。
o Message Type Namespace, Section 7
メッセージタイプのネームスペース、セクション7 O
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
TLVタイプ、セクション7 O
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].
LFBクラスID、セクション7.1.5（モデルドキュメントによって解決、[RFC5812] O。
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
A.1. Message Type Namespace
A.1。メッセージタイプのネームスペース
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
0x00の予約が0x01 0x02のAssociationSetup AssociationTeardown 0x03のコンフィグ0x04のクエリ0x05のEventNotification 0x06のPacketRedirect 0x07の - 0x0Eの予約0x0FのHearbeat 0x11をAssociationSetupResponseの0x12予約0x13を0x14にConfigResponse 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管理は不要です。
A.2. Operation Selection
A.2。動作選択
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タイプ0x0000-0x0FF OPER-TLVタイプは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 OPER-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タイプは、ベンダプライベート拡張のために予約し、個々のベンダーの責任とされています。 OPER-TLVタイプの名前空間のこの範囲のIANA管理は不要です。
A.3. Header Flags
A.3。ヘッダーフラグ
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].
A.4. TLV Type Namespace
A.4。 TLVタイプネームスペース
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管理は不要です。
A.5. RESULT-TLV Result Values
A.5。 RESULT-TLVの結果値
The RESULT-TLV RTesult Value is an 8-bit value.
RESULT-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
All values not assigned in this specification are designated as Assignment by Expert Review.
この仕様で割り当てられていないすべての値は、専門家レビューにより割り当てに指定されています。
A.6. Association Setup Response
A.6。協会のセットアップ応答
The Association Setup Response namespace is 32 bits long. The following is the guideline for managing the Association Setup Response namespace.
協会のセットアップ応答の名前空間は32ビット長です。以下は、協会のセットアップ応答の名前空間を管理するためのガイドラインです。
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
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協会セットアップ応答は、ベンダプライベート拡張のために予約し、個々のベンダーの責任とされています。協会セットアップ応答名前空間のこの範囲のIANA管理は不要です。
A.7. Association Teardown Message
A.7。協会ティアダウンメッセージ
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-0x0000FFFF関連ティアダウンメッセージは、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
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-0xFFFFFFFFF協会ティアダウンメッセージは、ベンダプライベート拡張のために予約し、個々のベンダーの責任とされています。協会ティアダウンメッセージの名前空間のこの範囲のIANA管理は不要です。
Appendix B. ForCES Protocol LFB Schema
付録B.のForCESプロトコルLFBスキーマ
The schema described below conforms to the LFB schema described in the ForCES model [RFC5812].
以下に記載するスキーマは、のForCESモデル[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>
<LFBLibraryのxmlns = "壷：IETF：のparams：XML：NS：力：lfbmodel：1.0" のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance" = "のFePO" 提供> <！ - XXX - > <dataTypeDefs> <dataTypeDef> <名前> CEHBPolicyValues </名前> <概要> CEハートビートポリシーの可能な値</シノプシス> <原子> <baseType> UCHAR </ baseType> <specialValues> <specialValue値= "0"> <名前> CEHBPolicy0 </名前> <概要> CEハートビートポリシー0 </概要> </ specialValue> <specialValue値= "1"> <名前> CEHBPolicy1 </名前> <概要> CEハートビートポリシー1 </概要> </ specialValue> </ specialValues> </原子> </ 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>
<specialValue値= "0"> <名前> FEHBPolicy0 </名前> <概要> FEハートビートポリシー0 </概要> </ specialValue> <specialValue値= "1"> <名前> FEHBPolicy1 </名前> <概要> FEハートビートポリシー1 </概要> </ specialValue> </ specialValues> </原子> </ 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> <名前> FERestartPolicyValues </名前> <概要> FE再起動ポリシーの可能な値</シノプシス> <原子> <baseType> UCHAR </ baseType> <specialValues> <specialValue値= "0"> <名前> FERestartPolicy0 </名前> <概要> FE再起動ポリシー0 </概要> </ specialValue> </ specialValues> </アトミック> </ 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>
<dataTypeDef> <名前> CEFailoverPolicyValues </名前> <概要> CE・フェイルオーバー・ポリシーの可能な値</シノプシス> <原子> <baseType> UCHAR </ baseType> <specialValues> <specialValue値= "0"> <名前> CEFailoverPolicy0 </名前> <概要> CEのフェイルオーバー・ポリシー0 </概要> </ specialValue>
<specialValue value="1"> <name>CEFailoverPolicy1</name> <synopsis> The CE failover policy 1 </synopsis> </specialValue> </specialValues> </atomic> </dataTypeDef>
<specialValue値= "1"> <名前> CEFailoverPolicy1 </名前> <概要> CE・フェイルオーバー・ポリシー1 </概要> </ specialValue> </ specialValues> </原子> </ 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>
<dataTypeDef> <名前> FEHACapab </名前> <概要>サポートされているHA機能</シノプシス> <原子> <baseType> UCHAR </ baseType> <specialValues> <specialValue値= "0"> <名前> GracefullRestart </ > <概要> FEは、グレースフルリスタート</概要> </ specialValue> <specialValue値= "1" をサポートしている名前> <名前> HA </名前> <概要> FEは、HA </概要> </ specialValue> <をサポートしています/ specialValues> </アトミック> </ dataTypeDef> </ dataTypeDefs>
<LFBClassDefs> <LFBClassDef LFBClassID="2"> <name>FEPO</name> <synopsis> The FE Protocol Object </synopsis> <version>1.0</version>
<LFBClassDefs> <LFBClassDef LFBClassID = "2"> <名前>のFePO </名前> <概要> FEプロトコルオブジェクト</シノプシス>の<version> 1.0 </バージョン>
<components> <component componentID="1" access="read-only"> <name>CurrentRunningVersion</name> <synopsis>Currently running ForCES version</synopsis> <typeRef>uchar</typeRef>
<成分> <コンポーネントのComponentID = "1" アクセス= "読み取り専用"> <名前> CurrentRunningVersion </名前> <概要>現在実行中のForCESバージョン</シノプシス> <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>
<TypeRef> UINT32 </ typeRef> </成分>
<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>
<成分COMPONENTID =「9」アクセス=「読み書き」> <名前> BackupCEs </名前> <概要>プライマリ</シノプシス> <配列型=「可変サイズ」>以外のすべてのバックアップCEのテーブル<typeRef> UINT32 </ typeRef> </アレイ> </コンポーネント> <コンポーネントのComponentID = "10" アクセス= "読み書き"> <名前> CEFailoverPolicy </名前> <概要> CEフェイルオーバー・ポリシー</概要> <typeRef> CEFailoverPolicyValues </ typeRef> </成分>
<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>
<成分COMPONENTID = "11" アクセス= "読み書き"> <名前> CEFTI </名前> <概要> millisecsにおけるCEフェイルオーバタイムアウト間隔</シノプシス> <typeRef> UINT32 </ typeRef> </成分> <コンポーネントCOMPONENTID = "12" アクセス= "読み書き"> <名前> FERestartPolicy </名前> <概要> FE再起動ポリシー</概要> <typeRef> FERestartPolicyValues </ typeRef> </部品> <コンポーネントCOMPONENTID =」 13" アクセス= "読み書き"> <名前> LastCEID </名前> <概要>このFEは</シノプシス> <typeRef> UINT32 </ typeRef> </成分> </部品>と最後に関連付けられたプライマリCE
<capabilities> <capability componentID="30"> <name>SupportableVersions</name> <synopsis> the table of ForCES versions that FE supports
<機能> <機能COMPONENTID = "30"> <名前> SupportableVersions </名前> <あらすじ>のForCESバージョンFEサポートのテーブル
</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>
</シノプシス> <配列型= "可変サイズ"> <typeRef> UCHAR </ typeRef> </アレイ> </機能> <能力COMPONENTID = "31"> <名前> HACapabilities </名前> <概要> HA機能のテーブルは、FEがサポート</シノプシス> <配列型= "可変サイズ"> <typeRef> FEHACapab </ typeRef> </アレイ> </機能> </機能>
<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>
<イベントbaseID = "61"> <イベントのeventID = "1"> <名前> PrimaryCEDown </名前> <概要> pimary CEが変更された</シノプシス> <のEventTarget> <eventField> LastCEID </ eventField> </のEventTarget > <eventChanged /> <eventReports> <eventReport> <eventField> LastCEID </ eventField> </ eventReport> </ eventReports> </イベント> </イベント>
</LFBClassDef> </LFBClassDefs> </LFBLibrary>
</ LFBClassDef> </ LFBClassDefs> </ LFBLibrary>
B.1. Capabilities
B.1。機能
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に参加することはできません。
B.2. Components
B.2。コンポーネント
All components are explained in Section 7.3.1.
すべてのコンポーネントは、7.3.1項で説明されています。
Appendix C. Data Encoding Examples
付録C.データ符号化の例
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つの固定-lengthof、必須フィールドを持つ構造体。
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)
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)
==========
Example 2:
==========
Structure with three fixed-lengthof fields, one mandatory, two optional.
3固定lengthofフィールド、必須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)
(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)
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.
固定lengthofと可変lengthofフィールド、いくつかの必須、いくつかのオプションが混在する構造。この場合には注意、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)
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）[]エンコードされているだけ10およびZ 15の添え字を想定し、またSPARSEDATA-TLVて説明Z []の2つのインスタンスと、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.
（15続く10）Zのコンポーネントの穴に注意してください。また、唯一の成分Aおよび出現Cが、Bではないとインデックス15の隙間に注意してください。
Appendix D. Use Cases
付録D.ユースケース
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
TABLE1：型アレイ、ID = 3つの成分である：T1、型U32、ID = 1、T2、型U32、ID = 2 //インデックステーブル2の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 }
表2：型アレイ、ID = 4つの成分である：J1、型U32、ID = 1 J2、型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、型U32、ID = 1名、文字列型変数サイズ、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}
表4：型アレイ、ID = 6の構成要素は、次のとおりJ1、型U32、ID = 1 J2、型U32、ID = 2 J3、型U32、ID = 3 J4、型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}
タイプX：X 1、ID 1、タイプU32×2、ID2、型U32のKEY：処理鍵、ID = 1、V = {X 1}
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の値を示すためのvalueOf（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を参照。
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)
OPER = GET-TLV PATH-DATA-TLV：IDCOUNT = 1、のID = 1の検索結果：OPER = GET-RESPONSE-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 1、IDが= 1 FULLDATA-TLVのL = 4 +4、V =のvalueOf（foo1の）
OPER = SET-TLV PATH-DATA-TLV: flags = 0, IDCount = 1, IDs = 2 FULLDATA-TLV: L = 4+4, V=10
OPER = SET-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 1、IDが= 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：フラグ= 0、IDCOUNT = 1、IDが= 2 RESULT-TLV
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
OPER = GET-TLV PATH-DATA-TLV：IDCOUNT = 1、のID = 4の検索結果：OPER = GET-RESPONSE-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 1、IDが= 4 FULLDATA-TLV：L = XXX、Vは一連=：表全体を表す指標を、のvalueOf（J1）のvalueOf（J2）
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に変換することができるはずです。上記の例の結果は、SET-TLV（代わりにGET-RESPONSE_TLVの）に返送された場合、テーブルの全内容は、その時点で交換されます。
4. Multiple operations example. To create entry 0-5 of table2 (Error conditions are ignored)
前記複数の動作例。表2のエントリ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
OPER = SET-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 1、IDは= 4 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 0 FULLDATA-TLV用のvalueOf（J1）のvalueOf（J2）エントリ1 PATH-DATA-TLVフラグのエントリ0 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 1 FULLDATA-TLV用のvalueOf（J1）のvalueOf（J2）の= 0、IDCOUNT = 1、IDが= 2 FULLDATA-TLVのvalueOf（J1）のvalueOfエントリー2 PATH-DATA-TLVフラグの（J2）= 0、IDCOUNT = 1、のID = 3 FULLDATA-TLV用のvalueOf（J1）のvalueOf（J2）エントリの3 PATH-DATA- TLVフラグ= 0、IDCOUNT = 1、IDが= 4 FULLDATA-TLV用のvalueOf（J1）のvalueOfエントリの（J2）4 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 5 FULLDATA-TLV用のvalueOf（J1）エントリー5、のvalueOf（J2）
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
結果：OPER = SET-RESPONSE-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 1、IDが= 4 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 0 RESULT-TLV PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 1 RESULT-TLV経路-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 2 RESULT-TLV経路-DATA-TLVフラグ= 0、IDCOUNT = 1、のID = 3 RESULT -TLV PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 4 RESULT-TLV PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 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
OPER = SET-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 1、IDは= 4 PATH-DATA-TLVフラグ= 0、のvalueOf（J1）を含有IDCOUNT = 1、IDが= 0 FULLDATA-TLV、のvalueOf（J2 2のvalueOf（J1）のvalueOf（J2）を含む）0 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 2 FULLDATA-TLV
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
結果：OPER = SET-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 1、IDが= 4 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 0 RESULT-TLV PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 2 RESULT-TLV
OPER = GET-TLV PATH-DATA-TLV: IDCount = 2, IDs = 4.0
OPER = GET-TLV PATH-DATA-TLV：IDCOUNT = 2、IDを= 4.0
Result: OPER = GET-RESPONSE-TLV PATH-DATA-TLV: IDCount = 2, IDs = 4.0 FULLDATA-TLV containing valueof(j1), valueof(j2)
結果：OPER = GET-RESPONSE-TLV経路-DATA-TLV：IDCOUNT = 2、IDが= 4.0のvalueOf（J1）を含有FULLDATA-TLV、のvalueOf（J2）
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
OPER = GET-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 1、IDが= 4 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 0 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1 、のID = 1 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 2 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、のID = 3 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 4 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 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)
結果：OPER = GET-RESPONSE-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 1、IDが= 4 PATH-DATA-TLVフラグ= 0、のvalueOfを含むIDCOUNT = 1、IDが= 0 FULLDATA-TLV（J1） 、のvalueOf（J2）PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 1 FULLDATA-TLVのvalueOf（J1）を含有する、のvalueOf（J2）PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 2 valueOf（J1）を含むのvalueOf（J1）を含有FULLDATA-TLV、のvalueOf（J2）PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、のID = 3 FULLDATA-TLV、のvalueOf（J2）PATH-DATA-TLVフラグ= 0 valueOf（J1）のvalueOf（J2）を含む、IDCOUNT = 1、IDが= 4 FULLDATA-TLVのvalueOf（J1）を含有する、のvalueOf（J2）PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 5 FULLDATA-TLV
OPER = SET-TLV PATH-DATA-TLV: flags = 0, IDCount = 2, IDs = 4.5 FULLDATA-TLV containing valueof(j1), valueof(j2)
OPER = SET-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 2、IDが= 4.5 FULLDATA-TLV含有の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：フラグ= 0、IDCOUNT = 1、IDを= 4.5 RESULT-TLV
OPER = GET-TLV PATH-DATA-TLV: flags = 0, IDCount = 1, IDs = 3
OPER = GET-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 1、IDを= 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フラグ= 0、IDCOUNT = 1、のID = 3 FULLDATA-TLV、長さ= XXXX（TABLE1のサイズに応じて）インデックス、のvalueOf（T1）のvalueOf（T2）インデックスの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テーブルからの行のエントリを取得します。リコールは、J1は、このテーブルの定義されたキーであり、そのキーIDは1です。
OPER = GET-TLV PATH-DATA-TLV: flags = F_SELKEY IDCount = 1, IDs = 6 KEYINFO-TLV = KeyID=1, KEY_DATA=100
OPER = GET-TLV PATH-DATA-TLV：フラグ= F_SELKEY IDCOUNT = 1、IDは= 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)
結果：J1 = 100、インデックス10 OPER = GET-RESPONSE-TLV経路-DATA-TLVであった場合は、次のフラグ= 0、IDCOUNT = 1、IDを= 6.10 FULLDATA-TLV含有の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、J 2 = 200）KEY一致して行を削除します。 J1、J2のペアは、表2のために定義されたキーであることに注意してください。
OPER = DEL-TLV PATH-DATA-TLV: flags = F_SELKEY IDCount = 1, IDs = 4 KEYINFO-TLV: {KeyID =1 KEY_DATA=100,200}
OPER = DEL-TLV経路-DATA-TLV：フラグ= F_SELKEY IDCOUNT = 1、のID = 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
結果：OPER = DELETE-RESPONSE-TLV PATH-DATA-TLV：（J1 = 100、J 2 = 200）場合、エントリで15であったフラグ= 0 IDCOUNT = 2のID = 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.
表3の12ダンプの内容。なお、このテーブルは、サイズ可変である部品名を持つ列を有していることに留意すべきです。この使用例の目的は、そのような成分が符号化される方法を示すことです。
OPER = GET-TLV PATH-DATA-TLV: flags = 0 IDCount = 1, IDs = 5
OPER = GET-TLV PATH-DATA-TLV：フラグ= 0 IDCOUNT = 1、IDを= 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：フラグ= 0 IDCOUNT = 1、IDが= 5 FULLDATA-TLV、長さ= XXXXインデックス、someidv、TLV：T = FULLDATA-TLV、L = 4 + STRLEN（ namev）、Vは=のvalueOf（V）インデックス、someidv、TLV：T = FULLDATA-TLV、L = 4 + STRLEN（namev）、Vは=のvalueOf（V）インデックス、someidv、TLV：T = FULLDATA-TLV、L = 4 + STRLEN（namev）、V =のvalueOf（V）インデックス、someidv、TLV：T = FULLDATA-TLV、L = 4 + STRLEN（namev）、Vは=のvalueOf（V）。 。 。
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.
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)
//オペレーション1：表2インデックス＃20に新しいエントリを追加します。 OPER = SET-TLVパスTLV：フラグ= 0、IDCOUNT = 2のID = 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
//操作2：//がT2で指した更新TABLE1エントリ= 10が今20 OPER = SET-TLV PATH-DATA-TLVを指すように：フラグ= F_SELKEY、IDCOUNT = 1、のID = 3のKeyInfo-TLV = KeyIDを= 1 KEY_DATA = 10 PATH-DATA-TLVフラグ= 0 IDCOUNT = 1、IDが= 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
結果：//最初の操作、SET OPER = SET-RESPONSE-TLV PATH-DATA-TLVフラグ= 0 IDCOUNT = 3、IDを= 4.20 RESULT-TLVコード=成功FULLDATA-TLV、V =のvalueOf（J1）のvalueOf（J2 ）//第2の動作セット - 想定エントリ16が更新されたOPER = SET-RESPONSE-TLV PATH-DATA-TLVフラグ= 0 IDCOUNT = 2のID = 3.16 PATH-DATA-TLVフラグ= 0 IDCOUNT = 1、IDが= 2 RESULT -TLVコード=成功FULLDATA-TLV、長さ= 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 300脱退J4 200へJ2 100 J1、J3を交換します。
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}
PER = SET-TLV PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 6 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 1 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、 ID = 1 FULLDATA-TLV、長さ= XXXX、V = {100} PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 2 FULLDATA-TLV、長さ= XXXX、V = {200} PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、のID = 3 FULLDATA-TLV、長さ= XXXX、V = {300} PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、のID = 3 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 1 FULLDATA-TLV、長さ= XXXX、V = {100} PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 2 FULLDATA-TLV、長さ= XXXX、V = {200} PATH- DATA-TLVフラグ= 0、IDCOUNT = 1、のID = 3 FULLDATA-TLV、長さ= 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
OPER = SET-RESPONSE-TLV PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 6 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 1 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 1 RESULT-TLV PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 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操作。表5のエントリー10の内部に、指標4と表10行からX1を得ます。
operation = GET-TLV PATH-DATA-TLV flags = 0 IDCount = 5, IDs=7.10.2.4.1
操作= GET-TLV PATH-DATA-TLVフラグ= 0 IDCOUNT = 5、IDを= 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)
結果：操作= GET-RESPONSE-TLV PATH-DATA-TLVフラグ= 0 IDCOUNT = 5、IDが= 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).
表5の行10表10から16、（リコールx1がKeyIDを1である）10に等しいX1の値に基づいて、X2Sを得ます。
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
オペレーション= GET-TLV PATH-DATA-TLVフラグ= F_SELKEY、IDCOUNT = 3、IDS = 7.10.2のKeyInfo-TLV、KeyIDを= 1、KEYDATA = 10 PATH-DATA-TLV IDCOUNT = 1、IDS = 2×2を選択//
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)
結果：X1 = 10エントリで11であった場合は、次の操作= GET-RESPONSE-TLV PATH-DATA-TLVフラグ= 0、IDCOUNT = 5、IDS = 7.10.2.11 PATH-DATA-TLVフラグ= 0 IDCOUNT = 1、IDS = 2 FULLDATA-TLV：L = XXXX、V =のvalueOf（X2）
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：タイプアレイ、ID = 8つの部品である：P1、タイプU32、ID = 1、P2、型アレイ、ID = 2、タイプtype-Aの配列要素として定義されている考える表6、
type-A: a1, type u32, ID 1, a2, type array ID2 ,array components of type type-B
タイプA：A1、型U32、ID 1、A2、型配列ID2、タイプtype-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
333に222 table6.10.p2.20.a2.30.b1に111 table6.10.p2.20.a1にtable6.10.p1：一例のために交換することによって設定したい場合
in one message and one operation.
一つのメッセージと、一回の操作インチ
There are two ways to do this: a) using nesting b) using a flat path data
これを行うには二つの方法があります：a）は、ネストBを使用して）フラットパスデータを使用して
A. Method using nesting in one message with a single operation
単一の操作で一つのメッセージにネスティングを使用する方法A.
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}
オペレーション= SET-TLV経路-DATA-TLVフラグ= 0 IDCOUNT = 2のID = 6.10 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 1 FULLDATA-TLV：L = XXXX、V = {111} PATH -DATA-TLVフラグ= 0 IDCOUNT = 2のID = 2.20 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 1 FULLDATA-TLV：L = XXXX、V = {222} PATH-DATA-TLV：フラグ= 0、IDCOUNT = 3、IDが= 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
結果：操作= SET-RESPONSE-TLV PATH-DATA-TLVフラグ= 0 IDCOUNT = 2のID = 6.10 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 1 RESULT-TLV PATH-DATA-TLVフラグ= 0 IDCOUNT = 2のID = 2.20 PATH-DATA-TLVフラグ= 0、IDCOUNT = 1、IDが= 1 RESULT-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 3、IDが= 2.30.1 RESULT-TLV
B. Method using a flat path data in one message with a single operation
単一の操作で一つのメッセージにおけるフラットパスデータを使用してB.方法
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
オペレーション= SET-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 3、IDが= 6.10.1 FULLDATA-TLV：L = XXXX、V = {111} PATH-DATA-TLV：フラグ= 0、IDCOUNT = 5 、のID = 6.10.1.20.1 FULLDATA-TLV：L = XXXX、V = {222} PATH-DATA-TLV：フラグ= 0、IDCOUNT = 7、のID = 6.10.1.20.1.30.1 FULLDATA-TLV：L = XXXX、V = {333}結果：動作= SET-TLV経路-DATA-TLV：= 0フラグ、IDCOUNT = 3、IDが= 6.10.1 RESULT-TLV経路-DATA-TLV：フラグ= 0、IDCOUNT = 5、 IDが= 6.10.1.20.1 RESULT-TLV PATH-DATA-TLV：フラグ= 0、IDCOUNT = 7、のID = 6.10.1.20.1.30.1 RESULT-TLV
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:
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
結果：FEの動作= GET-RESPONSE-TLV PATH-DATA-TLVフラグ= 0 IDCOUNT = 0 FULLDATA-TLVエンコーディングLFBオブジェクト
Authors' Addresses
著者のアドレス
Avri Doria (editor) Lulea University of Technology Rainbow Way Lulea SE-971 87 Sweden
Avriドリア（エディタ）ルレオ工科大学の虹の道ルーレオSE-971 87スウェーデン
Phone: +46 73 277 1788 EMail: avri@ltu.se
電話：+46 73 277 1788 Eメール：avri@ltu.se
Jamal Hadi Salim (editor) Znyx Ottawa, Ontario Canada
ジャマル・ハディサリム（エディタ）ZNYXオタワ、オンタリオ州カナダ
Phone: EMail: hadi@mojatatu.com
電話番号：Eメール：hadi@mojatatu.com
Robert Haas (editor) IBM Saumerstrasse 4 8803 Ruschlikon Switzerland
ロバート・ハース（編集者）IBM Saumerstrasse 4 8803リュシュリコンスイス
Phone: EMail: rha@zurich.ibm.com
電話番号：Eメール：rha@zurich.ibm.com
Hormuzd M Khosravi (editor) Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
Hormuzd M Khosravi（エディタ）インテル2111 NE 25日アベニューヒルズボロ、OR 97124 USA
Phone: +1 503 264 0334 EMail: hormuzd.m.khosravi@intel.com
電話：+1 503 264 0334 Eメール：hormuzd.m.khosravi@intel.com
Weiming Wang (editor) Zhejiang Gongshang University 18, Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China
魏名王（エディタ）Z Hejiang行くアグリビジネス大学18、X UE正STR。、Ξアシャ大学町杭州310018中華人民共和国
Phone: +86-571-28877721 EMail: wmwang@zjgsu.edu.cn
電話：+ 86-571-28877721電子メール：wmwang@zjgsu.edu.cn
Ligang Dong Zhejiang Gongshang University 18, Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China
L Iは、シリンダ洞Zは、AIB大学18、X UE正STR。、ξアシャ大学町杭州310018中華人民共和国をhejiang行きます
Phone: +86-571-28877751 EMail: donglg@zjgsu.edu.cn
電話：+ 86-571-28877751電子メール：donglg@zjgsu.edu.cn
Ram Gopal Nokia 5, Wayside Road Burlington, MA 310035 USA
ラムゴパルノキア5、道端の道路バーリントン、マサチューセッツ310035 USA
Phone: +1-781-993-3685 EMail: ram.gopal@nsn.com
電話：+ 1-781-993-3685 Eメール：ram.gopal@nsn.com
Joel Halpern P.O. Box 6049 Leesburg, VA 20178 USA
ジョエルハルパーンの私書箱ボックス6049リーズバーグ、VA 20178 USA
Phone: +1-703-371-3043 EMail: jmh@joelhalpern.com
電話：+ 1-703-371-3043 Eメール：jmh@joelhalpern.com