[要約] RFC 5812は、ForCES Forwarding Element Modelに関する標準仕様です。このRFCの目的は、ネットワーク機器の転送機能と制御機能を分離するためのモデルを提供することです。
Internet Engineering Task Force (IETF) J. Halpern
Request for Comments: 5812 Self
Category: Standards Track J. Hadi Salim
ISSN: 2070-1721 Znyx Networks
March 2010
Forwarding and Control Element Separation (ForCES) Forwarding Element Model
転送および制御要素分離（力）転送要素モデル
Abstract
概要
This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol. The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in RFC 3654.
このドキュメントでは、転送および制御要素分離（力）プロトコルで使用される転送要素（FE）モデルを定義します。このモデルは、力プロトコルのコンテキスト内で転送要素の機能、状態、および構成を表し、制御要素（CE）がそれに応じてFESを制御できるようにします。より具体的には、モデルは、FEに存在する論理関数、これらの関数がサポートする機能、およびこれらの関数がどのように相互接続されるかを説明します。このFEモデルは、RFC 3654で指定されたモデル要件を満たすことを目的としています。
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/rfc5812.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5812で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................5
1.1. Requirements on the FE Model ...............................5
1.2. The FE Model in Relation to FE Implementations .............6
1.3. The FE Model in Relation to the ForCES Protocol ............6
1.4. Modeling Language for the FE Model .........................7
1.5. Document Structure .........................................8
2. Definitions .....................................................8
3. ForCES Model Concepts ..........................................10
3.1. ForCES Capability Model and State Model ...................12
3.1.1. FE Capability Model and State Model ................12
3.1.2. Relating LFB and FE Capability and State Model .....14
3.2. Logical Functional Block (LFB) Modeling ...................14
3.2.1. LFB Outputs ........................................18
3.2.2. LFB Inputs .........................................21
3.2.3. Packet Type ........................................24
3.2.4. Metadata ...........................................24
3.2.5. LFB Events .........................................27
3.2.6. Component Properties ...............................28
3.2.7. LFB Versioning .....................................29
3.2.8. LFB Inheritance ....................................29
3.3. ForCES Model Addressing ...................................30
3.3.1. Addressing LFB Components: Paths and Keys ..........32
3.4. FE Data Path Modeling .....................................32
3.4.1. Alternative Approaches for Modeling FE Data Paths ..33
3.4.2. Configuring the LFB Topology .......................37
4. Model and Schema for LFB Classes ...............................41
4.1. Namespace .................................................42
4.2. <LFBLibrary> Element ......................................42
4.3. <load> Element ............................................44
4.4. <frameDefs> Element for Frame Type Declarations ...........45
4.5. <dataTypeDefs> Element for Data Type Definitions ..........45
4.5.1. <typeRef> Element for Renaming Existing
Data Types .........................................49
4.5.2. <atomic> Element for Deriving New Atomic Types .....49
4.5.3. <array> Element to Define Arrays ...................50
4.5.4. <struct> Element to Define Structures ..............54
4.5.5. <union> Element to Define Union Types ..............56
4.5.6. <alias> Element ....................................56
4.5.7. Augmentations ......................................57
4.6. <metadataDefs> Element for Metadata Definitions ...........58
4.7. <LFBClassDefs> Element for LFB Class Definitions ..........59
4.7.1. <derivedFrom> Element to Express LFB Inheritance ...62
4.7.2. <inputPorts> Element to Define LFB Inputs ..........62
4.7.3. <outputPorts> Element to Define LFB Outputs ........65
4.7.4. <components> Element to Define LFB
Operational Components .............................67
4.7.5. <capabilities> Element to Define LFB
Capability Components ..............................70
4.7.6. <events> Element for LFB Notification Generation ...71
4.7.7. <description> Element for LFB Operational
Specification ......................................79
4.8. Properties ................................................79
4.8.1. Basic Properties ...................................79
4.8.2. Array Properties ...................................81
4.8.3. String Properties ..................................81
4.8.4. Octetstring Properties .............................82
4.8.5. Event Properties ...................................83
4.8.6. Alias Properties ...................................87
4.9. XML Schema for LFB Class Library Documents ................88
5. FE Components and Capabilities .................................99
5.1. XML for FEObject Class Definition .........................99
5.2. FE Capabilities ..........................................106
5.2.1. ModifiableLFBTopology .............................106
5.2.2. SupportedLFBs and SupportedLFBType ................106
5.3. FE Components ............................................110
5.3.1. FEState ...........................................110
5.3.2. LFBSelectors and LFBSelectorType ..................110
5.3.3. LFBTopology and LFBLinkType .......................110
5.3.4. FENeighbors and FEConfiguredNeighborType ..........111
6. Satisfying the Requirements on the FE Model ...................111
7. Using the FE Model in the ForCES Protocol .....................112
7.1. FE Topology Query ........................................115
7.2. FE Capability Declarations ...............................116
7.3. LFB Topology and Topology Configurability Query ..........116
7.4. LFB Capability Declarations ..............................116
7.5. State Query of LFB Components ............................118
7.6. LFB Component Manipulation ...............................118
7.7. LFB Topology Reconfiguration .............................118
8. Example LFB Definition ........................................119
8.1. Data Handling ............................................126
8.1.1. Setting Up a DLCI .................................127
8.1.2. Error Handling ....................................127
8.2. LFB Components ...........................................128
8.3. Capabilities .............................................128
8.4. Events ...................................................129
9. IANA Considerations ...........................................130
9.1. URN Namespace Registration ...............................130
9.2. LFB Class Names and LFB Class Identifiers ................130
10. Authors Emeritus .............................................132
11. Acknowledgments ..............................................132
12. Security Considerations ......................................132
13. References ...................................................132
13.1. Normative References ....................................132
13.2. Informative References ..................................133
RFC 3746 [RFC3746] specifies a framework by which control elements (CEs) can configure and manage one or more separate forwarding elements (FEs) within a network element (NE) using the ForCES protocol. The ForCES architecture allows forwarding elements of varying functionality to participate in a ForCES network element. The implication of this varying functionality is that CEs can make only minimal assumptions about the functionality provided by FEs in an NE. Before CEs can configure and control the forwarding behavior of FEs, CEs need to query and discover the capabilities and states of their FEs. RFC 3654 [RFC3654] mandates that the capabilities, states and configuration information be expressed in the form of an FE model.
RFC 3746 [RFC3746]は、フォースプロトコルを使用してネットワーク要素（NE）内で1つ以上の個別の転送要素（FES）を構成および管理できるフレームワークを指定します。Force Architectureは、さまざまな機能の要素をForce Network Elementに参加させることを可能にします。このさまざまな機能の意味は、CESがNEのFESによって提供される機能について最小限の仮定しか行うことができないことです。CESがFESの転送挙動を構成および制御する前に、CESはFESの機能と状態を照会して発見する必要があります。RFC 3654 [RFC3654]は、機能、状態、構成情報がFEモデルの形で表現されることを義務付けています。
RFC 3444 [RFC3444] observed that information models (IMs) and data models (DMs) are different because they serve different purposes. "The main purpose of an IM is to model managed objects at a conceptual level, independent of any specific implementations or protocols used". "DMs, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs". Sometimes it is difficult to draw a clear line between the two. The FE model described in this document is primarily an information model, but also includes some aspects of a data model, such as explicit definitions of the LFB (Logical Functional Block) class schema and FE schema. It is expected that this FE model will be used as the basis to define the payload for information exchange between the CE and FE in the ForCES protocol.
RFC 3444 [RFC3444]は、情報モデル（IMS）とデータモデル（DM）が異なる目的を果たすため、異なることを観察しました。「IMの主な目的は、使用される特定の実装またはプロトコルとは無関係に、概念レベルで管理されたオブジェクトをモデル化することです」。「逆に、DMは抽象化の低いレベルで定義され、多くの詳細が含まれています。それらは実装者向けであり、プロトコル固有の構成要素を含みます」。2つの間に明確な線を引くことが難しい場合があります。このドキュメントで説明されているFEモデルは主に情報モデルですが、LFB（論理機能ブロック）クラススキーマの明示的な定義やFEスキーマなど、データモデルのいくつかの側面も含まれています。このFEモデルは、Force ProtocolのCEとFEの間の情報交換のペイロードを定義するための基礎として使用されることが予想されます。
RFC 3654 [RFC3654] defines requirements that must be satisfied by a ForCES FE model. To summarize, an FE model must define:
RFC 3654 [RFC3654]は、力FEモデルによって満たされなければならない要件を定義します。要約するには、FEモデルを定義する必要があります。
o Logically separable and distinct packet forwarding operations in an FE data path (Logical Functional Blocks or LFBs);
o FEデータパス（論理機能ブロックまたはLFB）での論理的に分離可能で異なるパケット転送操作。
o The possible topological relationships (and hence the sequence of packet forwarding operations) between the various LFBs;
o さまざまなLFB間のトポロジー関係（したがってパケット転送操作のシーケンス）。
o The possible operational capabilities (e.g., capacity limits, constraints, optional features, granularity of configuration) of each type of LFB;
o LFBの各タイプの可能な運用機能（容量制限、制約、オプションの機能、構成の粒度など）。
o The possible configurable parameters (e.g., components) of each type of LFB; and
o 各タイプのLFBの可能な構成可能なパラメーター（例：コンポーネント）。と
o Metadata that may be exchanged between LFBs.
o LFB間で交換されるメタデータ。
The FE model proposed here is based on an abstraction using distinct Logical Functional Blocks (LFBs), which are interconnected in a directed graph, and receive, process, modify, and transmit packets along with metadata. The FE model is designed, and any defined LFB classes should be designed, such that different implementations of the forwarding data path can be logically mapped onto the model with the functionality and sequence of operations correctly captured. However, the model is not intended to directly address how a particular implementation maps to an LFB topology. It is left to the forwarding plane vendors to define how the FE functionality is represented using the FE model. Our goal is to design the FE model such that it is flexible enough to accommodate most common implementations.
ここで提案されているFEモデルは、指示されたグラフに相互接続され、メタデータとともにパケットを受信、処理、修正、および送信される個別の論理機能ブロック（LFB）を使用した抽象化に基づいています。FEモデルが設計されており、定義されたLFBクラスを設計する必要があります。これにより、転送データパスのさまざまな実装をモデルに論理的にマッピングできるようにして、機能と一連の操作が正しくキャプチャされます。ただし、このモデルは、特定の実装がLFBトポロジにどのようにマップするかを直接対処することを意図したものではありません。FEモデルを使用してFE機能がどのように表現されるかを定義するために、フォワーディングプレーンベンダーに任されています。私たちの目標は、FEモデルを設計することで、最も一般的な実装に対応するのに十分な柔軟性を備えています。
The LFB topology model for a particular data path implementation must correctly capture the sequence of operations on the packet. Metadata generation by certain LFBs MUST always precede any use of that metadata by subsequent LFBs in the topology graph; this is required for logically consistent operation. Further, modification of packet fields that are subsequently used as inputs for further processing MUST occur in the order specified in the model for that particular implementation to ensure correctness.
特定のデータパス実装のLFBトポロジモデルは、パケットの一連の操作を正しくキャプチャする必要があります。特定のLFBによるメタデータの生成は、トポロジグラフの後続のLFBにより、常にそのメタデータの使用に先行する必要があります。これは、論理的に一貫した操作に必要です。さらに、その特定の実装のためにモデルで指定された順序で、さらに処理するための入力として使用されるパケットフィールドの変更が正しいことを保証する必要があります。
The ForCES base protocol [RFC5810] is used by the CEs and FEs to maintain the communication channel between the CEs and FEs. The ForCES protocol may be used to query and discover the intra-FE topology. The details of a particular data path implementation inside an FE, including the LFB topology, along with the operational capabilities and attributes of each individual LFB, are conveyed to the CE within information elements in the ForCES protocol. The model of an LFB class should define all of the information that needs to be exchanged between an FE and a CE for the proper configuration and management of that LFB.
Force Base Protocol [RFC5810]は、CESとFESによってCESとFES間の通信チャネルを維持するために使用されます。Force Protocolを使用して、FE内トポロジを照会して発見することができます。LFBトポロジを含むFE内の特定のデータパス実装の詳細と、各個々のLFBの運用機能と属性は、フォースプロトコルの情報要素内のCEに伝えられます。LFBクラスのモデルは、そのLFBの適切な構成と管理のために、FEとCEの間で交換する必要があるすべての情報を定義する必要があります。
Specifying the various payloads of the ForCES messages in a systematic fashion is difficult without a formal definition of the objects being configured and managed (the FE and the LFBs within). The FE model document defines a set of classes and components for describing and manipulating the state of the LFBs within an FE. These class definitions themselves will generally not appear in the ForCES protocol. Rather, ForCES protocol operations will reference classes defined in this model, including relevant components and the defined operations.
力メッセージのさまざまなペイロードを体系的に指定することは、構成および管理されているオブジェクト（FEおよびLFBS内）の正式な定義がなければ困難です。FEモデルドキュメントは、FE内のLFBの状態を記述および操作するためのクラスとコンポーネントのセットを定義します。これらのクラスの定義自体は、一般に、フォースプロトコルには表示されません。むしろ、Force Protocol操作は、関連するコンポーネントや定義された操作を含むこのモデルで定義されたクラスを参照します。
Section 7 provides more detailed discussion on how the FE model should be used by the ForCES protocol.
セクション7では、FEモデルをForce Protocolで使用する方法についての詳細な説明を説明します。
Even though not absolutely required, it is beneficial to use a formal data modeling language to represent the conceptual FE model described in this document. Use of a formal language can help to enforce consistency and logical compatibility among LFBs. A full specification will be written using such a data modeling language. The formal definition of the LFB classes may facilitate the eventual automation of some of the code generation process and the functional validation of arbitrary LFB topologies. These class definitions form the LFB library. Documents that describe LFB classes are therefore referred to as LFB library documents.
絶対に必要ではありませんが、正式なデータモデリング言語を使用して、このドキュメントに記載されている概念的なFEモデルを表すことが有益です。正式な言語の使用は、LFB間の一貫性と論理的互換性を強制するのに役立ちます。このようなデータモデリング言語を使用して、完全な仕様が記述されます。LFBクラスの正式な定義は、コード生成プロセスの一部の最終的な自動化と、任意のLFBトポロジの機能的検証を促進する可能性があります。これらのクラス定義は、LFBライブラリを形成します。したがって、LFBクラスを説明するドキュメントは、LFBライブラリドキュメントと呼ばれます。
Human readability was the most important factor considered when selecting the specification language, whereas encoding, decoding, and transmission performance were not a selection factor. The encoding method for over-the-wire transport is not dependent on the specification language chosen and is outside the scope of this document and up to the ForCES protocol to define.
人間の読みやすさは、仕様言語を選択する際に考慮される最も重要な要素でしたが、エンコード、デコード、および送信パフォーマンスは選択要因ではありませんでした。ワイヤ輸送のエンコーディング方法は、選択された仕様言語に依存せず、このドキュメントの範囲外であり、定義するための力プロトコルまであります。
XML is chosen as the specification language in this document, because XML has the advantage of being both human and machine readable with widely available tools support. This document uses an XML schema to define the structure of the LFB library documents, as defined in [RFC3470] and [Schema1] and [Schema2]. While these LFB class definitions are not sent in the ForCES protocol, these definitions comply with the recommendations in RFC 3470 [RFC3470] on the use of XML in IETF protocols.
XMLには、広く利用可能なツールサポートを使用して人間とマシンの両方が読みやすくなるという利点があるため、XMLはこのドキュメントの仕様言語として選択されます。このドキュメントでは、XMLスキーマを使用して、[RFC3470]および[schema1]および[schema2]で定義されているように、LFBライブラリドキュメントの構造を定義します。これらのLFBクラスの定義はForce Protocolで送信されていませんが、これらの定義は、IETFプロトコルでのXMLの使用に関するRFC 3470 [RFC3470]の推奨事項に準拠しています。
By using an XML schema to define the structure for the LFB library documents, we have a very clear set of syntactic restrictions to go with the desired semantic descriptions and restrictions covered in this document. As a corollary to that, if it is determined that a change in the syntax is needed, then a new schema will be required. This would be identified by a different URN to identify the namespace for such a new schema.
XMLスキーマを使用してLFBライブラリドキュメントの構造を定義することにより、このドキュメントで説明されている目的のセマンティックな説明と制限に合わせて、非常に明確な構文制限セットがあります。それに対する結果として、構文の変更が必要であると判断された場合、新しいスキーマが必要になります。これは、このような新しいスキーマの名前空間を識別するために、別のURNによって識別されます。
Section 3 provides a conceptual overview of the FE model, laying the foundation for the more detailed discussion and specifications in the sections that follow. Section 4 and Section 5 constitute the core of the FE model, detailing the two major aspects of the FE model: a general LFB model and a definition of the FE Object LFB, with its components, including FE capabilities and LFB topology information. Section 6 directly addresses the model requirements imposed by the ForCES requirements defined in RFC 3654 [RFC3654], while Section 7 explains how the FE model should be used in the ForCES protocol.
セクション3では、FEモデルの概念的概要を説明し、以下のセクションでより詳細な議論と仕様の基礎を築きます。セクション4とセクション5は、FEモデルのコアを構成し、FEモデルの2つの主要な側面を詳述しています。一般的なLFBモデルとFEオブジェクトLFBの定義は、FE機能とLFBトポロジ情報を含むコンポーネントを備えています。セクション6では、RFC 3654 [RFC3654]で定義されている力要件によって課されるモデル要件に直接対処し、セクション7では、FEモデルを力プロトコルで使用する方法について説明します。
The use of compliance terminology (MUST, SHOULD, MAY, MUST NOT) is used in accordance with RFC 2119 [RFC2119]. Such terminology is used in describing the required behavior of ForCES forwarding elements or control elements in supporting or manipulating information described in this model.
コンプライアンス用語の使用（必須、そうでなければ、そうでないかもしれない）は、RFC 2119 [RFC2119]に従って使用されます。このような用語は、このモデルで説明されている情報をサポートまたは操作する際に、要素または制御要素を転送する力の必要な動作を説明する際に使用されます。
Terminology associated with the ForCES requirements is defined in RFC 3654 [RFC3654] and is not copied here. The following list of terminology relevant to the FE model is defined in this section.
力の要件に関連付けられた用語は、RFC 3654 [RFC3654]で定義されており、ここではコピーされていません。このセクションでは、FEモデルに関連する次の用語のリストを定義しています。
FE Model: The FE model is designed to model the logical processing functions of an FE. The FE model proposed in this document includes three components; the LFB modeling of individual Logical Functional Block (LFB model), the logical interconnection between LFBs (LFB topology), and the FE-level attributes, including FE capabilities. The FE model provides the basis to define the information elements exchanged between the CE and the FE in the ForCES protocol [RFC5810].
FEモデル：FEモデルは、FEの論理処理関数をモデル化するように設計されています。このドキュメントで提案されているFEモデルには、3つのコンポーネントが含まれています。個々の論理機能ブロック（LFBモデル）のLFBモデリング、LFB（LFBトポロジ）間の論理的相互接続、およびFe機能を含むFeレベル属性。FEモデルは、Forceプロトコル[RFC5810]でCEとFEの間で交換される情報要素を定義する基礎を提供します。
Data Path: A conceptual path taken by packets within the forwarding plane inside an FE. Note that more than one data path can exist within an FE.
データパス：FE内の転送面内のパケットによって採用された概念パス。FE内には複数のデータパスが存在する可能性があることに注意してください。
LFB (Logical Functional Block) Class (or type): A template that represents a fine-grained, logically separable aspect of FE processing. Most LFBs relate to packet processing in the data path. LFB classes are the basic building blocks of the FE model.
LFB（論理関数ブロック）クラス（またはタイプ）：FE処理の細粒で論理的に分離可能な側面を表すテンプレート。ほとんどのLFBは、データパスでのパケット処理に関連しています。LFBクラスは、FEモデルの基本的な構成要素です。
LFB Instance: As a packet flows through an FE along a data path, it flows through one or multiple LFB instances, where each LFB is an instance of a specific LFB class. Multiple instances of the same LFB class can be present in an FE's data path. Note that we often refer to LFBs without distinguishing between an LFB class and LFB instance when we believe the implied reference is obvious for the given context.
LFBインスタンス：パケットがデータパスに沿ってFEを流れると、1つまたは複数のLFBインスタンスを流れます。各LFBは特定のLFBクラスのインスタンスです。同じLFBクラスの複数のインスタンスは、FEのデータパスに存在する可能性があります。LFBクラスとLFBインスタンスを区別することなくLFBを参照することがよくあることに注意してください。
LFB Model: The LFB model describes the content and structures in an LFB, plus the associated data definition. XML is used to provide a formal definition of the necessary structures for the modeling. Four types of information are defined in the LFB model. The core part of the LFB model is the LFB class definitions; the other three types of information define constructs associated with and used by the class definition. These are reusable data types, supported frame (packet) formats, and metadata.
LFBモデル：LFBモデルは、LFBのコンテンツと構造と、関連するデータ定義を記述します。XMLは、モデリングに必要な構造の正式な定義を提供するために使用されます。LFBモデルでは、4種類の情報が定義されています。LFBモデルのコア部分は、LFBクラス定義です。他の3つのタイプの情報は、クラス定義に関連付けられ、使用される構造を定義します。これらは、再利用可能なデータ型、サポートされているフレーム（パケット）形式、およびメタデータです。
Element: Element is generally used in this document in accordance with the XML usage of the term. It refers to an XML tagged part of an XML document. For a precise definition, please see the full set of XML specifications from the W3C. This term is included in this list for completeness because the ForCES formal model uses XML.
要素：要素は通常、このドキュメントでは、用語のXML使用に従って使用されます。XMLドキュメントのXMLタグ付けされた部分を指します。正確な定義については、W3CのXML仕様の完全なセットを参照してください。Force ModelがXMLを使用するため、この用語は完全性のためにこのリストに含まれています。
Attribute: Attribute is used in the ForCES formal modeling in accordance with standard XML usage of the term, i.e., to provide attribute information included in an XML tag.
属性：属性は、用語の標準XML使用法、つまりXMLタグに含まれる属性情報を提供するために、フォーマルモデリングで使用されます。
LFB Metadata: Metadata 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 metadata is identified, produced, and consumed by the LFBs, but not how the per-packet state is implemented within actual hardware. Metadata is sent between the FE and the CE on redirect packets.
LFBメタデータ：メタデータは、パケットごとの状態をあるLFBから別のLFBに通信するために使用されますが、ネットワーク全体で送信されません。FEモデルは、そのようなメタデータがLFBによってどのように識別、生産、および消費されるかを定義しますが、実際のハードウェア内でパケットごとの状態がどのように実装されるかは定義されていません。メタデータは、リダイレクトパケットでFEとCEの間に送信されます。
ForCES Component: A ForCES Component is a well-defined, uniquely identifiable and addressable ForCES model building block. A component has a 32-bit ID, name, type, and an optional synopsis description. These are often referred to simply as components.
力コンポーネント：力コンポーネントは、明確に定義され、一意に識別可能で、アドレス指定可能な力モデルの構成要素です。コンポーネントには、32ビットID、名前、タイプ、およびオプションの概要説明があります。これらは、多くの場合、単にコンポーネントと呼ばれます。
LFB Component: An LFB component is a ForCES component that defines the Operational parameters of the LFBs that must be visible to the CEs.
LFBコンポーネント：LFBコンポーネントは、CESに見える必要があるLFBの運用パラメーターを定義する力コンポーネントです。
Structure Component: A ForCES component that is part of a complex data structure to be used in LFB data definitions. The individual parts that make up a structured set of data are referred to as structure components. These can themselves be of any valid data type, including tables and structures.
構造コンポーネント：LFBデータ定義で使用される複雑なデータ構造の一部である力コンポーネント。構造化されたデータセットを構成する個々の部品は、構造コンポーネントと呼ばれます。これらは、テーブルや構造を含む有効なデータ型である可能性があります。
Property: ForCES components have properties associated with them, such as readability. Other examples include lengths for variable-sized components. These properties are accessed by the CE for reading (or, where appropriate, writing.) Details on the ForCES properties are found in Section 4.8.
プロパティ：力コンポーネントには、読みやすさなどのプロパティが関連付けられています。その他の例には、可変サイズのコンポーネントの長さが含まれます。これらのプロパティは、読み取り（または必要に応じて、書き込み）のためにCEによってアクセスされます。力のプロパティに関する詳細は、セクション4.8にあります。
LFB Topology: LFB topology is a representation of the logical interconnection and the placement of LFB instances along the data path within one FE. Sometimes this representation is called intra-FE topology, to be distinguished from inter-FE topology. LFB topology is outside of the LFB model, but is part of the FE model.
LFBトポロジ：LFBトポロジーは、論理的相互接続と1つのFe内のデータパスに沿ったLFBインスタンスの配置の表現です。時々、この表現は、FE間トポロジーと区別されるため、FE内トポロジーと呼ばれます。LFBトポロジーはLFBモデルの外側にありますが、FEモデルの一部です。
FE Topology: FE topology is a representation of how multiple FEs within a single network element (NE) are interconnected. Sometimes this is called inter-FE topology, to be distinguished from intra-FE topology (i.e., LFB topology). An individual FE might not have the global knowledge of the full FE topology, but the local view of its connectivity with other FEs is considered to be part of the FE model. The FE topology is discovered by the ForCES base protocol or by some other means.
FEトポロジ：FEトポロジは、単一のネットワーク要素（NE）内の複数のFESが相互接続されていることを表しています。これは、FE内トポロジーと呼ばれる場合があり、FE内トポロジ（つまり、LFBトポロジ）と区別されます。個々のFEは、完全なFEトポロジーの世界的な知識を持っていないかもしれませんが、他のFEとの接続性のローカルな見解は、FEモデルの一部であると考えられています。FEトポロジーは、Forces Base Protocolまたは他の手段によって発見されます。
Inter-FE Topology: See FE Topology.
Inter-FEトポロジ：FEトポロジーを参照してください。
Intra-FE Topology: See LFB Topology.
Intra-FEトポロジ：LFBトポロジを参照してください。
LFB Class Library: The LFB class library is a set of LFB classes that has been identified as the most common functions found in most FEs and hence should be defined first by the ForCES Working Group.
LFBクラスライブラリ：LFBクラスライブラリは、ほとんどのFESで見られる最も一般的な機能として特定されたLFBクラスのセットであるため、最初に作業作業グループによって定義される必要があります。
Some of the important ForCES concepts used throughout this document are introduced in this section. These include the capability and state abstraction, the FE and LFB model construction, and the unique addressing of the different model structures. Details of these aspects are described in Section 4 and Section 5. The intent of this section is to discuss these concepts at the high level and lay the foundation for the detailed description in the following sections.
このドキュメント全体で使用される重要な力の概念のいくつかをこのセクションで紹介します。これらには、機能と状態の抽象化、FEおよびLFBモデルの構造、異なるモデル構造の一意のアドレス指定が含まれます。これらの側面の詳細については、セクション4およびセクション5で説明します。このセクションの意図は、これらの概念を高レベルで説明し、以下のセクションに詳細な説明の基礎を築くことです。
The ForCES FE model includes both a capability and a state abstraction.
Force FEモデルには、能力と状態抽象化の両方が含まれています。
o The FE/LFB capability model describes the capabilities and capacities of an FE/LFB by specifying the variation in functions supported and any limitations. Capacity describes the limits of specific components (an example would be a table size limit).
o Fe/LFB機能モデルは、サポートされている関数の変動と制限を指定することにより、Fe/LFBの機能と容量を記述します。容量は、特定のコンポーネントの制限を記述します（例はテーブルサイズの制限です）。
o The state model describes the current state of the FE/LFB, that is, the instantaneous values or operational behavior of the FE/ LFB.
o 状態モデルは、Fe/ LFBの現在の状態、つまりFe/ LFBの瞬間的な値または運用挙動を説明しています。
Section 3.1 explains the difference between a capability model and a state model, and describes how the two can be combined in the FE model.
セクション3.1では、機能モデルと状態モデルの違いについて説明し、FEモデルで2つを組み合わせる方法について説明します。
The ForCES model construction laid out in this document allows an FE to provide information about its structure for operation. This can be thought of as FE-level information and information about the individual instances of LFBs provided by the FE.
このドキュメントにレイアウトされた力モデルの構造により、FEは動作の構造に関する情報を提供できます。これは、FEが提供するLFBの個々のインスタンスに関するFEレベルの情報と情報と考えることができます。
o The ForCES model includes the constructions for defining the class of Logical Functional Blocks (LFBs) that an FE may support. These classes are defined in this and other documents. The definition of such a class provides the information content for monitoring and controlling instances of the LFB class for ForCES purposes. Each LFB model class formally defines the operational LFB components, LFB capabilities, and LFB events. Essentially, Section 3.2 introduces the concept of LFBs as the basic functional building blocks in the ForCES model.
o Forceモデルには、FEがサポートする可能性のある論理機能ブロック（LFB）のクラスを定義するための構造が含まれています。これらのクラスは、このドキュメントおよびその他のドキュメントで定義されています。このようなクラスの定義は、力のためにLFBクラスのインスタンスを監視および制御するための情報コンテンツを提供します。各LFBモデルクラスは、運用上のLFBコンポーネント、LFB機能、およびLFBイベントを正式に定義します。基本的に、セクション3.2では、LFBの概念を力モデルの基本的な機能構成要素として紹介します。
o The FE model also provides the construction necessary to monitor and control the FE as a whole for ForCES purposes. For consistency of operation and simplicity, this information is represented as an LFB, the FE Object LFB class and a singular LFB instance of that class, defined using the LFB model. The FE Object class defines the components to provide information at the FE level, particularly the capabilities of the FE at a coarse level, i.e., not all possible capabilities or all details about the capabilities of the FE. Part of the FE-level information is the LFB topology, which expresses the logical inter-connection between the LFB instances along the data path(s) within the FE. Section 3.3 discusses the LFB topology. The FE Object also includes information about what LFB classes the FE can support.
o FEモデルは、力の目的でFE全体を監視および制御するために必要な構造も提供します。動作とシンプルさの一貫性のために、この情報は、LFBモデルのLFB、FEオブジェクトLFBクラス、およびLFBモデルを使用して定義された特異なLFBインスタンスとして表されます。FEオブジェクトクラスは、FEレベルで情報を提供するコンポーネントを定義します。特に、粗いレベルでのFEの機能、つまりすべての可能な機能やFEの機能に関するすべての詳細はありません。FEレベル情報の一部はLFBトポロジーです。これは、FE内のデータパスに沿ったLFBインスタンス間の論理的な相互接続を表します。セクション3.3では、LFBトポロジについて説明します。FEオブジェクトには、FEがサポートできるLFBクラスに関する情報も含まれています。
The ForCES model allows for unique identification of the different constructs it defines. This includes identification of the LFB classes, and of LFB instances within those classes, as well as identification of components within those instances.
力モデルにより、定義するさまざまな構成要素のユニークな識別が可能になります。これには、LFBクラス、およびそれらのクラス内のLFBインスタンスの識別、およびそれらのインスタンス内のコンポーネントの識別が含まれます。
The ForCES protocol [RFC5810] encapsulates target address(es) to eventually get to a fine-grained entity being referenced by the CE. The addressing hierarchy is broken into the following:
Force Protocol [RFC5810]は、ターゲットアドレスをカプセル化して、最終的にCEによって参照される細かいエンティティに到達します。アドレス指定階層は以下に分かれています。
o An FE is uniquely identified by a 32-bit FEID.
o FEは、32ビットのFeidによって独自に識別されます。
o Each class of LFB is uniquely identified by a 32-bit LFB ClassID. The LFB ClassIDs are global within the network element and may be issued by IANA.
o LFBの各クラスは、32ビットLFB ClassIDによって一意に識別されます。LFB ClassIDは、ネットワーク要素内でグローバルであり、IANAによって発行される場合があります。
o Within an FE, there can be multiple instances of each LFB class. Each LFB class instance is identified by a 32-bit identifier that is unique within a particular LFB class on that FE.
o FE内では、各LFBクラスの複数のインスタンスがあります。各LFBクラスインスタンスは、そのFEの特定のLFBクラス内で一意の32ビット識別子によって識別されます。
o All the components within an LFB instance are further defined using 32-bit identifiers.
o LFBインスタンス内のすべてのコンポーネントは、32ビット識別子を使用してさらに定義されています。
Refer to Section 3.3 for more details on addressing.
アドレス指定の詳細については、セクション3.3を参照してください。
Capability and state modeling applies to both the FE and LFB abstraction.
機能と状態モデリングは、FEとLFBの両方の抽象化に適用されます。
Figure 1 shows the concepts of FE state, capabilities, and configuration in the context of CE-FE communication via the ForCES protocol.
図1は、Force Protocolを介したCE-FE通信のコンテキストでのFe状態、機能、および構成の概念を示しています。
+-------+ +-------+
| | FE capabilities: what it can/cannot do. | |
| |<-----------------------------------------| |
| | | |
| CE | FE state: what it is now. | FE |
| |<-----------------------------------------| |
| | | |
| | FE configuration: what it should be. | |
| |----------------------------------------->| |
+-------+ +-------+
Figure 1: Illustration of FE capabilities, state, and configuration exchange in the context of CE-FE communication via ForCES.
図1：力を介したCE-FE通信のコンテキストでのFE機能、状態、および構成交換の図。
Conceptually, the FE capability model tells the CE which states are allowed on an FE, with capacity information indicating certain quantitative limits or constraints. Thus, the CE has general knowledge about configurations that are applicable to a particular FE.
概念的には、FE機能モデルは、特定の定量的制限または制約を示す容量情報を使用して、FEで許可される状態をCEに伝えます。したがって、CEには、特定のFeに適用可能な構成に関する一般的な知識があります。
The FE capability model may be used to describe an FE at a coarse level. For example, an FE might be defined as follows:
FE機能モデルは、粗いレベルでFEを記述するために使用できます。たとえば、FEは次のように定義される場合があります。
o the FE can handle IPv4 and IPv6 forwarding;
o FEはIPv4およびIPv6の転送を処理できます。
o the FE can perform classification based on the following fields: source IP address, destination IP address, source port number, destination port number, etc.;
o FEは、次のフィールドに基づいて分類を実行できます。ソースIPアドレス、宛先IPアドレス、ソースポート番号、宛先ポート番号など。
o the FE can perform metering;
o FEは計量を実行できます。
o the FE can handle up to N queues (capacity); and
o FEは最大nキュー（容量）を処理できます。と
o the FE can add and remove encapsulating headers of types including IPsec, GRE, L2TP.
o FEは、IPSEC、GRE、L2TPを含むタイプのカプセル化ヘッダーを追加および削除できます。
While one could try to build an object model to fully represent the FE capabilities, other efforts found this approach to be a significant undertaking. The main difficulty arises in describing detailed limits, such as the maximum number of classifiers, queues, buffer pools, and meters that the FE can provide. We believe that a good balance between simplicity and flexibility can be achieved for the FE model by combining coarse-level-capability reporting with an error reporting mechanism. That is, if the CE attempts to instruct the FE to set up some specific behavior it cannot support, the FE will return an error indicating the problem. Examples of similar approaches include Diffserv PIB RFC 3317 [RFC3317] and framework PIB RFC 3318 [RFC3318].
FE機能を完全に表現するためにオブジェクトモデルを構築しようとすることはできますが、他の努力はこのアプローチが重要な事業であると判断しました。主な難しさは、FEが提供できる分類器、キュー、バッファープール、メーターの最大数など、詳細な制限を記述する際に生じます。粗いレベルの能力レポートとエラー報告メカニズムを組み合わせることにより、FEモデルでは、シンプルさと柔軟性のバランスが良いと考えています。つまり、CEがサポートできない特定の動作を設定するためにFEに指示しようとすると、Feは問題を示すエラーを返します。同様のアプローチの例には、Diffserv Pib RFC 3317 [RFC3317]およびFramework PIB RFC 3318 [RFC3318]が含まれます。
The FE state model presents the snapshot view of the FE to the CE. For example, using an FE state model, an FE might be described to its corresponding CE as the following:
Fe状態モデルは、CEへのFEのスナップショットビューを示しています。たとえば、Fe状態モデルを使用して、FEは対応するCEに次のように説明される場合があります。
o on a given port, the packets are classified using a given classification filter;
o 特定のポートでは、パケットは特定の分類フィルターを使用して分類されます。
o the given classifier results in packets being metered in a certain way and then marked in a certain way;
o 指定された分類器の結果、パケットが特定の方法でメーターになり、特定の方法でマークされます。
o the packets coming from specific markers are delivered into a shared queue for handling, while other packets are delivered to a different queue; and
o 特定のマーカーから来るパケットは、取り扱いのために共有キューに配信され、他のパケットは別のキューに配信されます。と
o a specific scheduler with specific behavior and parameters will service these collected queues.
o 特定の動作とパラメーターを備えた特定のスケジューラは、これらの収集されたキューにサービスを提供します。
Both LFB capability and state information are defined formally using the LFB modeling XML schema.
LFB機能と状態情報の両方が、LFBモデリングXMLスキーマを使用して正式に定義されます。
Capability information at the LFB level is an integral part of the LFB model and provides for powerful semantics. For example, when certain features of an LFB class are optional, the CE needs to be able to determine whether those optional features are supported by a given LFB instance. The schema for the definition of LFB classes provides a means for identifying such components.
LFBレベルでの機能情報は、LFBモデルの不可欠な部分であり、強力なセマンティクスを提供します。たとえば、LFBクラスの特定の機能がオプションである場合、CEは、これらのオプションの機能が特定のLFBインスタンスによってサポートされているかどうかを判断できる必要があります。LFBクラスの定義のスキーマは、そのようなコンポーネントを識別する手段を提供します。
State information is defined formally using LFB component constructs.
状態情報は、LFBコンポーネントコンストラクトを使用して正式に定義されます。
Capability information at the FE level describes the LFB classes that the FE can instantiate, the number of instances of each that can be created, the topological (linkage) limitations between these LFB instances, etc. Section 5 defines the FE-level components including capability information. Since all information is represented as LFBs, this is provided by a single instance of the FE Object LFB class. By using a single instance with a known LFB class and a known instance identification, the ForCES protocol can allow a CE to access this information whenever it needs to, including while the CE is establishing the control of the FE.
FEレベルの機能情報は、FEがインスタンス化できるLFBクラス、作成できる各インスタンスの数、これらのLFBインスタンスの間のトポロジー（リンケージ）の制限などを説明しています。セクション5では、機能を含むFEレベルコンポーネントを定義します。情報。すべての情報はLFBとして表されるため、これはFEオブジェクトLFBクラスの単一インスタンスによって提供されます。既知のLFBクラスと既知のインスタンス識別を備えた単一のインスタンスを使用することにより、Forceプロトコルは、CEがFEの制御を確立している間、CEが必要なときにいつでもこの情報にアクセスできるようにすることができます。
Once the FE capability is described to the CE, the FE state information can be represented at two levels. The first level is the logically separable and distinct packet processing functions, called LFBs. The second level of information describes how these individual LFBs are ordered and placed along the data path to deliver a complete forwarding plane service. The interconnection and ordering of the LFBs is called LFB topology. Section 3.2 discusses high-level concepts around LFBs, whereas Section 3.3 discusses LFB topology issues. This topology information is represented as components of the FE Object LFB instance, to allow the CE to fetch and manipulate this.
FE機能がCEに記載されると、FE状態情報は2つのレベルで表現できます。最初のレベルは、LFBSと呼ばれる論理的に分離可能で異なるパケット処理機能です。2番目のレベルの情報は、これらの個々のLFBがデータパスに沿って配置され、完全な転送面サービスを提供する方法を説明しています。LFBの相互接続と順序はLFBトポロジーと呼ばれます。セクション3.2では、LFBに関する高レベルの概念について説明しますが、セクション3.3ではLFBトポロジの問題について説明します。このトポロジ情報は、CEがこれをフェッチおよび操作できるようにするために、FEオブジェクトLFBインスタンスのコンポーネントとして表されます。
Each LFB performs a well-defined action or computation on the packets passing through it. Upon completion of its prescribed function, either the packets are modified in certain ways (e.g., decapsulator, marker), or some results are generated and stored, often in the form of metadata (e.g., classifier). Each LFB typically performs a single action. Classifiers, shapers, and meters are all examples of such LFBs. Modeling LFBs at such a fine granularity allows us to use a small number of LFBs to express the higher-order FE functions (such as an IPv4 forwarder) precisely, which in turn can describe more complex networking functions and vendor implementations of software and hardware. These fine-grained LFBs will be defined in detail in one or more documents to be published separately, using the material in this model.
各LFBは、それを通過するパケットで明確に定義されたアクションまたは計算を実行します。規定された関数が完了すると、パケットが特定の方法で変更され（例：脱カプセレータ、マーカー）、またはいくつかの結果が生成および保存され、多くの場合メタデータ（例：分類器）の形で生成され保存されます。通常、各LFBは単一のアクションを実行します。分類器、シェイパー、メーターはすべて、そのようなLFBの例です。このような細かい粒度でLFBをモデリングすると、少数のLFBを使用して高次のFE関数（IPv4転送業者など）を正確に表現することができ、これにより、より複雑なネットワーキング関数とソフトウェアとハードウェアのベンダー実装を記述できます。これらのきめの細かいLFBは、このモデルの資料を使用して、個別に公開される1つ以上のドキュメントで詳細に定義されます。
It is also the case that LFBs may exist in order to provide a set of components for control of FE operation by the CE (i.e., a locus of control), without tying that control to specific packets or specific parts of the data path. An example of such an LFB is the FE Object, which provides the CE with information about the FE as a whole, and allows the FE to control some aspects of the FE, such as the data path itself. Such LFBs will not have the packet-oriented properties described in this section.
また、特定のパケットまたはデータパスの特定の部分にその制御を結び付けることなく、CE（すなわち、制御の軌跡）によるFE操作の制御のためのコンポーネントのセットを提供するためにLFBSが存在する場合があります。このようなLFBの例はFEオブジェクトであり、CEにFE全体に関する情報を提供し、FEがデータパス自体などのFEのいくつかの側面を制御できるようにします。このようなLFBには、このセクションで説明されているパケット指向のプロパティはありません。
In general, multiple LFBs are contained in one FE, as shown in Figure 2, and all the LFBs share the same ForCES protocol (Fp) termination point that implements the ForCES protocol logic and maintains the communication channel to and from the CE.
一般に、図2に示すように、複数のLFBが1つのFeに含まれており、すべてのLFBは、力プロトコルロジックを実装し、CEとの通信チャネルを維持する同じ力プロトコル（FP）終端ポイントを共有します。
+-----------+
| CE |
+-----------+
^
| Fp reference point
|
+--------------------------|-----------------------------------+
| FE | |
| v |
| +----------------------------------------------------------+ |
| | ForCES protocol | |
| | termination point | |
| +----------------------------------------------------------+ |
| ^ ^ |
| : : Internal control |
| : : |
| +---:----------+ +---:----------| |
| | :LFB1 | | : LFB2 | |
| =====>| v |============>| v |======>...|
| Inputs| +----------+ |Outputs | +----------+ | |
| (P,M) | |Components| |(P',M') | |Components| |(P",M") |
| | +----------+ | | +----------+ | |
| +--------------+ +--------------+ |
| |
+--------------------------------------------------------------+
Figure 2: Generic LFB diagram.
図2：一般的なLFB図。
An LFB, as shown in Figure 2, may have inputs, outputs, and components that can be queried and manipulated by the CE via an Fp reference point (defined in RFC 3746 [RFC3746]) and the ForCES protocol termination point. The horizontal axis is in the forwarding plane for connecting the inputs and outputs of LFBs within the same FE. P (with marks to indicate modification) indicates a data packet, while M (with marks to indicate modification) indicates the metadata associated with a packet. The vertical axis between the CE and the FE denotes the Fp reference point where bidirectional communication between the CE and FE occurs: the CE-to-FE communication is for configuration, control, and packet injection, while the FE-to-CE communication is used for packet redirection to the control plane, reporting of monitoring and accounting information, reporting of errors, etc. Note that the interaction between the CE and the LFB is only abstract and indirect. The result of such an interaction is for the CE to manipulate the components of the LFB instances.
図2に示すように、LFBには、FP参照ポイント（RFC 3746 [RFC3746]で定義）および力プロトコル終端ポイントを介してCEによって照会および操作できる入力、出力、およびコンポーネントがあります。水平軸は、同じFe内のLFBの入力と出力を接続するための転送面にあります。p（変更を示すマーク付き）はデータパケットを示しますが、m（変更を示すマーク付き）はパケットに関連付けられたメタデータを示します。CEとFEの間の垂直軸は、CEとFEの間の双方向通信が発生するFP基準点を示します。CE対FE通信は構成、制御、およびパケットインジェクションのためですが、FE-CE通信はコントロールプレーンへのパケットリダイレクト、監視および会計情報の報告、エラーの報告などに使用されます。CEとLFBの相互作用は抽象的で間接的であることに注意してください。このような相互作用の結果は、CEがLFBインスタンスのコンポーネントを操作するためです。
An LFB can have one or more inputs. Each input takes a pair of a packet and its associated metadata. Depending upon the LFB input port definition, the packet or the metadata may be allowed to be empty (or equivalently to not be provided). When input arrives at an LFB, either the packet or its associated metadata must be non-empty or there is effectively no input. (LFB operation generally may be triggered by input arrival, by timers, or by other system state. It is only in the case where the goal is to have input drive operation that the input must be non-empty.)
LFBには1つ以上の入力があります。各入力は、パケットとそれに関連するメタデータのペアを取ります。LFB入力ポート定義に応じて、パケットまたはメタデータを空にすることができます（または同等に提供されないように）。入力がLFBに到着すると、パケットまたはそれに関連するメタデータのいずれかが空ではない必要があります。または、事実上入力がありません。（一般に、LFBの操作は、入力到着、タイマー、または他のシステム状態によってトリガーされる場合があります。それは、入力操作が入力されていないことを目標にする場合にのみです。）
The LFB processes the input, and produces one or more outputs, each of which is a pair of a packet and its associated metadata. Again, depending upon the LFB output port definition, either the packet or the metadata may be allowed to be empty (or equivalently to be absent). Metadata attached to packets on output may be metadata that was received, or may be information about the packet processing that may be used by later LFBs in the FEs packet processing.
LFBは入力を処理し、1つ以上の出力を生成します。各出力は、パケットとそれに関連するメタデータのペアです。繰り返しますが、LFB出力ポートの定義に応じて、パケットまたはメタデータのいずれかが空になる（または同等に存在しない）ことができます。出力でパケットに接続されたメタデータは、受信したメタデータである場合があるか、FESパケット処理で後のLFBが使用できるパケット処理に関する情報である場合があります。
A namespace is used to associate a unique name and ID with each LFB class. The namespace MUST be extensible so that a new LFB class can be added later to accommodate future innovation in the forwarding plane.
名前空間は、一意の名前とIDを各LFBクラスに関連付けるために使用されます。ネームスペースは、転送面の将来のイノベーションに対応するために新しいLFBクラスを後で追加できるように拡張可能でなければなりません。
LFB operation is specified in the model to allow the CE to understand the behavior of the forwarding data path. For instance, the CE needs to understand at what point in the data path the IPv4 header TTL is decremented by the FE. That is, the CE needs to know if a control packet could be delivered to it either before or after this point in the data path. In addition, the CE needs to understand where and what type of header modifications (e.g., tunnel header append or strip) are performed by the FEs. Further, the CE works to verify that the various LFBs along a data path within an FE are compatible to link together. Connecting incompatible LFB instances will produce a non-working data path. So the model is designed to provide sufficient information for the CE to make this determination.
LFB操作は、CEが転送データパスの動作を理解できるようにモデルで指定されています。たとえば、CEは、IPv4ヘッダーTTLがFEによって減少するデータパスのどのポイントで理解する必要があります。つまり、CEは、データパスのこのポイントの前または後にコントロールパケットを配信できるかどうかを知る必要があります。さらに、CEは、FESによって実行されるヘッダーの変更（トンネルヘッダーの追加またはストリップなど）をどこで、どのタイプのヘッダーの変更（たとえば、どのタイプのヘッダー変更）を理解する必要があります。さらに、CEは、FE内のデータパスに沿ったさまざまなLFBがリンクできることを確認するために機能します。互換性のないLFBインスタンスを接続すると、非労働データパスが生成されます。したがって、このモデルは、この決定を行うためにCEに十分な情報を提供するように設計されています。
Selecting the right granularity for describing the functions of the LFBs is an important aspect of this model. There is value to vendors if the operation of LFB classes can be expressed in sufficient detail so that physical devices implementing different LFB functions can be integrated easily into an FE design. However, the model, and the associated library of LFBs, must not be so detailed and so specific as to significantly constrain implementations. Therefore, a semi-formal specification is needed; that is, a text description of the LFB operation (human readable), but sufficiently specific and unambiguous to allow conformance testing and efficient design, so that interoperability between different CEs and FEs can be achieved.
LFBSの機能を記述するための適切な粒度を選択することは、このモデルの重要な側面です。LFBクラスの動作を十分に詳細に表現できる場合、ベンダーに価値があり、さまざまなLFB関数を実装する物理デバイスをFE設計に簡単に統合できます。ただし、モデルと関連するLFBのライブラリは、実装を大幅に制約するほど詳細かつ具体的であってはなりません。したがって、半形式の仕様が必要です。つまり、LFB操作のテキストの説明（人間の読み取り可能）ですが、適切なテストと効率的な設計を可能にするために十分に特異的かつ明確ではないため、異なるCEとFES間の相互運用性を達成できます。
The LFB class model specifies the following, among other information:
LFBクラスモデルは、次の情報を指定します。
o number of inputs and outputs (and whether they are configurable)
o 入力と出力の数（およびそれらが構成可能かどうか）
o metadata read/consumed from inputs
o 入力から読み取り/消費されたメタデータ
o metadata produced at the outputs
o 出力で生成されたメタデータ
o packet types accepted at the inputs and emitted at the outputs
o 入力で受け入れられ、出力で放出されるパケットタイプ
o packet content modifications (including encapsulation or decapsulation)
o パケットコンテンツの変更（カプセル化または脱カプセル化を含む）
o packet routing criteria (when multiple outputs on an LFB are present)
o パケットルーティング基準（LFBの複数の出力が存在する場合）
o packet timing modifications
o パケットタイミングの変更
o packet flow ordering modifications
o パケットフロー順序付けの変更
o LFB capability information components
o LFB機能情報コンポーネント
o events that can be detected by the LFB, with notification to the CE
o CEに通知して、LFBが検出できるイベント
o LFB operational components
o LFB運用コンポーネント
Section 4 of this document provides a detailed discussion of the LFB model with a formal specification of LFB class schema. The rest of Section 3.2 only intends to provide a conceptual overview of some important issues in LFB modeling, without covering all the specific details.
このドキュメントのセクション4では、LFBクラススキーマの正式な仕様を使用したLFBモデルの詳細な説明を提供します。セクション3.2の残りの部分は、すべての特定の詳細をカバーすることなく、LFBモデリングにおけるいくつかの重要な問題の概念的概要を提供することのみを目的としています。
An LFB output is a conceptual port on an LFB that can send information to another LFB. The information sent on that port is a pair of a packet and associated metadata, one of which may be empty. (If both were empty, there would be no output.)
LFB出力は、LFBの概念ポートであり、別のLFBに情報を送信できます。そのポートに送信された情報は、パケットと関連するメタデータのペアであり、そのうちの1つは空になる可能性があります。（両方が空であれば、出力はありません。）
A single LFB output can be connected to only one LFB input. This is required to make the packet flow through the LFB topology unambiguous.
単一のLFB出力は、1つのLFB入力のみに接続できます。これは、LFBトポロジを介してパケットフローを明確にするために必要です。
Some LFBs will have a single output, as depicted in Figure 3.a.
図3に示すように、一部のLFBには単一の出力があります。
+---------------+ +-----------------+
| | | |
| | | OUT +-->
... OUT +--> ... |
| | | EXCEPTIONOUT +-->
| | | |
+---------------+ +-----------------+
a. One output b. Two distinct outputs
a. 1つの出力b。2つの異なる出力
+---------------+ +-----------------+
| | | EXCEPTIONOUT +-->
| OUT:1 +--> | |
... OUT:2 +--> ... OUT:1 +-->
| ... +... | OUT:2 +-->
| OUT:n +--> | ... +...
+---------------+ | OUT:n +-->
+-----------------+
c. One output group d. One output and one output group
c. 1つの出力グループd。1つの出力と1つの出力グループ
Figure 3: Examples of LFBs with various output combinations.
図3：さまざまな出力の組み合わせを伴うLFBの例。
To accommodate a non-trivial LFB topology, multiple LFB outputs are needed so that an LFB class can fork the data path. Two mechanisms are provided for forking: multiple singleton outputs and output groups, which can be combined in the same LFB class.
非自明のLFBトポロジに対応するには、LFBクラスがデータパスをフォークできるように、複数のLFB出力が必要です。フォーキングには2つのメカニズムが提供されています。複数のシングルトン出力と出力グループを使用して、同じLFBクラスで組み合わせることができます。
Multiple separate singleton outputs are defined in an LFB class to model a predetermined number of semantically different outputs. That is, the LFB class definition MUST include the number of outputs, implying the number of outputs is known when the LFB class is defined. Additional singleton outputs cannot be created at LFB instantiation time, nor can they be created on the fly after the LFB is instantiated.
複数の個別のシングルトン出力がLFBクラスで定義され、決定的な数の意味的に異なる出力の数をモデル化します。つまり、LFBクラスの定義には出力の数を含める必要があります。これは、LFBクラスが定義されているときに出力の数がわかっていることを意味します。追加のシングルトン出力は、LFBインスタンスタイムで作成することはできませんし、LFBがインスタンス化された後、その場で作成することもできません。
For example, an IPv4 LPM (Longest-Prefix-Matching) LFB may have one output (OUT) to send those packets for which the LPM look-up was successful, passing a META_ROUTEID as metadata; and have another output (EXCEPTIONOUT) for sending exception packets when the LPM look-up failed. This example is depicted in Figure 3.b. Packets emitted by these two outputs not only require different downstream treatment, but they are a result of two different conditions in the LFB and each output carries different metadata. This concept assumes that the number of distinct outputs is known when the LFB class is defined. For each singleton output, the LFB class definition defines the types of frames (packets) and metadata the output emits.
たとえば、IPv4 LPM（最長-Prefixマッチング）LFBには、LPMのルックアップが成功したパケットを送信するために1つの出力（OUT）があり、Meta_RouteIDをメタデータとして渡すことができます。LPMのルックアップが失敗したときに、例外パケットを送信するための別の出力（例外）があります。この例を図3.Bに示します。これらの2つの出力によって放出されるパケットは、異なる下流の治療を必要とするだけでなく、LFBの2つの異なる条件の結果であり、各出力は異なるメタデータを運びます。この概念は、LFBクラスが定義されているときに異なる出力の数がわかっていることを前提としています。シングルトン出力ごとに、LFBクラス定義は、出力が発するフレームの種類（パケット）とメタデータを定義します。
An output group, on the other hand, is used to model the case where a flow of similar packets with an identical set of permitted metadata needs to be split into multiple paths. In this case, the number of such paths is not known when the LFB class is defined because it is not an inherent property of the LFB class. An output group consists of a number of outputs, called the output instances of the group, where all output instances share the same frame (packet) and metadata emission definitions (see Figure 3.c). Each output instance can connect to a different downstream LFB, just as if they were separate singleton outputs, but the number of output instances can differ between LFB instances of the same LFB class. The class definition may include a lower and/or an upper limit on the number of outputs. In addition, for configurable FEs, the FE capability information may define further limits on the number of instances in specific output groups for certain LFBs. The actual number of output instances in a group is a component of the LFB instance, which is read-only for static topologies, and read-write for dynamic topologies. The output instances in a group are numbered sequentially, from 0 to N-1, and are addressable from within the LFB. To use Output Port groups, the LFB has to have a built-in mechanism to select one specific output instance for each packet. This mechanism is described in the textual definition of the class and is typically configurable via some attributes of the LFB.
一方、出力グループは、許容されるメタデータの同一のセットを使用した同様のパケットのフローを複数のパスに分割する必要がある場合をモデル化するために使用されます。この場合、LFBクラスの固有のプロパティではないため、LFBクラスが定義されている場合、そのようなパスの数は不明です。出力グループは、グループの出力インスタンスと呼ばれる多数の出力で構成されており、すべての出力インスタンスが同じフレーム（パケット）とメタデータの排出量定義を共有します（図3.Cを参照）。各出力インスタンスは、まるでそれらが別々のシングルトン出力であるかのように、異なる下流のLFBに接続できますが、同じLFBクラスのLFBインスタンス間で出力インスタンスの数は異なります。クラスの定義には、出力の数の下限および/または上限が含まれる場合があります。さらに、構成可能なFESの場合、FE機能情報は、特定のLFBの特定の出力グループのインスタンス数のさらなる制限を定義する場合があります。グループ内の実際の出力インスタンスの数は、LFBインスタンスのコンポーネントであり、静的トポロジでは読み取り専用であり、動的トポロジの読み取りワイトです。グループ内の出力インスタンスは、0からn-1まで連続して番号が付けられており、LFB内からアドレス指定可能です。出力ポートグループを使用するには、LFBには、各パケットに1つの特定の出力インスタンスを選択するための組み込みメカニズムが必要です。このメカニズムは、クラスのテキスト定義で説明されており、通常、LFBのいくつかの属性を介して構成可能です。
For example, consider a redirector LFB, whose sole purpose is to direct packets to one of N downstream paths based on one of the metadata associated with each arriving packet. Such an LFB is fairly versatile and can be used in many different places in a topology. For example, given LFBs that record the type of packet in a FRAMETYPE metadatum, or a packet rate class in a COLOR metadatum, one may uses these metadata for branching. A redirector can be used to divide the data path into an IPv4 and an IPv6 path based on a FRAMETYPE metadatum (N=2), or to fork into rate-specific paths after metering using the COLOR metadatum (red, yellow, green; N=3), etc.
たとえば、リダイレクターLFBを検討します。リダイレクターLFBは、到着する各パケットに関連付けられたメタデータの1つに基づいて、パケットを下流パスの1つに向けることです。このようなLFBはかなり用途が広く、トポロジのさまざまな場所で使用できます。たとえば、フレームタイプメタデータのパケットの種類を記録するLFB、またはカラーメタデータのパケットレートクラスを記録する場合、これらのメタデータを分岐に使用する場合があります。リダイレクターを使用して、データパスをFrameType Metadatum（n = 2）に基づいてIPv4とIPv6パスに分割するか、色メタデータ（赤、黄色、緑、n nを使用して計量した後、レート固有のパスに分割することができます。= 3）など
Using an output group in the above LFB class provides the desired flexibility to adapt each instance of this class to the required operation. The metadata to be used as a selector for the output instance is a property of the LFB. For each packet, the value of the specified metadata may be used as a direct index to the output instance. Alternatively, the LFB may have a configurable selector table that maps a metadatum value to output instance.
上記のLFBクラスで出力グループを使用すると、このクラスの各インスタンスを必要な操作に適応させるための柔軟性があります。出力インスタンスのセレクターとして使用されるメタデータは、LFBのプロパティです。各パケットについて、指定されたメタデータの値は、出力インスタンスへの直接インデックスとして使用できます。あるいは、LFBには、メタデータ値を出力インスタンスにマッピングする構成可能なセレクターテーブルがある場合があります。
Note that other LFBs may also use the output group concept to build in similar adaptive forking capability. For example, a classifier LFB with one input and N outputs can be defined easily by using the output group concept. Alternatively, a classifier LFB with one singleton output in combination with an explicit N-output re-director LFB models the same processing behavior. The decision of whether to use the output group model for a certain LFB class is left to the LFB class designers.
他のLFBは、出力グループの概念を使用して、同様の適応フォーキング機能を構築することもできます。たとえば、出力グループの概念を使用して、1つの入力とn出力を備えた分類LFBを簡単に定義できます。あるいは、明示的なn出力リダイレクターLFBを組み合わせた1つのシングルトン出力を備えた分類器LFBは、同じ処理挙動をモデル化します。特定のLFBクラスに出力グループモデルを使用するかどうかの決定は、LFBクラスデザイナーに任されています。
The model allows the output group to be combined with other singleton output(s) in the same class, as demonstrated in Figure 3.d. The LFB here has two types of outputs, OUT, for normal packet output, and EXCEPTIONOUT, for packets that triggered some exception. The normal OUT has multiple instances; thus, it is an output group.
このモデルにより、図3.Dに示すように、同じクラスの他のシングルトン出力と出力グループを組み合わせることができます。ここのLFBには、通常のパケット出力用の2種類の出力があり、例外がいくつかの例外をトリガーしたパケットの場合があります。通常の外出には複数のインスタンスがあります。したがって、それは出力グループです。
In summary, the LFB class may define one output, multiple singleton outputs, one or more output groups, or a combination thereof. Multiple singleton outputs should be used when the LFB must provide for forking the data path and at least one of the following conditions hold:
要約すると、LFBクラスは、1つの出力、複数のシングルトン出力、1つ以上の出力グループ、またはその組み合わせを定義できます。LFBがデータパスを分岐する必要があり、少なくとも次の条件の1つが保持される場合は、複数のSingleton出力を使用する必要があります。
o the number of downstream directions is inherent from the definition of the class and hence fixed
o 下流の方向の数はクラスの定義から固有のものであり、したがって修正
o the frame type and set of permitted metadata emitted on any of the outputs are different from what is emitted on the other outputs (i.e., they cannot share their frametype and permitted metadata definitions)
o 出力のいずれかで放出される許可されたメタデータのフレームタイプとセットは、他の出力で放出されるものとは異なります（つまり、フレーメタイプと許可されたメタデータの定義を共有できません）
An output group is appropriate when the LFB must provide for forking the data path and at least one of the following conditions hold:
LFBがデータパスを分岐する必要があり、少なくとも次の条件の1つが保持される場合、出力グループが適切です。
o the number of downstream directions is not known when the LFB class is defined
o LFBクラスが定義されている場合、下流の方向の数は不明です
o the frame type and set of metadata emitted on these outputs are sufficiently similar or, ideally, identical, such they can share the same output definition
o これらの出力で放出されるメタデータのフレームタイプとセットは、十分に類似しているか、理想的には同一であるため、同じ出力定義を共有できます
An LFB input is a conceptual port on an LFB on which the LFB can receive information from other LFBs. The information is typically a pair of a packet and its associated metadata. Either the packet or the metadata may for some LFBs and some situations be empty. They cannot both be empty, as then there is no input.
LFB入力は、LFBが他のLFBから情報を受信できるLFB上の概念ポートです。情報は通常、パケットとそれに関連するメタデータのペアです。一部のLFBのパケットまたはメタデータのいずれかが空になる可能性があります。入力がないため、両方とも空にすることはできません。
For LFB instances that receive packets from more than one other LFB instance (fan-in), there are three ways to model fan-in, all supported by the LFB model and can all be combined in the same LFB:
他の複数のLFBインスタンス（ファンイン）からパケットを受信するLFBインスタンスの場合、ファンインをモデル化する3つの方法があり、すべてLFBモデルでサポートされ、すべて同じLFBで結合できます。
o Implicit multiplexing via a single input o Explicit multiplexing via multiple singleton inputs
o 単一の入力を介した暗黙的多重化o複数のシングルトン入力を介した明示的な多重化
o Explicit multiplexing via a group of inputs (input group)
o 入力グループを介した明示的な多重化（入力グループ）
The simplest form of multiplexing uses a singleton input (Figure 4.a). Most LFBs will have only one singleton input. Multiplexing into a single input is possible because the model allows more than one LFB output to connect to the same LFB input. This property applies to any LFB input without any special provisions in the LFB class. Multiplexing into a single input is applicable when the packets from the upstream LFBs are similar in frametype and accompanying metadata, and require similar processing. Note that this model does not address how potential contention is handled when multiple packets arrive simultaneously. If contention handling needs to be explicitly modeled, one of the other two modeling solutions must be used.
マルチプレックスの最も単純な形式では、シングルトン入力が使用されます（図4.a）。ほとんどのLFBには、シングルトン入力が1つしかありません。モデルにより複数のLFB出力が同じLFB入力に接続できるようになるため、単一の入力への多重化が可能です。このプロパティは、LFBクラスに特別な規定なしにLFB入力に適用されます。上流のLFBからのパケットがフレームタイプとそれに付随するメタデータで類似しており、同様の処理が必要な場合、単一の入力への多重化が適用されます。このモデルは、複数のパケットが同時に到着したときに潜在的な競合がどのように処理されるかに対処していないことに注意してください。競合処理を明示的にモデル化する必要がある場合、他の2つのモデリングソリューションの1つを使用する必要があります。
The second method to model fan-in uses individually defined singleton inputs (Figure 4.b). This model is meant for situations where the LFB needs to handle distinct types of packet streams, requiring input-specific handling inside the LFB, and where the number of such distinct cases is known when the LFB class is defined. For example, an LFB that can perform both Layer 2 decapsulation (to Layer 3) and Layer 3 encapsulation (to Layer 2) may have two inputs, one for receiving Layer 2 frames for decapsulation, and one for receiving Layer 3 frames for encapsulation. This LFB type expects different frames (L2 versus L3) at its inputs, each with different sets of metadata, and would thus apply different processing on frames arriving at these inputs. This model is capable of explicitly addressing packet contention by defining how the LFB class handles the contending packets.
ファンインをモデル化する2番目の方法では、個別に定義されたシングルトン入力を使用します（図4.b）。このモデルは、LFBが異なるタイプのパケットストリームを処理する必要がある状況を対象としており、LFB内で入力固有の処理が必要であり、LFBクラスが定義されているときにそのような異なるケースの数がわかっています。たとえば、レイヤー2脱カプセル化（レイヤー3）とレイヤー3のカプセル化（レイヤー2へ）の両方を実行できるLFBには、2つの入力があります。このLFBタイプは、入力で異なるフレーム（L2対L3）を予想しており、それぞれが異なるメタデータセットを持つため、これらの入力に到達するフレームに異なる処理を適用します。このモデルは、LFBクラスが競合するパケットをどのように処理するかを定義することにより、パケットの競合に明示的に対処できます。
+--------------+ +------------------------+
| LFB X +---+ | |
+--------------+ | | |
| | |
+--------------+ v | |
| LFB Y +---+-->|input Meter LFB |
+--------------+ ^ | |
| | |
+--------------+ | | |
| LFB Z |---+ | |
+--------------+ +------------------------+
(a) An LFB connects with multiple upstream LFBs via a single input.
(a) LFBは、単一の入力を介して複数の上流LFBと接続します。
+--------------+ +------------------------+
| LFB X +---+ | |
+--------------+ +-->|layer2 |
+--------------+ | |
| LFB Y +------>|layer3 LFB |
+--------------+ +------------------------+
(b) An LFB connects with multiple upstream LFBs via two separate singleton inputs.
(b) LFBは、2つの独立したSingleton入力を介して複数の上流LFBと接続します。
+--------------+ +------------------------+
| Queue LFB #1 +---+ | |
+--------------+ | | |
| | |
+--------------+ +-->|in:0 \ |
| Queue LFB #2 +------>|in:1 | input group |
+--------------+ |... | |
+-->|in:N-1 / |
... | | |
+--------------+ | | |
| Queue LFB #N |---+ | Scheduler LFB |
+--------------+ +------------------------+
(c) A Scheduler LFB uses an input group to differentiate which queue LFB packets are coming from.
(c) スケジューラLFBは、入力グループを使用して、どのキューLFBパケットが由来するかを区別します。
Figure 4: Examples of LFBs with various input combinations.
図4：さまざまな入力の組み合わせによるLFBの例。
The third method to model fan-in uses the concept of an input group. The concept is similar to the output group introduced in the previous section and is depicted in Figure 4.c. An input group consists of a number of input instances, all sharing the properties (same frame and metadata expectations). The input instances are numbered from 0 to N-1. From the outside, these inputs appear as normal inputs, i.e., any compatible upstream LFB can connect its output to one of these inputs. When a packet is presented to the LFB at a particular input instance, the index of the input where the packet arrived is known to the LFB and this information may be used in the internal processing. For example, the input index can be used as a table selector, or as an explicit precedence selector to resolve contention. As with output groups, the number of input instances in an input group is not defined in the LFB class. However, the class definition may include restrictions on the range of possible values. In addition, if an FE supports configurable topologies, it may impose further limitations on the number of instances for particular port group(s) of a particular LFB class. Within these limitations, different instances of the same class may have a different number of input instances.
ファンインをモデル化する3番目の方法では、入力グループの概念を使用します。この概念は、前のセクションで導入された出力グループに似ており、図4.Cに示されています。入力グループは、多くの入力インスタンスで構成されており、すべてプロパティ（同じフレームとメタデータの期待）を共有しています。入力インスタンスには0からn-1の番号が付けられています。外部から、これらの入力は通常の入力として表示されます。つまり、互換性のあるアップストリームLFBは、その出力をこれらの入力のいずれかに接続できます。特定の入力インスタンスでパケットがLFBに提示されると、パケットが到着した入力のインデックスはLFBに知られており、この情報は内部処理で使用される場合があります。たとえば、入力インデックスは、テーブルセレクターとして、または競合を解決するための明示的な優先セレクターとして使用できます。出力グループと同様に、入力グループの入力インスタンスの数はLFBクラスでは定義されていません。ただし、クラスの定義には、可能な値の範囲の制限が含まれる場合があります。さらに、FEが構成可能なトポロジーをサポートする場合、特定のLFBクラスの特定のポートグループのインスタンス数にさらなる制限を課す可能性があります。これらの制限内で、同じクラスの異なるインスタンスには、入力インスタンスの数が異なる場合があります。
The number of actual input instances in the group is a component defined in the LFB class, which is read-only for static topologies, and is read-write for configurable topologies.
グループ内の実際の入力インスタンスの数は、LFBクラスで定義されているコンポーネントであり、静的トポロジの読み取り専用であり、構成可能なトポロジの読み取りワイトです。
As an example for the input group, consider the Scheduler LFB depicted in Figure 4.c. Such an LFB receives packets from a number of Queue LFBs via a number of input instances, and uses the input index information to control contention resolution and scheduling.
入力グループの例として、図4.Cに示すスケジューラLFBを検討してください。このようなLFBは、多くの入力インスタンスを介して多数のキューLFBからパケットを受信し、入力インデックス情報を使用して競合解決とスケジューリングを制御します。
In summary, the LFB class may define one input, multiple singleton inputs, one or more input groups, or a combination thereof. Any input allows for implicit multiplexing of similar packet streams via connecting multiple outputs to the same input. Explicit multiple singleton inputs are useful when either the contention handling must be handled explicitly or when the LFB class must receive and process a known number of distinct types of packet streams. An input group is suitable when contention handling must be modeled explicitly, but the number of inputs is not inherent from the class (and hence is not known when the class is defined), or when it is critical for LFB operation to know exactly on which input the packet was received.
要約すると、LFBクラスは、1つの入力、複数のSingleton入力、1つ以上の入力グループ、またはその組み合わせを定義できます。任意の入力により、複数の出力を同じ入力に接続することにより、同様のパケットストリームの暗黙的な多重化が可能になります。明示的な複数のSingleton入力は、競合処理を明示的に処理する必要がある場合、またはLFBクラスが既知の数の異なるタイプのパケットストリームを受信および処理する必要がある場合に役立ちます。競合処理を明示的にモデル化する必要がある場合は、入力グループが適切ですが、入力の数はクラスから固有のものではありません（したがって、クラスが定義されている場合は不明です）。入力パケットが受信されました。
When LFB classes are defined, the input and output packet formats (e.g., IPv4, IPv6, Ethernet) MUST be specified. These are the types of packets that a given LFB input is capable of receiving and processing, or that a given LFB output is capable of producing. This model requires that distinct packet types be uniquely labeled with a symbolic name and/or ID.
LFBクラスを定義する場合、入力および出力パケット形式（IPv4、IPv6、イーサネットなど）を指定する必要があります。これらは、特定のLFB入力が受信および処理できるパケットのタイプ、または特定のLFB出力が生成できるパケットです。このモデルでは、個別のパケットタイプにシンボリック名および/またはIDで一意にラベル付けされる必要があります。
Note that each LFB has a set of packet types that it operates on, but does not care whether the underlying implementation is passing a greater portion of the packets. For example, an IPv4 LFB might only operate on IPv4 packets, but the underlying implementation may or may not be stripping the L2 header before handing it over. Whether or not such processing is happening is opaque to the CE.
各LFBには、動作するパケットタイプのセットがありますが、基礎となる実装がパケットの大部分を通過しているかどうかは気にしないことに注意してください。たとえば、IPv4 LFBはIPv4パケットでのみ動作する場合がありますが、基礎となる実装では、L2ヘッダーを引き渡す前に剥がしている場合とそうでない場合があります。そのような処理が起こっているかどうかは、CEに不透明です。
Metadata is state that is passed from one LFB to another alongside a packet. The metadata passed with the packet assists subsequent LFBs to process that packet.
メタデータは、パケットと一緒にあるLFBから別のLFBに渡される状態です。メタデータは、パケットを支援して後続のLFBを支援して、そのパケットを処理しました。
The ForCES model defines metadata as precise atomic definitions in the form of label, value pairs.
力モデルは、メタデータをラベルペア、バリューペアの形式の正確な原子定義として定義しています。
The ForCES model provides to the authors of LFB classes a way to formally define how to achieve metadata creation, modification, reading, as well as consumption (deletion).
Forceモデルは、LFBクラスの著者に、メタデータの作成、修正、読書、および消費（削除）を実現する方法を正式に定義する方法を提供します。
Inter-FE metadata, i.e., metadata crossing FEs, while it is likely to be semantically similar to this metadata, is out of scope for this document.
Inter-FEメタデータ、すなわち、メタデータがFESを横切ることは、このメタデータと意味的に類似している可能性が高いが、このドキュメントの範囲外です。
Section 4 has informal details on metadata.
セクション4には、メタデータに関する非公式の詳細があります。
Each metadatum is modeled as a <label, value> pair, where the label identifies the type of information (e.g., "color"), and its value holds the actual information (e.g., "red"). The label here is shown as a textual label, but for protocol processing it is associated with a unique numeric value (identifier).
各メタデータは、<ラベル、値>ペアとしてモデル化されています。ここで、ラベルは情報の種類（「色」など）を識別し、その値は実際の情報（例：「赤」）を保持します。ここのラベルはテキストラベルとして表示されますが、プロトコル処理の場合、一意の数値（識別子）に関連付けられています。
To ensure inter-operability between LFBs, the LFB class specification must define what metadata the LFB class "reads" or "consumes" on its input(s) and what metadata it "produces" on its output(s). For maximum extensibility, this definition should specify neither which LFBs the metadata is expected to come from for a consumer LFB nor which LFBs are expected to consume metadata for a given producer LFB.
LFB間の相互運用性を確保するために、LFBクラスの仕様は、LFBクラスが入力で「読み取る」または「消費」し、それが出力で「生成」するメタデータを「消費」するものを定義する必要があります。最大限の拡張性のために、この定義では、消費者LFBのメタデータがどのLFBから生まれるかも、特定の生産者LFBのメタデータを消費することが予想されることも、どのLFBを指定する必要はありません。
For a given metadatum on a given packet path, there MUST be at least one producer LFB that creates that metadatum and SHOULD be at least one consumer LFB that needs that metadatum.
特定のパケットパス上の特定のメタデータの場合、そのメタデータを作成する少なくとも1つの生産者LFBが必要であり、そのメタデータを必要とする少なくとも1つの消費者LFBでなければなりません。
In the ForCES model, the producer and consumer LFBs of a metadatum are not required to be adjacent. In addition, there may be multiple producers and consumers for the same metadatum. When a packet path involves multiple producers of the same metadatum, then subsequent producers overwrite that metadatum value.
フォースモデルでは、メタデータの生産者と消費者LFBは隣接する必要はありません。さらに、同じメタデータには複数の生産者と消費者がいる場合があります。パケットパスに同じメタデータの複数の生産者が関与する場合、その後の生産者はそのメタデータ値を上書きします。
The metadata that is produced by an LFB is specified by the LFB class definition on a per-output-port-group basis. A producer may always generate the metadata on the port group, or may generate it only under certain conditions. We call the former "unconditional" metadata, whereas the latter is "conditional" metadata. For example, deep packet inspection LFB might produce several pieces of metadata about the packet. The first metadatum might be the IP protocol (TCP, UDP, SCTP, ...) being carried, and two additional metadata items might be the source and destination port number. These additional metadata items are conditional on the value of the first metadatum (IP carried protocol) as they are only produced for protocols that use port numbers. In the case of conditional metadata, it should be possible to determine from the definition of the LFB when "conditional" metadata is produced. The consumer behavior of an LFB, that is, the metadata that the LFB needs for its operation, is defined in the LFB class definition on a per-input-port-group basis. An input port group may "require" a given metadatum, or may treat it as "optional" information. In the latter case, the LFB class definition MUST explicitly define what happens if any optional metadata is not provided. One approach is to specify a default value for each optional metadatum, and assume that the default value is used for any metadata that is not provided with the packet.
LFBによって生成されるメタデータは、LFBクラスの定義によって指定されています。生産者は、常にポートグループでメタデータを生成するか、特定の条件下でのみ生成する場合があります。私たちは以前の「無条件の」メタデータと呼びますが、後者は「条件付き」メタデータです。たとえば、ディープパケット検査LFBは、パケットに関するいくつかのメタデータを生成する可能性があります。最初のメタデータは、IPプロトコル（TCP、UDP、SCTP、...）が運ばれる可能性があり、2つの追加のメタデータアイテムがソースと宛先ポート番号になる可能性があります。これらの追加のメタデータ項目は、ポート番号を使用するプロトコルに対してのみ生成されるため、最初のメタデータ（IPキャリープロトコル）の値を条件としています。条件付きメタデータの場合、「条件付き」メタデータが生成される場合、LFBの定義から決定できるはずです。LFBの消費者の行動、つまりLFBがその動作に必要なメタデータは、入力ポートグループごとにLFBクラスの定義で定義されます。入力ポートグループは、特定のメタデータを「必要」するか、「オプションの」情報として扱うことがあります。後者の場合、LFBクラスの定義は、オプションのメタデータが提供されていない場合に何が起こるかを明示的に定義する必要があります。1つのアプローチは、各オプションのメタデータのデフォルト値を指定し、パケットに提供されていないメタデータにデフォルト値が使用されると仮定することです。
When specifying the metadata tags, some harmonization effort must be made so that the producer LFB class uses the same tag as its intended consumer(s).
メタデータタグを指定する場合、プロデューサーLFBクラスが意図した消費者と同じタグを使用するように、いくつかの調和の取り組みを行う必要があります。
When the packet is processed by an LFB (i.e., between the time it is received and forwarded by the LFB), the LFB may perform read, write, and/or consume operations on any active metadata associated with the packet. If the LFB is considered to be a black box, one of the following operations is performed on each active metadatum.
パケットがLFBによって処理される場合（つまり、LFBが受信および転送されるまでに）、LFBはパケットに関連するアクティブメタデータの読み取り、書き込み、および/または消費を実行できます。LFBがブラックボックスと見なされる場合、各アクティブメタデータで次の操作の1つが実行されます。
* IGNORE: ignores and forwards the metadatum
* 無視：メタデータを無視して転送します
* READ: reads and forwards the metadatum
* 読む：メタデータを読んで転送します
* READ/RE-WRITE: reads, over-writes, and forwards the metadatum
* 読み取り/書き直し：メタデータを読み取り、過剰に書き、転送します
* WRITE: writes and forwards the metadatum (can also be used to create new metadata)
* 書き込み：メタデータを書き、転送します（新しいメタデータを作成するためにも使用できます）
* READ-AND-CONSUME: reads and consumes the metadatum
* 読み取りと検査：メタデータを読み取り、消費します
* CONSUME: consumes metadatum without reading
* 消費：読んでもメタデータを消費します
The last two operations terminate the life-cycle of the metadatum, meaning that the metadatum is not forwarded with the packet when the packet is sent to the next LFB.
最後の2つの操作は、メタデータのライフサイクルを終了します。つまり、パケットが次のLFBに送信されると、メタデータがパケットで転送されません。
In the ForCES model, a new metadatum is generated by an LFB when the LFB applies a WRITE operation to a metadatum type that was not present when the packet was received by the LFB. Such implicit creation may be unintentional by the LFB; that is, the LFB may apply the WRITE operation without knowing or caring whether or not the given metadatum existed. If it existed, the metadatum gets over-written; if it did not exist, the metadatum is created.
力モデルでは、LFBがLFBが受信したときに存在しないメタデータタイプに書き込み操作を適用すると、LFBによって新しいメタデータが生成されます。このような暗黙の創造は、LFBによって意図的ではない場合があります。つまり、LFBは、指定されたメタデータが存在したかどうかを知らずに、書き込み操作を適用する場合があります。それが存在する場合、メタデータはオーバーライティングされます。それが存在しなかった場合、メタデータが作成されます。
For LFBs that insert packets into the model, WRITE is the only meaningful metadata operation.
パケットをモデルに挿入するLFBの場合、書き込みは唯一の意味のあるメタデータ操作です。
For LFBs that remove the packet from the model, they may either READ-AND-CONSUME (read) or CONSUME (ignore) each active metadatum associated with the packet.
モデルからパケットを削除するLFBの場合、パケットに関連付けられている各アクティブメタデータを読み取り（読み取り）または消費（無視）することができます。
During operation, various conditions may occur that can be detected by LFBs. Examples range from link failure or restart to timer expiration in special purpose LFBs. The CE may wish to be notified of the occurrence of such events. The description of how such messages are sent, and their format, is part of the Forwarding and Control Element Separation (ForCES) protocol [RFC5810] document. Indicating how such conditions are understood is part of the job of this model.
操作中、LFBで検出できるさまざまな条件が発生する可能性があります。例は、リンクの障害または再起動から、特別な目的のLFBでタイマーの有効期限にまで及びます。CEは、そのようなイベントの発生について通知されることを望むかもしれません。そのようなメッセージの送信方法とその形式の説明は、転送および制御要素分離（Force）Protocol [RFC5810]ドキュメントの一部です。そのような条件がどのように理解されているかを示すことが、このモデルの仕事の一部です。
Events are declared in the LFB class definition. The LFB event declaration constitutes:
イベントは、LFBクラスの定義で宣言されています。LFBイベント宣言は次のとおりです。
o a unique 32-bit identifier.
o 一意の32ビット識別子。
o An LFB component that is used to trigger the event. This entity is known as the event target.
o イベントのトリガーに使用されるLFBコンポーネント。このエンティティは、イベントターゲットとして知られています。
o A condition that will happen to the event target that will result in a generation of an event to the CE. Examples of a condition include something getting created or deleted, a config change, etc.
o CEのイベントの世代をもたらすイベントターゲットに発生する条件。条件の例には、作成または削除されるもの、構成変更などが含まれます。
o What should be reported to the CE by the FE if the declared condition is met.
o 宣言された条件が満たされている場合、FEまでにCEに報告すべきもの。
The declaration of an event within an LFB class essentially defines what part of the LFB component(s) need to be monitored for events, what condition on the LFB monitored LFB component an FE should detect to trigger such an event, and what to report to the CE when the event is triggered.
LFBクラス内のイベントの宣言は、イベントについてLFBコンポーネントのどの部分を監視する必要があるか、LFB監視されたLFBコンポーネントのどの条件がそのようなイベントをトリガーするために検出するか、そして何を報告するかを基本的に定義します。イベントがトリガーされたときのCE。
While events may be declared by the LFB class definition, runtime activity is controlled using built-in event properties using LFB component properties (discussed in Section 3.2.6). A CE subscribes to the events on an LFB class instance by setting an event property for subscription. Each event has a subscription property that is by default off. A CE wishing to receive a specific event needs to turn on the subscription property at runtime.
イベントはLFBクラスの定義によって宣言される場合がありますが、ランタイムアクティビティは、LFBコンポーネントプロパティを使用して組み込みのイベントプロパティを使用して制御されます（セクション3.2.6で説明）。CEは、サブスクリプション用のイベントプロパティを設定することにより、LFBクラスインスタンスのイベントを購読します。各イベントには、デフォルトでオフになっているサブスクリプションプロパティがあります。特定のイベントを受けたいCEは、実行時にサブスクリプションプロパティをオンにする必要があります。
Event properties also provide semantics for runtime event filtering. A CE may set an event property to further suppress events to which it has already subscribed. The LFB model defines such filters to include threshold values, hysteresis, time intervals, number of events, etc.
イベントプロパティは、ランタイムイベントフィルタリングのセマンティクスも提供します。CEは、すでに購読しているイベントをさらに抑制するためにイベントプロパティを設定する場合があります。LFBモデルは、そのようなフィルターを定義して、しきい値、ヒステリシス、時間間隔、イベントの数などを含む。
The contents of reports with events are designed to allow for the common, closely related information that the CE can be strongly expected to need to react to the event. It is not intended to carry information that the CE already has, large volumes of information, or information related in complex fashions.
イベントを含むレポートの内容は、CEがイベントに対応する必要があると強く期待できる一般的で密接に関連する情報を可能にするように設計されています。CEがすでに持っている情報、大量の情報、または複雑なファッションに関連する情報を携帯することを意図したものではありません。
From a conceptual point of view, at runtime, event processing is split into:
概念的な観点から、実行時にイベント処理は以下に分割されます。
1. Detection of something happening to the (declared during LFB class definition) event target. Processing the next step happens if the CE subscribed (at runtime) to the event.
1. （LFBクラス定義中に宣言された）イベントターゲットに起こっていることの検出。次のステップの処理は、CEが（実行時に）イベントにサブスクライブした場合に発生します。
2. Checking of the (declared during LFB class definition) condition on the LFB event target. If the condition is met, proceed with the next step.
2. LFBイベントターゲットの（LFBクラス定義中に宣言）条件の確認。状態が満たされている場合は、次のステップを進めます。
3. Checking (runtime set) event filters if they exist to see if the event should be reported or suppressed. If the event is to be reported, proceed to the next step.
3. イベントが存在するかどうかを確認する（ランタイムセット）イベントフィルターは、イベントを報告するか抑制するかを確認するかどうかを確認します。イベントが報告される場合は、次のステップに進みます。
4. Submitting of the declared report to the CE.
4. 宣言されたレポートをCEに提出します。
Section 4.7.6 discusses events in more details.
セクション4.7.6では、イベントについて詳しく説明します。
LFBs and structures are made up of components, containing the information that the CE needs to see and/or change about the functioning of the LFB. These components, as described in detail in Section 4.7, may be basic values, complex structures (containing multiple components themselves, each of which can be values, structures, or tables), or tables (which contain values, structures, or tables). Components may be defined such that their appearance in LFB instances is optional. Components may be readable or writable at the discretion of the FE implementation. The CE needs to know these properties. Additionally, certain kinds of components (arrays / tables, aliases, and events) have additional property information that the CE may need to read or write. This model defines the structure of the property information for all defined data types.
LFBと構造はコンポーネントで構成されており、CEがLFBの機能について確認および/または変更する必要がある情報が含まれています。セクション4.7で詳細に説明されているように、これらのコンポーネントは、基本値、複雑な構造（複数のコンポーネント自体を含む、それぞれが値、構造、またはテーブル）、またはテーブル（値、構造、またはテーブルを含む）である場合があります。コンポーネントは、LFBインスタンスでの外観がオプションになるように定義される場合があります。コンポーネントは、FE実装の裁量で読みやすい、または書くことができます。CEはこれらのプロパティを知る必要があります。さらに、特定の種類のコンポーネント（配列 /テーブル、エイリアス、イベント）には、CEが読み書きが必要な追加のプロパティ情報があります。このモデルは、定義されたすべてのデータ型のプロパティ情報の構造を定義します。
Section 4.8 describes properties in more details.
セクション4.8では、詳細についてはプロパティについて説明します。
LFB class versioning is a method to enable incremental evolution of LFB classes. In general, an FE is not allowed to contain an LFB instance for more than one version of a particular class. Inheritance (discussed next in Section 3.2.8) has special rules. If an FE data path model containing an LFB instance of a particular class C also simultaneously contains an LFB instance of a class C' inherited from class C; C could have a different version than C'.
LFBクラスバージョン化は、LFBクラスの増分進化を可能にする方法です。一般に、FEは特定のクラスの複数のバージョンのLFBインスタンスを含めることは許可されていません。継承（セクション3.2.8で次に説明）には特別なルールがあります。特定のクラスCのLFBインスタンスを含むFEデータパスモデルに、クラスCから継承されたクラスC 'のLFBインスタンスも同時に含まれている場合。CはC 'とは異なるバージョンを持つことができます。
LFB class versioning is supported by requiring a version string in the class definition. CEs may support multiple versions of a particular LFB class to provide backward compatibility, but FEs MUST NOT support more than one version of a particular class.
LFBクラスバージョンは、クラス定義にバージョン文字列を要求することによりサポートされています。CESは、特定のLFBクラスの複数のバージョンをサポートして後方互換性を提供する場合がありますが、FESは特定のクラスの複数のバージョンをサポートしてはなりません。
Versioning is not restricted to making backward-compatible changes. It is specifically expected to be used to make changes that cannot be represented by inheritance. Often this will be to correct errors, and hence may not be backward compatible. It may also be used to remove components that are not considered useful (particularly if they were previously mandatory, and hence were an implementation impediment).
バージョン化は、後方互換の変更を行うことに制限されていません。継承によって表現できない変更を行うために使用されることが特に期待されています。多くの場合、これはエラーを修正するためであるため、後方互換性がない場合があります。また、役に立たないコンポーネントを削除するためにも使用できます（特に以前に必須であり、したがって実装障害であった場合）。
LFB class inheritance is supported in the FE model as a method to define new LFB classes. This also allows FE vendors to add vendor-specific extensions to standardized LFBs. An LFB class specification MUST specify the base class and version number it inherits from (the default is the base LFB class). Multiple inheritance is not allowed, however, to avoid unnecessary complexity.
LFBクラスの継承は、新しいLFBクラスを定義する方法としてFEモデルでサポートされています。これにより、FEベンダーはベンダー固有の拡張機能を標準化されたLFBに追加できます。LFBクラスの仕様は、継承するベースクラスとバージョン番号を指定する必要があります（デフォルトはベースLFBクラスです）。ただし、不必要な複雑さを避けるために、複数の継承は許可されていません。
Inheritance should be used only when there is significant reuse of the base LFB class definition. A separate LFB class should be defined if little or no reuse is possible between the derived and the base LFB class.
継承は、ベースLFBクラス定義の大幅な再利用がある場合にのみ使用する必要があります。派生したLFBクラスとベースLFBクラスの間で再利用がほとんどまたはまったく不可能な場合は、個別のLFBクラスを定義する必要があります。
An interesting issue related to class inheritance is backward compatibility between a descendant and an ancestor class. Consider the following hypothetical scenario where a standardized LFB class "L1" exists. Vendor A builds an FE that implements LFB "L1", and vendor B builds a CE that can recognize and operate on LFB "L1". Suppose that a new LFB class, "L2", is defined based on the existing "L1" class by extending its capabilities incrementally. Let us examine the FE backward-compatibility issue by considering what would happen if vendor B upgrades its FE from "L1" to "L2" and vendor C's CE is not changed. The old L1-based CE can interoperate with the new L2-based FE if the derived LFB class "L2" is indeed backward compatible with the base class "L1".
クラスの継承に関連する興味深い問題は、子孫と祖先クラスの間の後方互換性です。標準化されたLFBクラス「L1」が存在する次の仮説シナリオを考えてみましょう。ベンダーAはLFB「L1」を実装するFEを構築し、ベンダーBはLFB「L1」を認識して操作できるCEを構築します。新しいLFBクラス「L2」が、機能を段階的に拡張することにより、既存の「L1」クラスに基づいて定義されていると仮定します。ベンダーBがFEを「L1」から「L2」にアップグレードし、ベンダーCのCEが変更されない場合に何が起こるかを検討して、FEの後方互換性の問題を調べてみましょう。古いL1ベースのCEは、導出されたLFBクラス「L2」が実際に基本クラス「L1」と逆方向に互換性がある場合、新しいL2ベースのFEと相互運用できます。
The reverse scenario is a much less problematic case, i.e., when CE vendor B upgrades to the new LFB class "L2", but the FE is not upgraded. Note that as long as the CE is capable of working with older LFB classes, this problem does not affect the model; hence we will use the term "backward compatibility" to refer to the first scenario concerning FE backward compatibility.
逆シナリオは、問題の少ないケースです。つまり、CEベンダーBが新しいLFBクラス「L2」にアップグレードする場合ですが、FEはアップグレードされていません。CEが古いLFBクラスで作業できる限り、この問題はモデルに影響しないことに注意してください。したがって、「後方互換性」という用語を使用して、FEの後方互換性に関する最初のシナリオを参照します。
Backward compatibility can be designed into the inheritance model by constraining LFB inheritance to require that the derived class be a functional superset of the base class (i.e., the derived class can only add functions to the base class, but not remove functions). Additionally, the following mechanisms are required to support FE backward compatibility:
後方互換性は、派生クラスが基本クラスの機能的スーパーセットであることを要求するためにLFB継承を制約することにより、継承モデルに設計できます（つまり、派生クラスはベースクラスに関数を追加するだけではなく、関数を削除することはできません）。さらに、FEの後方互換性をサポートするには、次のメカニズムが必要です。
1. When detecting an LFB instance of an LFB type that is unknown to the CE, the CE MUST be able to query the base class of such an LFB from the FE.
1. CEに知られていないLFBタイプのLFBインスタンスを検出する場合、CEはFEからそのようなLFBのベースクラスを照会できる必要があります。
2. The LFB instance on the FE SHOULD support a backward-compatibility mode (meaning the LFB instance reverts itself back to the base class instance), and the CE SHOULD be able to configure the LFB to run in such a mode.
2. FEのLFBインスタンスは、後方互換性モード（LFBインスタンスが基本クラスインスタンスに戻ることを意味する）をサポートする必要があり、CEはLFBをそのようなモードで実行するように構成できるはずです。
Figure 5 demonstrates the abstraction of the different ForCES model entities. The ForCES protocol provides the mechanism to uniquely identify any of the LFB class instance components.
図5は、異なる力モデルエンティティの抽象化を示しています。力プロトコルは、LFBクラスインスタンスコンポーネントを一意に識別するメカニズムを提供します。
FE Address = FE01
+--------------------------------------------------------------+
| |
| +--------------+ +--------------+ |
| | LFB ClassID 1| |LFB ClassID 91| |
| | InstanceID 3 |============>|InstanceID 3 |======>... |
| | +----------+ | | +----------+ | |
| | |Components| | | |Components| | |
| | +----------+ | | +----------+ | |
| +--------------+ +--------------+ |
| |
+--------------------------------------------------------------+
Figure 5: FE entity hierarchy.
図5：FEエンティティ階層。
At the top of the addressing hierarchy is the FE identifier. In the example above, the 32-bit FE identifier is illustrated with the mnemonic FE01. The next 32-bit entity selector is the LFB ClassID. In the illustration above, two LFB classes with identifiers 1 and 91 are demonstrated. The example above further illustrates one instance of each of the two classes. The scope of the 32-bit LFB class instance identifier is valid only within the LFB class. To emphasize that point, each of class 1 and 91 has an instance of 3.
アドレス指定階層の上部には、FE識別子があります。上記の例では、32ビットFe識別子をニーモニックFe01に示します。次の32ビットエンティティセレクターはLFB ClassIDです。上記の図では、識別子1と91を持つ2つのLFBクラスが実証されています。上記の例は、2つのクラスのそれぞれの1つのインスタンスをさらに示しています。32ビットLFBクラスインスタンス識別子の範囲は、LFBクラス内でのみ有効です。その点を強調するために、クラス1と91のそれぞれには3のインスタンスがあります。
Using the described addressing scheme, a message could be sent to address FE01, LFB ClassID 1, LFB InstanceID 3, utilizing the ForCES protocol. However, to be effective, such a message would have to target entities within an LFB. These entities could be carrying state, capability, etc. These are further illustrated in Figure 6 below.
記述されたアドレス指定スキームを使用して、FE01、LFB ClassID 1、LFB InstanceID 3に対処するためにメッセージを送信できます。ただし、効果的であるためには、そのようなメッセージはLFB内のエンティティをターゲットにする必要があります。これらのエンティティは、状態、能力などを運ぶ可能性があります。これらを以下の図6にさらに示します。
LFB Class ID 1,InstanceID 3 Components
+-------------------------------------+
| |
| LFB ComponentID 1 |
| +----------------------+ |
| | | |
| +----------------------+ |
| |
| LFB ComponentID 31 |
| +----------------------+ |
| | | |
| +----------------------+ |
| |
| LFB ComponentID 51 |
| +----------------------+ |
| | LFB ComponentID 89 | |
| | +-----------------+ | |
| | | | | |
| | +-----------------+ | |
| +----------------------+ |
| |
| |
+-------------------------------------+
Figure 6: LFB hierarchy.
図6：LFB階層。
Figure 6 zooms into the components carried by LFB Class ID 1, LFB InstanceID 3 from Figure 5.
図6は、図5からLFBクラスID 1、LFB InstanceID 3によって運ばれるコンポーネントにズームします。
The example shows three components with 32-bit component identifiers 1, 31, and 51. LFB ComponentID 51 is a complex structure encapsulating within it an entity with LFB ComponentID 89. LFB ComponentID 89 could be a complex structure itself, but is restricted in the example for the sake of clarity.
この例は、32ビットコンポーネント識別子1、31、および51を持つ3つのコンポーネントを示しています。LFBコンポーネント51は、LFBコンポーネント89のエンティティをカプセル化する複雑な構造です。LFBコンポーネント89は複雑な構造自体になりますが、明確にするための例。
As mentioned above, LFB components could be complex structures, such as a table, or even more complex structures such as a table whose cells are further tables, etc. The ForCES model XML schema (Section 4) allows for uniquely identifying anything with such complexity, utilizing the concept of dot-annotated static paths and content addressing of paths as derived from keys. As an example, if LFB ComponentID 51 were a structure, then the path to LFB ComponentID 89 above will be 51.89.
上記のように、LFBコンポーネントは、テーブルなどの複雑な構造、またはセルがさらにテーブルであるテーブルなどのさらに複雑な構造である可能性があります。力モデルXMLスキーマ（セクション4）は、そのような複雑さのあるものを一意に識別することができます。、キーから導出されたパスのドット解剖された静的パスとコンテンツアドレス指定の概念を利用します。例として、LFBコンポーネント51が構造である場合、上記のLFBコンポーネント89へのパスは51.89になります。
LFB ComponentID 51 might represent a table (an array). In that case, to select the LFB component with ID 89 from within the 7th entry of the table, one would use the path 51.7.89. In addition to supporting explicit table element selection by including an index in the dotted path, the model supports identifying table elements by their contents. This is referred to as using keys, or key indexing. So, as a further example, if ComponentID 51 was a table that was key index-able, then a key describing content could also be passed by the CE, along with path 51 to select the table, and followed by the path 89 to select the table structure element, which upon computation by the FE would resolve to the LFB ComponentID 89 within the specified table entry.
LFBコンポーネント51は、テーブル（配列）を表す場合があります。その場合、テーブルの7番目のエントリ内からID 89を持つLFBコンポーネントを選択するには、パス51.7.89を使用します。点線にインデックスを含めることによる明示的なテーブル要素の選択をサポートすることに加えて、モデルはその内容によるテーブル要素の識別をサポートします。これは、キーまたはキーインデックスの使用と呼ばれます。したがって、さらに例として、ComponentID 51が重要なインデックス可能なテーブルである場合、CEを記述するキーをCEを渡すこともできます。パス51とともにテーブルを選択し、その後パス89が続き、選択して選択します。テーブル構造要素は、FEによる計算により、指定されたテーブルエントリ内でLFBコンポーネント89に解決します。
Packets coming into the FE from ingress ports generally flow through one or more LFBs before leaving out of the egress ports. How an FE treats a packet depends on many factors, such as type of the packet (e.g., IPv4, IPv6, or MPLS), header values, time of arrival, etc. The result of LFB processing may have an impact on how the packet is to be treated in downstream LFBs. This differentiation of packet treatment downstream can be conceptualized as having alternative data paths in the FE. For example, the result of a 6-tuple classification performed by a classifier LFB could control which rate meter is applied to the packet by a rate meter LFB in a later stage in the data path.
イングレスポートからFEに入ってくるパケットは、通常、1つ以上のLFBを介して流出してから出口ポートから離れます。FEがパケットをどのように処理するかは、パケットのタイプ（IPv4、IPv6、またはMPLSなど）、ヘッダー値、到着時間など、多くの要因に依存します。LFB処理の結果は、パケットの影響に影響を与える可能性があります。下流のLFBで扱われます。下流のパケット処理のこの区別は、FEに代替データパスを持つこととして概念化できます。たとえば、分類器LFBによって実行される6タプル分類の結果は、データパスの後期段階でレートメーターLFBによってパケットに適用されるレートメーターを制御できます。
LFB topology is a directed graph representation of the logical data paths within an FE, with the nodes representing the LFB instances and the directed link depicting the packet flow direction from one LFB to the next. Section 3.4.1 discusses how the FE data paths can be modeled as LFB topology, while Section 3.4.2 focuses on issues related to LFB topology reconfiguration.
LFBトポロジーは、FE内の論理データパスの指示されたグラフ表現であり、ノードはLFBインスタンスを表し、指示されたリンクが1つのLFBから次のLFBへのパケットフロー方向を表します。セクション3.4.1では、FEデータパスをLFBトポロジとしてモデル化する方法について説明し、セクション3.4.2はLFBトポロジの再構成に関連する問題に焦点を当てています。
There are two basic ways to express the differentiation in packet treatment within an FE; one represents the data path directly and graphically (topological approach) and the other utilizes metadata (the encoded state approach).
Fe内のパケット処理の分化を表現する2つの基本的な方法があります。1つはデータパスを直接およびグラフィカルに（トポロジーアプローチ）を表し、もう1つはメタデータ（エンコードされた状態アプローチ）を利用します。
o Topological Approach
o トポロジー的アプローチ
Using this approach, differential packet treatment is expressed by splitting the LFB topology into alternative paths. In other words, if the result of an LFB operation controls how the packet is further processed, then such an LFB will have separate output ports, one for each alternative treatment, connected to separate sub-graphs, each expressing the respective treatment downstream.
このアプローチを使用して、微分パケット処理は、LFBトポロジーを代替パスに分割することにより表されます。言い換えれば、LFB操作の結果がパケットのさらに処理方法を制御する場合、そのようなLFBは、それぞれのサブグラフに接続された各代替処理に1つずつ、それぞれが下流の治療を表現する個別の出力ポートを持ちます。
o Encoded State Approach
o エンコードされた状態アプローチ
An alternate way of expressing differential treatment is by using metadata. The result of the operation of an LFB can be encoded in a metadatum, which is passed along with the packet to downstream LFBs. A downstream LFB, in turn, can use the metadata and its value (e.g., as an index into some table) to determine how to treat the packet.
微分治療を表現する別の方法は、メタデータを使用することです。LFBの動作の結果は、メタデータでエンコードでき、パケットと下流のLFBに渡されます。次に、下流のLFBは、メタデータとその値（たとえば、あるテーブルへのインデックスとして）を使用して、パケットの治療方法を決定できます。
Theoretically, either approach could substitute for the other, so one could consider using a single pure approach to describe all data paths in an FE. However, neither model by itself results in the best representation for all practically relevant cases. For a given FE with certain logical data paths, applying the two different modeling approaches will result in very different looking LFB topology graphs. A model using only the topological approach may require a very large graph with many links or paths, and nodes (i.e., LFB instances) to express all alternative data paths. On the other hand, a model using only the encoded state model would be restricted to a string of LFBs, which is not an intuitive way to describe different data paths (such as MPLS and IPv4). Therefore, a mix of these two approaches will likely be used for a practical model. In fact, as we illustrate below, the two approaches can be mixed even within the same LFB.
理論的には、どちらのアプローチも他のアプローチに代わる可能性があるため、FEのすべてのデータパスを記述するために単一の純粋なアプローチを使用することを検討できます。ただし、どちらのモデルでも、実質的に関連するすべてのケースに最適な表現をもたらすことはありません。特定の論理データパスを使用した特定のFEの場合、2つの異なるモデリングアプローチを適用すると、LFBトポロジグラフが大きく異なります。トポロジーアプローチのみを使用するモデルでは、多くのリンクまたはパスを備えた非常に大きなグラフ、およびすべての代替データパスを表現するためにノード（つまり、LFBインスタンス）が必要になる場合があります。一方、エンコードされた状態モデルのみを使用するモデルは、さまざまなデータパス（MPLSやIPv4など）を記述する直感的な方法ではありません。したがって、これらの2つのアプローチの組み合わせは、実用的なモデルに使用される可能性があります。実際、以下に示すように、同じLFB内でも2つのアプローチを混合できます。
Using a simple example of a classifier with N classification outputs followed by other LFBs, Figure 7.a shows what the LFB topology looks like when using the pure topological approach. Each output from the classifier goes to one of the N LFBs where no metadata is needed. The topological approach is simple, straightforward, and graphically intuitive. However, if N is large and the N nodes following the classifier (LFB#1, LFB#2, ..., LFB#N) all belong to the same LFB type (e.g., meter), but each has its own independent components, the encoded state approach gives a much simpler topology representation, as shown in Figure 7.b. The encoded state approach requires that a table of N rows of meter components be provided in the Meter node itself, with each row representing the attributes for one meter instance. A metadatum M is also needed to pass along with the packet P from the classifier to the meter, so that the meter can use M as a look-up key (index) to find the corresponding row of the attributes that should be used for any particular packet P.
n分類出力を備えた分類器の簡単な例を使用して、他のLFBが続きます。図7.aは、純粋なトポロジーアプローチを使用する際のLFBトポロジーがどのように見えるかを示しています。分類器からの各出力は、メタデータが必要ないN LFBの1つに移動します。トポロジカルアプローチは、シンプルで、単純で、グラフィー的に直感的です。ただし、nが大きく、分類器（LFB＃1、LFB＃2、...、LFB＃N）に続くNノードがすべて同じLFBタイプ（例：メーター）に属しますが、それぞれに独自の独立したコンポーネントがあります、エンコードされた状態アプローチは、図7.bに示すように、はるかに単純なトポロジの表現を提供します。エンコードされた状態アプローチでは、メーターコンポーネントのn行のテーブルをメーターノード自体に提供する必要があり、各行は1メートルインスタンスの属性を表します。メーターが分類器からメーターにパケットPを渡すためにはメタデータMが必要であるため、メーターはルックアップキー（インデックス）としてMを使用して、任意の属性の対応する行を見つけることができます。特定のパケットP.
What if those N nodes (LFB#1, LFB#2, ..., LFB#N) are not of the same type? For example, if LFB#1 is a queue while the rest are all meters, what is the best way to represent such data paths? While it is still possible to use either the pure topological approach or the pure encoded state approach, the natural combination of the two appears to be the best option. Figure 7.c depicts two different functional data paths using the topological approach while leaving the N-1 meter instances distinguished by metadata only, as shown in Figure 7.c.
これらのnノード（LFB＃1、LFB＃2、...、LFB＃n）が同じタイプではない場合はどうなりますか？たとえば、LFB＃1がキューである場合、残りはすべてメートルである場合、そのようなデータパスを表す最良の方法は何ですか？純粋なトポロジーアプローチまたは純粋なエンコードされた状態アプローチのいずれかを使用することはまだ可能ですが、2つの自然な組み合わせが最良の選択肢であるように見えます。図7.Cは、図7.Cに示すように、メタデータのみで識別されたN-1メートルインスタンスのままにしながら、トポロジーアプローチを使用して2つの異なる機能データパスを示しています。
+----------+
P | LFB#1 |
+--------->|(Compon-1)|
+-------------+ | +----------+
| 1|------+ P +----------+
| 2|---------------->| LFB#2 |
| classifier 3| |(Compon-2)|
| ...|... +----------+
| N|------+ ...
+-------------+ | P +----------+
+--------->| LFB#N |
|(Compon-N)|
+----------+
(a) Using pure topological approach
(a) 純粋なトポロジーアプローチを使用します
+-------------+ +-------------+
| 1| | Meter |
| 2| (P, M) | (Compon-1) |
| 3|---------------->| (Compon-2) |
| ...| | ... |
| N| | (Compon-N) |
+-------------+ +-------------+
(b) Using pure encoded state approach to represent the LFB topology in 5(a), if LFB#1, LFB#2, ..., and LFB#N are of the same type (e.g., meter).
(b) 純粋なエンコード状態アプローチを使用して、LFB＃1、LFB＃2、...、およびLFB＃nが同じタイプ（メーターなど）の場合、LFBトポロジーを5（a）で表します。
+-------------+
+-------------+ (P, M) | queue |
| 1|------------->| (Compon-1) |
| 2| +-------------+
| 3| (P, M) +-------------+
| ...|------------->| Meter |
| N| | (Compon-2) |
+-------------+ | ... |
| (Compon-N) |
+-------------+
(c) Using a combination of the two, if LFB#1, LFB#2, ..., and LFB#N are of different types (e.g., queue and meter).
(c) LFB＃1、LFB＃2、...、およびLFB＃nの場合、2つの組み合わせを使用して、異なるタイプ（キューやメーターなど）です。
Figure 7: An example of how to model FE data paths.
図7：FEデータパスをモデル化する方法の例。
From this example, we demonstrate that each approach has a distinct advantage depending on the situation. Using the encoded state approach, fewer connections are typically needed between a fan-out node and its next LFB instances of the same type because each packet carries metadata the following nodes can interpret and hence invoke a different packet treatment. For those cases, a pure topological approach forces one to build elaborate graphs with many more connections and often results in an unwieldy graph. On the other hand, a topological approach is the most intuitive for representing functionally different data paths.
この例から、各アプローチには状況に応じて明確な利点があることを示します。エンコードされた状態アプローチを使用すると、各パケットがメタデータを運ぶ可能性があるため、異なるパケット処理を呼び出す可能性があるため、ファンアウトノードと同じタイプの次のLFBインスタンスの間で通常必要な接続が少なくなります。これらの場合、純粋なトポロジー的アプローチは、より多くの接続を備えた精巧なグラフを構築することを強制し、多くの場合、扱いにくいグラフになります。一方、トポロジカルアプローチは、機能的に異なるデータパスを表現するための最も直感的です。
For complex topologies, a combination of the two is the most flexible. A general design guideline is provided to indicate which approach is best used for a particular situation. The topological approach should primarily be used when the packet data path forks to distinct LFB classes (not just distinct parameterizations of the same LFB class), and when the fan-outs do not require changes, such as adding/removing LFB outputs, or require only very infrequent changes.
複雑なトポロジの場合、2つの組み合わせが最も柔軟です。特定の状況に最適なアプローチを示すために、一般的な設計ガイドラインが提供されています。トポロジー的アプローチは、パケットデータパスフォークが異なるLFBクラス（同じLFBクラスの明確なパラメーター化だけでなく）にフォークする場合、およびファンアウトがLFB出力の追加/削除、または削除などの変更を必要としない場合に使用する必要があります。非常にまれな変更のみ。
Configuration information that needs to change frequently should be expressed by using the internal attributes of one or more LFBs (and hence using the encoded state approach).
頻繁に変更する必要がある構成情報は、1つ以上のLFBの内部属性（したがってエンコードされた状態アプローチを使用して）を使用して表現する必要があります。
+---------------------------------------------+
| |
+----------+ V +----------+ +------+ |
| | | | |if IP-in-IP| | |
---->| ingress |->+----->|classifier|---------->|Decap.|---->---+
| ports | | |---+ | |
+----------+ +----------+ |others +------+
|
V
(a) The LFB topology with a logical loop
+-------+ +-----------+ +------+ +-----------+
| | | |if IP-in-IP | | | |
--->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|->
| ports | | |----+ | | | |
+-------+ +-----------+ |others +------+ +-----------+
|
V
(b) The LFB topology without the loop utilizing two independent
classifier instances.
Figure 8: An LFB topology example.
図8：LFBトポロジの例。
It is important to point out that the LFB topology described here is the logical topology, not the physical topology of how the FE hardware is actually laid out. Nevertheless, the actual implementation may still influence how the functionality is mapped to the LFB topology. Figure 8 shows one simple FE example. In this example, an IP-in-IP packet from an IPsec application like VPN may go to the classifier first and have the classification done based on the outer IP header. Upon being classified as an IP-in-IP packet, the packet is then sent to a decapsulator to strip off the outer IP header, followed by a classifier again to perform classification on the inner IP header. If the same classifier hardware or software is used for both outer and inner IP header classification with the same set of filtering rules, a logical loop is naturally present in the LFB topology, as shown in Figure 8.a. However, if the classification is implemented by two different pieces of hardware or software with different filters (i.e., one set of filters for the outer IP header and another set for the inner IP header), then it is more natural to model them as two different instances of classifier LFB, as shown in Figure 8.b.
ここで説明するLFBトポロジーは論理トポロジであり、FEハードウェアが実際にレイアウトされる方法の物理的トポロジではないことを指摘することが重要です。それにもかかわらず、実際の実装は、機能がLFBトポロジにマッピングされる方法に依然として影響する可能性があります。図8は、1つの簡単なFE例を示しています。この例では、VPNのようなIPSECアプリケーションからのIP-in-IPパケットは、最初に分類器に移動し、外部IPヘッダーに基づいて分類を実行できます。IP-in-IPパケットとして分類されると、パケットは脱カプセレーターに送信されて外側のIPヘッダーを取り除き、その後に分類器が再びインナーIPヘッダーで分類を実行します。同じ分類子ハードウェアまたはソフトウェアが、同じフィルタリングルールのセットを使用した外側および内側のIPヘッダー分類に使用されている場合、図8.a.ただし、分類が異なるフィルターを備えた2つの異なるハードウェアまたはソフトウェアによって実装されている場合（つまり、外部IPヘッダー用の1つのフィルターセットと内側のIPヘッダー用の別のセット）、2つとしてモデル化する方が自然なことです。図8.Bに示すように、分類器LFBのさまざまなインスタンス。
While there is little doubt that an individual LFB must be configurable, the configurability question is more complicated for LFB topology. Since the LFB topology is really the graphic representation of the data paths within an FE, configuring the LFB topology means dynamically changing the data paths, including changing the LFBs along the data paths on an FE (e.g., creating/ instantiating, updating, or deleting LFBs) and setting up or deleting interconnections between outputs of upstream LFBs to inputs of downstream LFBs.
個々のLFBが構成可能でなければならないことはほとんど疑いがありませんが、LFBトポロジの構成可能性の質問はより複雑です。LFBトポロジは実際にはFE内のデータパスのグラフィック表現であるため、LFBトポロジを構成することは、FEのデータパスに沿ったLFBの変更を含むデータパスを動的に変更することを意味します（たとえば、作成/インスタンス化、更新、削除LFBS）および下流LFBの入力への上流LFBの出力間の相互接続をセットアップまたは削除します。
Why would the data paths on an FE ever change dynamically? The data paths on an FE are set up by the CE to provide certain data plane services (e.g., Diffserv, VPN) to the network element's (NE) customers. The purpose of reconfiguring the data paths is to enable the CE to customize the services the NE is delivering at run time. The CE needs to change the data paths when the service requirements change, such as adding a new customer or when an existing customer changes their service. However, note that not all data path changes result in changes in the LFB topology graph. Changes in the graph are dependent on the approach used to map the data paths into LFB topology. As discussed in Section 3.4.1, the topological approach and encoded state approach can result in very different looking LFB topologies for the same data paths. In general, an LFB topology based on a pure topological approach is likely to experience more frequent topology reconfiguration than one based on an encoded state approach. However, even an LFB topology based entirely on an encoded state approach may have to change the topology at times, for example, to bypass some LFBs or insert new LFBs. Since a mix of these two approaches is used to model the data paths, LFB topology reconfiguration is considered an important aspect of the FE model.
FEのデータパスが動的に変化するのはなぜですか？FEのデータパスはCEによって設定され、特定のデータプレーンサービス（Diffserv、VPNなど）をネットワーク要素（NE）の顧客に提供します。データパスを再構成する目的は、CEが実行時に提供されているサービスをCEがカスタマイズできるようにすることです。CEは、新しい顧客を追加するなど、サービス要件が変更されたとき、または既存の顧客がサービスを変更するなど、データパスを変更する必要があります。ただし、すべてのデータパスの変更がLFBトポロジグラフの変更につながるわけではないことに注意してください。グラフの変更は、データパスをLFBトポロジにマッピングするために使用されるアプローチに依存します。セクション3.4.1で説明したように、トポロジーアプローチとエンコードされた状態アプローチは、同じデータパスに対して非常に異なるLFBトポロジーをもたらす可能性があります。一般に、純粋なトポロジー的アプローチに基づいたLFBトポロジーは、エンコードされた状態アプローチに基づいたものよりも頻繁なトポロジの再構成を経験する可能性があります。ただし、エンコードされた状態アプローチに完全に基づいたLFBトポロジでさえ、たとえば、いくつかのLFBをバイパスしたり、新しいLFBを挿入したりするために、時々トポロジを変更する必要がある場合があります。これら2つのアプローチが組み合わされていることを使用してデータパスをモデル化するため、LFBトポロジの再構成はFEモデルの重要な側面と見なされます。
We want to point out that allowing a configurable LFB topology in the FE model does not mandate that all FEs are required to have this capability. Even if an FE supports configurable LFB topology, the FE may impose limitations on what can actually be configured. Performance-optimized hardware implementations may have zero or very limited configurability, while FE implementations running on network processors may provide more flexibility and configurability. It is entirely up to the FE designers to decide whether or not the FE actually implements reconfiguration and if so, how much. Whether a simple runtime switch is used to enable or disable (i.e., bypass) certain LFBs, or more flexible software reconfiguration is used, is an implementation detail internal to the FE and outside the scope of the FE model. In either case, the CE(s) MUST be able to learn the FE's configuration capabilities. Therefore, the FE model MUST provide a mechanism for describing the LFB topology configuration capabilities of an FE. These capabilities may include (see Section 5 for full details):
FEモデルで構成可能なLFBトポロジを許可しても、すべてのFESがこの機能を持つ必要があることを義務付けていないことを指摘したいと思います。FEが構成可能なLFBトポロジをサポートしていても、FEは実際に構成できるものに制限を課す可能性があります。パフォーマンスが最適化されたハードウェアの実装は、ゼロまたは非常に限られた構成可能性を持つ場合がありますが、ネットワークプロセッサで実行されるFE実装により、柔軟性と構成可能性が向上する場合があります。FEが実際に再構成を実装するかどうか、そしてもしそうなら、どれだけを実装するかを決定するのは、完全にFEデザイナー次第です。特定のLFBSを有効または無効にする（つまり、バイパス）、またはより柔軟なソフトウェア再構成を使用する（つまり、バイパス）、FEモデルの範囲内およびFEモデルの範囲外の実装詳細が使用される場合（つまり、バイパス）、FEモデルの範囲外かどうかがあります。どちらの場合でも、CE（S）はFEの構成機能を学習できる必要があります。したがって、FEモデルは、FEのLFBトポロジ構成機能を記述するためのメカニズムを提供する必要があります。これらの機能には含まれる場合があります（詳細については、セクション5を参照）：
o Which LFB classes the FE can instantiate
o FEがインスタンス化できるLFBクラス
o The maximum number of instances of the same LFB class that can be created
o 作成できる同じLFBクラスのインスタンスの最大数
o Any topological limitations, for example:
o たとえば、トポロジーの制限：
* The maximum number of instances of the same class or any class that can be created on any given branch of the graph
* 同じクラスのインスタンスの最大数またはグラフの任意のブランチで作成できるクラス
* Ordering restrictions on LFBs (e.g., any instance of LFB class A must be always downstream of any instance of LFB class B)
* LFBでの注文制限（たとえば、LFBクラスAのインスタンスは、LFBクラスbのインスタンスの常に下流でなければなりません）
The CE needs some programming help in order to cope with the range of complexity. In other words, even when the CE is allowed to configure LFB topology for the FE, the CE is not expected to be able to interpret an arbitrary LFB topology and determine which specific service or application (e.g., VPN, Diffserv) is supported by the FE. However, once the CE understands the coarse capability of an FE, the CE MUST configure the LFB topology to implement the network service the NE is supposed to provide. Thus, the mapping the CE has to understand is from the high-level NE service to a specific LFB topology, not the other way around. The CE is not expected to have the ultimate intelligence to translate any high-level service policy into the configuration data for the FEs. However, it is conceivable that within a given network service domain, a certain amount of intelligence can be programmed into the CE to give the CE a general understanding of the LFBs involved to allow the translation from a high-level service policy to the low-level FE configuration to be done automatically. Note that this is considered an implementation issue internal to the control plane and outside the scope of the FE model. Therefore, it is not discussed any further in this document.
CEは、複雑さの範囲に対処するために、いくつかのプログラミングヘルプが必要です。言い換えれば、CEがFEのLFBトポロジーを構成することを許可されている場合でも、CEは任意のLFBトポロジを解釈し、どの特定のサービスまたはアプリケーション（VPN、diffserv）がどの特定のサービスまたはアプリケーションがサポートされているかを決定することは期待されません。fe。ただし、CEがFEの粗い機能を理解したら、CEはNEが提供するはずのネットワークサービスを実装するようにLFBトポロジを構成する必要があります。したがって、CEのマッピングは、高レベルのNEサービスから特定のLFBトポロジまでのものであり、その逆ではありません。CEは、高レベルのサービスポリシーをFESの構成データに変換するための究極のインテリジェンスを持つことは期待されていません。ただし、特定のネットワークサービスドメイン内で、CEに関連するLFBの一般的な理解を与えるために、CEに一定量のインテリジェンスをプログラムすることができると考えられます。自動的に実行されるレベルFE構成。これは、制御プレーンの内部およびFEモデルの範囲外の実装問題と見なされていることに注意してください。したがって、このドキュメントではこれ以上議論されていません。
+----------+ +-----------+
---->| Ingress |---->|classifier |--------------+
| | |chip | |
+----------+ +-----------+ |
v
+-------------------------------------------+
+--------+ | Network Processor |
<----| Egress | | +------+ +------+ +-------+ |
+--------+ | |Meter | |Marker| |Dropper| |
^ | +------+ +------+ +-------+ |
| | |
+----------+-------+ |
| | |
| +---------+ +---------+ +------+ +---------+ |
| |Forwarder|<------|Scheduler|<--|Queue | |Counter | |
| +---------+ +---------+ +------+ +---------+ |
+--------------------------------------------------------------+
Figure 9: The capability of an FE as reported to the CE.
図9：CEに報告されたFEの機能。
Figure 9 shows an example where a QoS-enabled (quality-of-service) router has several line cards that have a few ingress ports and egress ports, a specialized classification chip, and a network processor containing codes for FE blocks like meter, marker, dropper, counter, queue, scheduler, and IPv4 forwarder. Some of the LFB topology is already fixed and has to remain static due to the physical layout of the line cards. For example, all of the ingress ports might be hardwired into the classification chip so all packets flow from the ingress port into the classification engine. On the other hand, the LFBs on the network processor and their execution order are programmable. However, certain capacity limits and linkage constraints could exist between these LFBs. Examples of the capacity limits might be:
図9は、QoS対応（サービス品質）ルーターに、いくつかのイングレスポートと出口ポート、専門分類チップ、メーター、マーカーなどのFEブロックのコードを含むネットワークプロセッサを含むいくつかのラインカードがいくつかある例を示しています。、ドロッパー、カウンター、キュー、スケジューラ、およびIPv4フォワーダー。LFBトポロジの一部はすでに固定されており、ラインカードの物理レイアウトのために静的なままでなければなりません。たとえば、すべてのイングレスポートが分類チップに固定されている可能性があるため、すべてのパケットがイングレスポートから分類エンジンに流れます。一方、ネットワークプロセッサのLFBとその実行順序はプログラム可能です。ただし、これらのLFBの間には、特定の容量制限とリンケージの制約が存在する可能性があります。容量制限の例は次のとおりです。
o 8 meters
o 8メートル
o 16 queues in one FE
o 1つのFEで16のキュー
o the scheduler can handle at most up to 16 queues
o スケジューラはせいぜい最大16キューを処理できます
o The linkage constraints might dictate that:
o リンケージの制約はそれを決定するかもしれません：
* the classification engine may be followed by:
* 分類エンジンの後には次のとおりです。
+ a meter
+ メーター
+ marker
+ マーカー
+ dropper
+ ドロッパー
+ counter
+ カウンター
+ queue or IPv4 forwarder, but not a scheduler
+ キューまたはIPv4フォワーダーですが、スケジューラではありません
* queues can only be followed by a scheduler
* キューはスケジューラのみに続くことができます
* a scheduler must be followed by the IPv4 forwarder
* スケジューラの後にIPv4フォワーダーが続く必要があります
* the last LFB in the data path before going into the egress ports must be the IPv4 forwarder
* 出力ポートに入る前のデータパスの最後のLFBはIPv4フォワーダーでなければなりません
+-----+ +-------+ +---+
| A|--->|Queue1 |--------------------->| |
------>| | +-------+ | | +---+
| | | | | |
| | +-------+ +-------+ | | | |
| B|--->|Meter1 |----->|Queue2 |------>| |->| |
| | | | +-------+ | | | |
| | | |--+ | | | |
+-----+ +-------+ | +-------+ | | +---+
classifier +-->|Dropper| | | IPv4
+-------+ +---+ Fwd.
Scheduler
Figure 10: An LFB topology as configured by the CE and accepted by the FE.
図10：CEによって構成され、FEで受け入れられているLFBトポロジー。
Once the FE reports these capabilities and capacity limits to the CE, it is now up to the CE to translate the QoS policy into a desirable configuration for the FE. Figure 9 depicts the FE capability, while Figure 10 and Figure 11 depict two different topologies that the CE may request the FE to configure. Note that Figure 11 is not fully drawn, as inter-LFB links are included to suggest potential complexity, without drawing in the endpoints of all such links.
FEがこれらの機能と容量制限をCEに報告すると、QoSポリシーをFEの望ましい構成に変換するのはCE次第です。図9はFE機能を示していますが、図10と図11は、CEが構成するFEを要求する2つの異なるトポロジーを示しています。このようなリンクのすべてのエンドポイントを描画することなく、潜在的な複雑さを示唆するためにLFB間リンクが含まれているため、図11は完全には描画されていません。
Queue1
+---+ +--+
| A|------------------->| |--+
+->| | | | |
| | B|--+ +--+ +--+ +--+ |
| +---+ | | | | | |
| Meter1 +->| |-->| | |
| | | | | |
| +--+ +--+ | IPv4
| Counter1 Dropper1 Queue2| +--+ Fwd.
+---+ | +--+ +--->|A | +-+
| A|---+ | |------>|B | | |
------>| B|------------------------------>| | +-->|C |->| |->
| C|---+ +--+ | +>|D | | |
| D|-+ | | | +--+ +-+
+---+ | | +---+ Queue3 | |Scheduler
Classifier1 | | | A|------------> +--+ | |
| +->| | | |-+ |
| | B|--+ +--+ +-------->| | |
| +---+ | | | | +--+ |
| Meter2 +->| |-+ |
| | | |
| +--+ Queue4 |
| Marker1 +--+ |
+---------------------------->| |---+
| |
+--+
Figure 11: Another LFB topology as configured by the CE and accepted by the FE.
図11：CEによって構成され、FEで受け入れられている別のLFBトポロジー。
Note that both the ingress and egress are omitted in Figure 10 and Figure 11 to simplify the representation. The topology in Figure 11 is considerably more complex than Figure 10, but both are feasible within the FE capabilities, and so the FE should accept either configuration request from the CE.
表現を簡素化するために、図10と図11で侵入と出口の両方が省略されていることに注意してください。図11のトポロジーは図10よりもかなり複雑ですが、どちらもFE機能内で実行可能であるため、FEはCEからの構成要求を受け入れる必要があります。
The main goal of the FE model is to provide an abstract, generic, modular, implementation-independent representation of the FEs. This is facilitated using the concept of LFBs, which are instantiated from LFB classes. LFB classes and associated definitions will be provided in a collection of XML documents. The collection of these XML documents is called an LFB class library, and each document is called an LFB class library document (or library document, for short). Each of the library documents MUST conform to the schema presented in this section. The schema here and the rules for conforming to the schema are those defined by the W3C in the definitions of XML schema in XML schema [Schema1] and XML schema DataTypes [Schema2]. The root element of the library document is the <LFBLibrary> element.
FEモデルの主な目標は、FESの抽象的な、一般的、モジュール式、実装に依存しない表現を提供することです。これは、LFBクラスからインスタンス化されたLFBの概念を使用して促進されます。LFBクラスと関連する定義は、XMLドキュメントのコレクションで提供されます。これらのXMLドキュメントのコレクションはLFBクラスライブラリと呼ばれ、各ドキュメントはLFBクラスライブラリドキュメント（または略してライブラリドキュメント）と呼ばれます。各ライブラリ文書は、このセクションで提示されているスキーマに準拠する必要があります。ここでのスキーマとスキーマに準拠するためのルールは、XMLスキーマ[Schema1]およびXMLスキーマデータ型[Schema2]のXMLスキーマの定義でW3Cによって定義されているものです。ライブラリドキュメントのルート要素は、<lfblibrary>要素です。
It is not expected that library documents will be exchanged between FEs and CEs "over-the-wire". But the model will serve as an important reference for the design and development of the CEs (software) and FEs (mostly the software part). It will also serve as a design input when specifying the ForCES protocol elements for CE-FE communication.
ライブラリ文書がFESとCESの「オーバーワイヤー」の間で交換されることは予想されません。しかし、このモデルは、CES（ソフトウェア）とFES（主にソフトウェア部分）の設計と開発の重要な参照として機能します。また、CE-FE通信の力プロトコル要素を指定するときに設計入力としても機能します。
The following sections describe the portions of an LFBLibrary XML document. The descriptions primarily provide the necessary semantic information to understand the meaning and uses of the XML elements. The XML schema below provides the final definition on what elements are permitted, and their base syntax. Unfortunately, due to the limitations of English and XML, there are constraints described in the semantic sections that are not fully captured in the XML schema, so both sets of information need to be used to build a compliant library document.
次のセクションでは、lfblibrary xmlドキュメントの部分について説明します。説明は、主にXML要素の意味と使用を理解するために必要なセマンティック情報を提供します。以下のXMLスキーマは、許可されている要素とその基本構文に関する最終的な定義を提供します。残念ながら、英語とXMLの制限により、XMLスキーマで完全にキャプチャされていないセマンティックセクションに記載されている制約があるため、両方の情報セットを使用して準拠したライブラリドキュメントを作成する必要があります。
A namespace is needed to uniquely identify the LFB type in the LFB class library. The reference to the namespace definition is contained in Section 9, IANA Considerations.
LFBクラスライブラリのLFBタイプを一意に識別するには、名前空間が必要です。名前空間定義への参照は、セクション9、IANAの考慮事項に含まれています。
The <LFBLibrary> element serves as a root element of all library documents. A library document contains a sequence of top-level elements. The following is a list of all the elements that can occur directly in the <LFBLibrary> element. If they occur, they must occur in the order listed.
<lfblibrary>要素は、すべてのライブラリドキュメントのルート要素として機能します。ライブラリドキュメントには、一連のトップレベル要素が含まれています。以下は、<lfblibrary>要素で直接発生する可能性のあるすべての要素のリストです。それらが発生した場合、それらはリストされている順序で発生する必要があります。
o <description> providing a text description of the purpose of the library document,
o <説明>ライブラリドキュメントの目的のテキスト説明を提供する、
o <load> for loading information from other library documents,
o <Load>他のライブラリドキュメントから情報を読み込むために、
o <frameDefs> for the frame declarations, o <dataTypeDefs> for defining common data types,
o <フレーム>フレーム宣言の場合、<データタイプフェフ>の一般的なデータ型を定義するために、
o <metadataDefs> for defining metadata, and
o メタデータを定義するための<MetadAtadefs>
o <LFBClassDefs> for defining LFB classes.
o <LFBClassDefs> LFBクラスを定義するため。
Each element is optional. One library document may contain only metadata definitions, another may contain only LFB class definitions, and yet another may contain all of the above.
各要素はオプションです。1つのライブラリドキュメントにはメタデータの定義のみが含まれている場合があり、別のライブラリドキュメントにはLFBクラスの定義のみが含まれている場合があり、別のライブラリにはすべての定義が含まれている場合があります。
A library document can import other library documents if it needs to refer to definitions contained in the included document. This concept is similar to the "#include" directive in the C programming language. Importing is expressed by the use of <load> elements, which must precede all the above elements in the document. For unique referencing, each LFBLibrary instance document has a unique label defined in the "provide" attribute of the LFBLibrary element. Note that what this performs is a ForCES inclusion, not an XML inclusion. The semantic content of the library referenced by the <load> element is included, not the xml content. Also, in terms of the conceptual processing of <load> elements, the total set of documents loaded is considered to form a single document for processing. A given document is included in this set only once, even if it is referenced by <load> elements several times, even from several different files. As the processing of LFBLibrary information is not order dependent, the order for processing loaded elements is up to the implementor, as long as the total effect is as if all of the information from all the files were available for referencing when needed. Note that such computer processing of ForCES model library documents may be helpful for various implementations, but is not required to define the libraries, or for the actual operation of the protocol itself.
ライブラリドキュメントは、含まれているドキュメントに含まれる定義を参照する必要がある場合、他のライブラリドキュメントをインポートできます。この概念は、Cプログラミング言語の「#include」指令に似ています。インポートは、ドキュメント内の上記のすべての要素に先行する必要がある<load>要素の使用によって表されます。一意の参照のために、各lfblibraryインスタンスドキュメントには、lfblibrary要素の「提供」属性で定義された一意のラベルがあります。これが実行するのは、XML包含ではなく、力が含まれることであることに注意してください。XMLコンテンツではなく、<load>要素によって参照されるライブラリのセマンティックコンテンツが含まれています。また、<load>要素の概念処理に関しては、ロードされたドキュメントの合計セットは、処理用の単一のドキュメントを形成すると見なされます。特定のドキュメントは、いくつかの異なるファイルからであっても、<load>要素によって数回参照されている場合でも、このセットには一度だけ含まれています。lfblibrary情報の処理は順序に依存しないため、ロードされた要素を処理する順序は、すべてのファイルからのすべての情報が必要に応じて参照できるようになるように、ロードされた要素を処理する順序は実装者次第です。Force Model Libraryドキュメントのこのようなコンピューター処理は、さまざまな実装に役立つかもしれませんが、ライブラリを定義するために、またはプロトコル自体の実際の操作には必要ではないことに注意してください。
The following is a skeleton of a library document:
以下は、ライブラリドキュメントのスケルトンです。
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
provides="this_library">
<description>
<説明>
</description>
</description>
<!-- Loading external libraries (optional) -->
<load library="another_library"/>
...
<!-- FRAME TYPE DEFINITIONS (optional) -->
<frameDefs>
...
</frameDefs>
<!-- DATA TYPE DEFINITIONS (optional) -->
<dataTypeDefs>
...
</dataTypeDefs>
<!-- METADATA DEFINITIONS (optional) -->
<metadataDefs>
...
</metadataDefs>
<!--
-
-
LFB CLASS DEFINITIONS (optional) -->
<LFBCLassDefs>
</LFBCLassDefs>
</LFBLibrary>
This element is used to refer to another LFB library document. Similar to the "#include" directive in C, this makes the objects (metadata types, data types, etc.) defined in the referred library document available for referencing in the current document.
この要素は、別のLFBライブラリドキュメントを参照するために使用されます。Cの「#include」指令と同様に、これにより、紹介されたライブラリドキュメントで定義されているオブジェクト（メタデータタイプ、データ型など）が現在のドキュメントで参照できるようになります。
The load element MUST contain the label of the library document to be included and MAY contain a URL to specify where the library can be retrieved. The load element can be repeated unlimited times. Below are three examples for the <load> elements:
負荷要素には、含まれるライブラリドキュメントのラベルが含まれている必要があり、ライブラリを取得できる場所を指定するためのURLが含まれている場合があります。負荷要素は無制限に繰り返すことができます。以下は、<load>要素の3つの例です。
<load library="a_library"/>
<load library="another_library" location="another_lib.xml"/>
<load library="yetanother_library"
location="http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/>
Frame names are used in the LFB definition to define the types of frames the LFB expects at its input port(s) and emits at its output port(s). The <frameDefs> optional element in the library document contains one or more <frameDef> elements, each declaring one frame type.
フレーム名は、LFB定義で使用されて、LFBが入力ポートで期待するフレームのタイプを定義し、出力ポートで発します。ライブラリドキュメントの<FrameDefs>オプション要素には、1つ以上の<Framedef>要素が含まれており、それぞれが1つのフレームタイプを宣言しています。
Each frame definition MUST contain a unique name (NMTOKEN) and a brief synopsis. In addition, an optional detailed description MAY be provided.
各フレーム定義には、一意の名前（nmtoken）と簡単な概要が含まれている必要があります。さらに、オプションの詳細な説明が提供される場合があります。
Uniqueness of frame types MUST be ensured among frame types defined in the same library document and in all directly or indirectly included library documents.
同じライブラリドキュメントで定義されたフレームタイプ間および直接的または間接的に含まれるライブラリドキュメントで、フレームタイプの一意性を確保する必要があります。
The following example defines two frame types:
次の例では、2つのフレームタイプを定義します。
<frameDefs>
<frameDef>
<name>ipv4</name>
<synopsis>IPv4 packet</synopsis>
<description>
This frame type refers to an IPv4 packet.
</description>
</frameDef>
<frameDef>
<name>ipv6</name>
<synopsis>IPv6 packet</synopsis>
<description>
This frame type refers to an IPv6 packet.
</description>
</frameDef>
...
</frameDefs>
The (optional) <dataTypeDefs> element can be used to define commonly used data types. It contains one or more <dataTypeDef> elements, each defining a data type with a unique name. Such data types can be used in several places in the library documents, including: o Defining other data types
（オプション）<dataTypedefs>要素を使用して、一般的に使用されるデータ型を定義できます。1つ以上の<dataTypedef>要素が含まれており、それぞれが一意の名前でデータ型を定義しています。このようなデータ型は、以下を含むライブラリドキュメントのいくつかの場所で使用できます。o他のデータ型の定義
o Defining components of LFB classes
o LFBクラスのコンポーネントの定義
This is similar to the concept of having a common header file for shared data types.
これは、共有データ型の共通ヘッダーファイルを持つという概念に似ています。
Each <dataTypeDef> element MUST contain a unique name (NMTOKEN), a brief synopsis, and a type definition element. The name MUST be unique among all data types defined in the same library document and in any directly or indirectly included library documents. The <dataTypeDef> element MAY also include an optional longer description, for example:
各<dataTypedef>要素には、一意の名前（nmtoken）、簡単な概要、およびタイプ定義要素が含まれている必要があります。名前は、同じライブラリドキュメントで定義されているすべてのデータ型と、直接的または間接的に含まれるライブラリドキュメントで一意でなければなりません。<dataTypedef>要素には、オプションの長い説明も含まれる場合があります。たとえば、：
<dataTypeDefs>
<dataTypeDef>
<name>ieeemacaddr</name>
<synopsis>48-bit IEEE MAC address</synopsis>
... type definition ...
</dataTypeDef>
<dataTypeDef>
<name>ipv4addr</name>
<synopsis>IPv4 address</synopsis>
... type definition ...
</dataTypeDef>
...
</dataTypeDefs>
There are two kinds of data types: atomic and compound. Atomic data types are appropriate for single-value variables (e.g., integer, string, byte array).
データ型には、アトミックと化合物の2種類があります。原子データ型は、単一価値変数（整数、文字列、バイト配列など）に適しています。
The following built-in atomic data types are provided, but additional atomic data types can be defined with the <typeRef> and <atomic> elements:
次の組み込み原子データ型が提供されていますが、追加の原子データ型は<typeref>および<atomic>要素で定義できます。
<name> Meaning
---- -------
char 8-bit signed integer
uchar 8-bit unsigned integer
int16 16-bit signed integer
uint16 16-bit unsigned integer
int32 32-bit signed integer
uint32 32-bit unsigned integer
int64 64-bit signed integer
uint64 64-bit unsigned integer
boolean A true / false value where
0 = false, 1 = true
string[N] A UTF-8 string represented in at most
N octets
string A UTF-8 string without a configured
storage length limit
byte[N] A byte array of N bytes
octetstring[N] A buffer of N octets, which MAY
contain fewer than N octets. Hence
the encoded value will always have
a length.
float32 32-bit IEEE floating point number
float64 64-bit IEEE floating point number
These built-in data types can be readily used to define metadata or LFB attributes, but can also be used as building blocks when defining new data types. The boolean data type is defined here because it is so common, even though it can be built by sub-ranging the uchar data type, as defined under atomic types (Section 4.5.2).
これらの組み込みデータ型は、メタデータまたはLFB属性を定義するために容易に使用できますが、新しいデータ型を定義する際にはビルディングブロックとしても使用できます。ブールデータ型は、原子型（セクション4.5.2）で定義されているように、UCHARデータ型をサブレンジで構築できる場合でも、非常に一般的であるため、ここで定義されています。
Compound data types can build on atomic data types and other compound data types. Compound data types can be defined in one of four ways. They may be defined as an array of components of some compound or atomic data type. They may be a structure of named components of compound or atomic data types (cf. C structures). They may be a union of named components of compound or atomic data types (cf. C unions). They may also be defined as augmentations (explained in Section 4.5.7) of existing compound data types.
化合物データ型は、原子データ型およびその他の化合物データ型に基づいて構築できます。複合データ型は、4つの方法のいずれかで定義できます。それらは、いくつかの化合物または原子データ型のコンポーネントの配列として定義される場合があります。それらは、化合物または原子データ型の名前付きコンポーネントの構造である可能性があります（C構造を参照）。それらは、化合物または原子データ型（Cユニオンを参照）の名前付きコンポーネントの結合である可能性があります。また、既存の化合物データ型の増強（セクション4.5.7で説明）として定義することもできます。
Given that the ForCES protocol will be getting and setting component values, all atomic data types used here must be able to be conveyed in the ForCES protocol. Further, the ForCES protocol will need a mechanism to convey compound data types. However, the details of such representations are for the ForCES protocol [RFC5810] document to define, not the model document. Strings and octetstrings must be conveyed by the protocol with their length, as they are not delimited, the value does not itself include the length, and these items are variable length.
Force Protocolがコンポーネント値を取得および設定することを考えると、ここで使用されるすべての原子データ型をForce Protocolで伝達できる必要があります。さらに、力プロトコルには、化合物データ型を伝えるメカニズムが必要です。ただし、このような表現の詳細は、モデルドキュメントではなく、Force Protocol [RFC5810]ドキュメントを定義するためのものです。文字列とオクテットリングは、区切られていないため、長さでプロトコルによって伝達する必要があります。値自体には長さが含まれておらず、これらのアイテムは長さが変動します。
With regard to strings, this model defines a small set of restrictions and definitions on how they are structured. String and octetstring length limits can be specified in the LFB class definitions. The component properties for string and octetstring components also contain actual lengths and length limits. This duplication of limits is to allow for implementations with smaller limits than the maximum limits specified in the LFB class definition. In all cases, these lengths are specified in octets, not in characters. In terms of protocol operation, as long as the specified length is within the FE's supported capabilities, the FE stores the contents of a string exactly as provided by the CE, and returns those contents when requested. No canonicalization, transformations, or equivalences are performed by the FE. Components of type string (or string[n]) MAY be used to hold identifiers for correlation with components in other LFBs. In such cases, an exact octet for octet match is used. No equivalences are used by the FE or CE in performing that matching. The ForCES protocol [RFC5810] does not perform or require validation of the content of UTF-8 strings. However, UTF-8 strings SHOULD be encoded in the shortest form to avoid potential security issues described in [UNICODE]. Any entity displaying such strings is expected to perform its own validation (for example, for correct multi-byte characters, and for ensuring that the string does not end in the middle of a multi-byte sequence). Specific LFB class definitions MAY restrict the valid contents of a string as suited to the particular usage (for example, a component that holds a DNS name would be restricted to hold only octets valid in such a name). FEs should validate the contents of SET requests for such restricted components at the time the set is performed, just as range checks for range-limited components are performed. The ForCES protocol behavior defines the normative processing for requests using that protocol.
文字列に関して、このモデルは、それらがどのように構造化されているかについての小さな制限と定義のセットを定義します。文字列およびオクテットストリングの長さの制限は、LFBクラスの定義で指定できます。文字列およびオクテットストリングコンポーネントのコンポーネントプロパティには、実際の長さと長さの制限も含まれています。この制限の複製は、LFBクラス定義で指定された最大制限よりも、制限が少ない実装を可能にすることです。すべての場合において、これらの長さは、文字ではなくオクテットで指定されています。プロトコル操作に関しては、指定された長さがFEのサポートされている機能内にある限り、FEはCEが提供する文字列の内容を正確に保存し、要求されたときにそれらの内容を返します。標準化、変換、または同等性はFEによって実行されません。型文字列（または文字列[n]）のコンポーネントを使用して、他のLFBのコンポーネントと相関する識別子を保持することができます。そのような場合、オクテットマッチの正確なオクテットが使用されます。FEまたはCEでは、そのマッチングの実行に等価性は使用されません。Force Protocol [RFC5810]は、UTF-8文字列の内容の検証を実行または必要としません。ただし、[Unicode]に記載されている潜在的なセキュリティ問題を回避するために、UTF-8文字列を最短形式でエンコードする必要があります。そのような文字列を表示するエンティティは、独自の検証を実行することが期待されます（たとえば、正しいマルチバイト文字の場合、および文字列がマルチバイトシーケンスの中央で終了しないようにするため）。特定のLFBクラスの定義は、特定の使用法に適した文字列の有効な内容を制限する場合があります（たとえば、DNS名を保持するコンポーネントは、そのような名前で有効なオクテットのみを保持するように制限されます）。FESは、範囲制限コンポーネントの範囲チェックが実行されるように、セットが実行された時点で、そのような制限されたコンポーネントのセット要求の内容を検証する必要があります。力プロトコルの動作は、そのプロトコルを使用した要求の規範的処理を定義します。
For the definition of the actual type in the <dataTypeDef> element, the following elements are available: <typeRef>, <atomic>, <array>, <struct>, and <union>.
<dataTypedef>要素の実際のタイプの定義については、次の要素が利用可能です：<typeref>、<atomic>、<Array>、<struct>、および<Union>。
The predefined type alias is somewhere between the atomic and compound data types. Alias is used to allow a component inside an LFB to be an indirect reference to another component inside the same or a different LFB class or instance. The alias component behaves like a structure, one component of which has special behavior. Given that the special behavior is tied to the other parts of the structure, the compound result is treated as a predefined construct.
事前定義されたタイプエイリアスは、原子データ型と複合データ型の間のどこかにあります。エイリアスは、LFB内のコンポーネントを同じまたは異なるLFBクラスまたはインスタンス内の別のコンポーネントへの間接的な参照とするために使用されます。エイリアスコンポーネントは構造のように動作し、その1つのコンポーネントは特別な動作を持っています。特別な動作が構造の他の部分に結び付けられていることを考えると、複合結果は定義された構造として扱われます。
The <typeRef> element refers to an existing data type by its name. The referred data type MUST be defined either in the same library document or in one of the included library documents. If the referred data type is an atomic data type, the newly defined type will also be regarded as atomic. If the referred data type is a compound type, the new type will also be compound. Some usage examples follow:
<typeref>要素は、その名前で既存のデータ型を指します。参照されたデータ型は、同じライブラリドキュメントまたは付属のライブラリドキュメントのいずれかで定義する必要があります。参照されたデータ型が原子データ型である場合、新しく定義された型もアトミックと見なされます。参照されたデータ型が化合物型の場合、新しい型も化合物になります。いくつかの使用例は次のとおりです。
<dataTypeDef>
<name>short</name>
<synopsis>Alias to int16</synopsis>
<typeRef>int16</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>ieeemacaddr</name>
<synopsis>48-bit IEEE MAC address</synopsis>
<typeRef>byte[6]</typeRef>
</dataTypeDef>
The <atomic> element allows the definition of a new atomic type from an existing atomic type, applying range restrictions and/or providing special enumerated values. Note that the <atomic> element can only use atomic types as base types, and its result MUST be another atomic type.
<原子>要素は、既存の原子タイプからの新しい原子タイプの定義を可能にし、範囲の制限を適用したり、特別な列挙値を提供したりします。<原子>要素は、原子タイプをベースタイプとしてのみ使用でき、その結果は別のアトミックタイプでなければならないことに注意してください。
For example, the following snippet defines a new "dscp" data type:
たとえば、次のスニペットは、新しい「DSCP」データ型を定義しています。
<dataTypeDef>
<name>dscp</name>
<synopsis>Diffserv code point.</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="63"/>
</rangeRestriction>
<specialValues>
<specialValue value="0">
<name>DSCP-BE</name>
<synopsis>Best Effort</synopsis>
</specialValue>
...
</specialValues>
</atomic>
</dataTypeDef>
The <array> element can be used to create a new compound data type as an array of a compound or an atomic data type. Depending upon context, this document and others refer to such arrays as tables or arrays interchangeably, without semantic or syntactic implication. The type of the array entry can be specified either by referring to an existing type (using the <typeRef> element) or defining an unnamed type inside the <array> element using any of the <atomic>, <array>, <struct>, or <union> elements.
<Array>要素を使用して、化合物または原子データ型の配列として新しい化合物データ型を作成できます。コンテキストに応じて、このドキュメントや他のドキュメントは、セマンティックまたは構文の意味なしに、テーブルやアレイなどの配列を互換性があります。配列エントリのタイプは、既存のタイプ（<Typeref>要素を使用）を参照するか、<Atomic>、<Array>、<struct>、<struct>を使用して<Array>要素内の名前のないタイプを定義することで指定できます。、または<ユニオン>要素。
The array can be "fixed-size" or "variable-size", which is specified by the "type" attribute of the <array> element. The default is "variable-size". For variable-size arrays, an optional "maxlength" attribute specifies the maximum allowed length. This attribute should be used to encode semantic limitations, not implementation limitations. The latter (support for implementation constraints) should be handled by capability components of LFB classes, and should never be included as the maxlength in a data type array that is regarded as being of unlimited size.
配列は、<Array>要素の「タイプ」属性によって指定されている「固定サイズ」または「可変サイズ」にすることができます。デフォルトは「可変サイズ」です。可変サイズの配列の場合、オプションの「最大」属性は、最大許可された長さを指定します。この属性は、実装の制限ではなく、セマンティック制限をエンコードするために使用する必要があります。後者（実装制約のサポート）は、LFBクラスの機能コンポーネントによって処理される必要があり、無制限のサイズであると見なされるデータ型アレイの最大長として決して含めるべきではありません。
For fixed-size arrays, a "length" attribute MUST be provided that specifies the constant size of the array.
固定サイズの配列の場合、アレイの定数サイズを指定する「長さ」属性を提供する必要があります。
The result of this construct is always a compound type, even if the array has a fixed size of 1.
このコンストラクトの結果は、アレイの固定サイズが1の場合でも、常に複合タイプです。
Arrays MUST only be subscripted by integers, and will be presumed to start with index 0.
配列は整数でのみサブスクリプト付けする必要があり、インデックス0から開始すると推定されます。
In addition to their subscripts, arrays MAY be declared to have content keys. Such a declaration has several effects:
サブスクリプトに加えて、配列にはコンテンツキーがあると宣言される場合があります。このような宣言にはいくつかの効果があります。
o Any declared key can be used in the ForCES protocol to select a component for operations (for details, see the ForCES protocol [RFC5810]).
o 宣言されたキーをフォースプロトコルで使用して、操作用のコンポーネントを選択できます（詳細については、Force Protocol [RFC5810]を参照）。
o In any instance of the array, each declared key MUST be unique within that instance. That is, no two components of an array may have the same values on all the fields that make up a key.
o 配列のどの例でも、宣言された各キーは、そのインスタンス内で一意でなければなりません。つまり、キーを構成するすべてのフィールドで、配列の2つのコンポーネントが同じ値を持つことはありません。
Each key is declared with a keyID for use in the ForCES protocol [RFC5810], where the unique key is formed by combining one or more specified key fields. To support the case where an array of an atomic type with unique values can be referenced by those values, the key field identifier MAY be "*" (i.e., the array entry is the key). If the value type of the array is a structure or an array, then the key is one or more components of the value type, each identified by name. Since the field MAY be a component of the contained structure, a component of a component of a structure, or further nested, the field name is actually a concatenated sequence of component identifiers, separated by decimal points ("."). The syntax for key field identification is given following the array examples.
各キーは、力プロトコル[RFC5810]で使用するためのKeyIDで宣言されます。ここでは、1つ以上の指定されたキーフィールドを組み合わせることで一意のキーが形成されます。一意の値を持つ原子タイプの配列がそれらの値によって参照できる場合をサポートするために、キーフィールド識別子は「*」である場合があります（つまり、配列エントリがキーです）。配列の値タイプが構造または配列である場合、キーは値タイプの1つ以上のコンポーネントであり、それぞれが名前で識別されます。フィールドは、含まれる構造のコンポーネントである可能性があるため、構造のコンポーネントのコンポーネント、またはさらにネストされているため、フィールド名は実際には、小数点（「。」）で区切られたコンポーネント識別子の連結シーケンスです。キーフィールド識別の構文は、配列の例に従って示されています。
The following example shows the definition of a fixed-size array with a predefined data type as the array content type:
次の例は、配列コンテンツタイプとして定義されたデータ型を持つ固定サイズの配列の定義を示しています。
<dataTypeDef>
<name>dscp-mapping-table</name>
<synopsis>
A table of 64 DSCP values, used to re-map code space.
</synopsis>
<array type="fixed-size" length="64">
<typeRef>dscp</typeRef>
</array>
</dataTypeDef>
The following example defines a variable-size array with an upper limit on its size:
次の例では、サイズに上限がある可変サイズ配列を定義します。
<dataTypeDef>
<name>mac-alias-table</name>
<synopsis>A table with up to 8 IEEE MAC addresses</synopsis>
<array type="variable-size" maxlength="8">
<typeRef>ieeemacaddr</typeRef>
</array>
</dataTypeDef>
The following example shows the definition of an array with a local (unnamed) content type definition:
次の例は、ローカル（名前のない）コンテンツタイプ定義を備えた配列の定義を示しています。
<dataTypeDef>
<name>classification-table</name>
<synopsis>
A table of classification rules and result opcodes.
</synopsis>
<array type="variable-size">
<struct>
<component componentID="1">
<name>rule</name>
<synopsis>The rule to match</synopsis>
<typeRef>classrule</typeRef>
</component>
<component componentID="2">
<name>opcode</name>
<synopsis>The result code</synopsis>
<typeRef>opcode</typeRef>
</component>
</struct>
</array>
</dataTypeDef>
In the above example, each entry of the array is a <struct> of two components ("rule" and "opcode").
上記の例では、配列の各エントリは、2つのコンポーネント（ "ルール"と「opcode」）の<struct>です。
The following example shows a table of IP prefix information that can be accessed by a multi-field content key on the IP address, prefix length, and information source. This means that in any instance of this table, no two entries can have the same IP address, prefix length, and information source.
次の例は、IPアドレス、プレフィックスの長さ、情報源のマルチフィールドコンテンツキーによってアクセスできるIPプレフィックス情報の表を示しています。これは、このテーブルのどの例でも、同じIPアドレス、プレフィックスの長さ、および情報ソースを持つことができる2つのエントリがないことを意味します。
<dataTypeDef>
<name>ipPrefixInfo_table</name>
<synopsis>
A table of information about known prefixes
</synopsis>
<array type="variable-size">
<struct>
<component componentID="1">
<name>address-prefix</name>
<synopsis>the prefix being described</synopsis>
<typeRef>ipv4Prefix</typeRef>
</component>
<component componentID="2">
<name>source</name>
<synopsis>
the protocol or process providing this information
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="3">
<name>prefInfo</name>
<synopsis>the information we care about</synopsis>
<typeRef>hypothetical-info-type</typeRef>
</component>
</struct>
<contentKey contentKeyID="1">
<contentKeyField> address-prefix.ipv4addr</contentKeyField>
<contentKeyField> address-prefix.prefixlen</contentKeyField>
<contentKeyField> source</contentKeyField>
</contentKey>
</array>
</dataTypeDef>
Note that the keyField elements could also have been simply address-prefix and source, since all of the fields of address-prefix are being used.
Address-Prefixのすべてのフィールドが使用されているため、キーフィールド要素は単にアドレス-Prefixとソースであった可能性があることに注意してください。
In order to use key declarations, one must refer to components that are potentially nested inside other components in the array. If there are nested arrays, one might even use an array element as a key (but great care would be needed to ensure uniqueness).
キー宣言を使用するには、配列内の他のコンポーネント内にネストされる可能性のあるコンポーネントを参照する必要があります。ネストされた配列がある場合、キーとして配列要素を使用することさえあります（ただし、一意性を確保するには細心の注意が必要です）。
The key is the combination of the values of each field declared in a keyField element.
キーは、キーフィールド要素で宣言された各フィールドの値の組み合わせです。
Therefore, the value of a keyField element MUST be a concatenated sequence of field identifiers, separated by a "." (period) character. Whitespace is permitted and ignored.
したがって、キーフィールド要素の値は、「。」で区切られたフィールド識別子の連結シーケンスでなければなりません。（期間）文字。Whitespaceは許可され、無視されます。
A valid string for a single field identifier within a keyField depends upon the current context. Initially, in an array key declaration, the context is the type of the array. Progressively, the context is whatever type is selected by the field identifiers processed so far in the current key field declaration.
キーフィールド内の単一のフィールド識別子の有効な文字列は、現在のコンテキストによって異なります。当初、配列キー宣言では、コンテキストは配列のタイプです。徐々に、コンテキストは、現在のキーフィールド宣言でこれまでに処理されたフィールド識別子によって選択されるタイプです。
When the current context is an array (e.g., when declaring a key for an array whose content is an array), then the only valid value for the field identifier is an explicit number.
現在のコンテキストが配列である場合（たとえば、コンテンツが配列である配列のキーを宣言する場合）、フィールド識別子の唯一の有効な値は明示的な数字です。
When the current context is a structure, the valid values for the field identifiers are the names of the components of the structure. In the special case of declaring a key for an array containing an atomic type, where that content is unique and is to be used as a key, the value "*" MUST be used as the single key field identifier.
現在のコンテキストが構造である場合、フィールド識別子の有効な値は、構造のコンポーネントの名前です。そのコンテンツが一意であり、キーとして使用される原子タイプを含む配列のキーを宣言する特別なケースでは、値「*」は単一のキーフィールド識別子として使用する必要があります。
In reference array or structure elements, it is possible to construct keyFields that do not exist. keyField references SHOULD never reference optional structure components. For references to array elements, care must be taken to ensure that the necessary array elements exist when creating or modifying the overall array element. Failure to do so will result in FEs returning errors on the creation attempt.
参照配列または構造要素では、存在しないキーフィールドを構築することが可能です。キーフィールド参照は、オプションの構造コンポーネントを参照しないでください。配列要素への参照の場合、全体的な配列要素を作成または変更するときに必要な配列要素が存在するように注意する必要があります。そうしないと、FESが作成の試みでエラーを返します。
A structure is composed of a collection of data components. Each data component has a data type (either an atomic type or an existing compound type) and is assigned a name unique within the scope of the compound data type being defined. These serve the same function as "struct" in C, etc. These components are defined using <component> elements. A <struct> element MAY contain an optional derivation indication, a <derivedFrom> element. The structure definition MUST contain a sequence of one or more <component> elements.
構造は、データコンポーネントのコレクションで構成されています。各データコンポーネントには、データ型（原子型または既存の化合物タイプのいずれか）があり、定義されている化合物データ型の範囲内で一意の名前を割り当てられます。これらは、Cなどの「struct」と同じ関数を機能させます。これらのコンポーネントは、<component>要素を使用して定義されます。<struct>要素には、オプションの派生指標、<derivedfrom>要素が含まれる場合があります。構造定義には、1つ以上の<component>要素のシーケンスを含める必要があります。
The actual type of the component can be defined by referring to an existing type (using the <typeRef> element), or can be a locally defined (unnamed) type created by any of the <atomic>, <array>, <struct>, or <union> elements.
実際のタイプのコンポーネントは、既存のタイプ（<Typeref>要素を使用）を参照することで定義できます。または、<Atomic>、<Array>、<struct>、<struct>によって作成されたローカルで定義された（名前のない）タイプにすることができます。、または<ユニオン>要素。
The <component> element MUST include a componentID attribute. This provides the numeric ID for this component, for use by the protocol. The <component> MUST contain a component name and a synopsis. It MAY contain a <description> element giving a textual description of the component. The definition MAY also include an <optional> element, which indicates that the component being defined is optional. The definition MUST contain elements to define the data type of the component, as described above.
<component>要素には、componentid属性を含める必要があります。これにより、プロトコルで使用するために、このコンポーネントの数値IDが提供されます。<component>には、コンポーネント名と概要を含める必要があります。コンポーネントのテキストの説明を与える<説明>要素が含まれる場合があります。定義には、<optional>要素が含まれる場合があります。これは、定義されているコンポーネントがオプションであることを示します。定義には、上記のようにコンポーネントのデータ型を定義する要素を含める必要があります。
For a dataTypeDef of a struct, the structure definition MAY be inherited from, and augment, a previously defined structured type. This is indicated by including the optional derivedFrom attribute in the struct declaration before the definition of the augmenting or replacing components. Section 4.5.7 describes how this is done in more detail.
構造体のデータ型型の場合、構造定義は、以前に定義された構造化された型から継承され、増強される場合があります。これは、コンポーネントの拡張または交換の定義の前に、struct宣言にオプションの派生属性を含めることによって示されます。セクション4.5.7では、これがどのように行われるかについて説明します。
The componentID attribute for different components in a structure (or in an LFB) MUST be distinct. They do not need to be in order, nor do they need to be sequential. For clarity of human readability, and ease of maintenance, it is usual to define at least sequential sets of values. But this is for human ease, not a model or protocol requirement.
構造（またはLFB）内の異なるコンポーネントのコンポーネント属性は異なる必要があります。彼らは整理する必要はありませんし、順番にする必要もありません。人間の読みやすさとメンテナンスの容易さを明確にするために、少なくとも順次の値セットを定義することが通常です。しかし、これは人間の容易さであり、モデルやプロトコルの要件ではありません。
The result of this construct is always a compound type, even when the <struct> contains only one field.
このコンストラクトの結果は、<struct>に1つのフィールドのみが含まれている場合でも、常に複合タイプです。
An example is the following:
例は次のとおりです。
<dataTypeDef>
<name>ipv4prefix</name>
<synopsis>
IPv4 prefix defined by an address and a prefix length
</synopsis>
<struct>
<component componentID="1">
<name>address</name>
<synopsis>Address part</synopsis>
<typeRef>ipv4addr</typeRef>
</component>
<component componentID="2">
<name>prefixlen</name>
<synopsis>Prefix length part</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="32"/>
</rangeRestriction>
</atomic>
</component>
</struct>
</dataTypeDef>
Similar to the union declaration in C, this construct allows the definition of overlay types. Its format is identical to the <struct> element.
Cの組合宣言と同様に、この構成により、オーバーレイタイプの定義が可能になります。その形式は、<struct>要素と同じです。
The result of this construct is always a compound type, even when the union contains only one element.
このコンストラクトの結果は、組合に1つの要素のみが含まれている場合でも、常に複合タイプです。
It is sometimes necessary to have a component in an LFB or structure refer to information (a component) in other LFBs. This can, for example, allow an ARP LFB to share the IP->MAC Address table with the local transmission LFB, without duplicating information. Similarly, it could allow a traffic measurement LFB to share information with a traffic enforcement LFB. The <alias> declaration creates the constructs for this. This construct tells the CE and FE that any manipulation of the defined data is actually manipulation of data defined to exist in some specified part of some other LFB instance. The content of an <alias> element MUST be a named type. Whatever component the alias references (which is determined by the alias component properties, as described below), that component must be of the same type as that declared for the alias. Thus, when the CE or FE dereferences the alias component, the type of the information returned is known. The type can be a base type or a derived type. The actual value referenced by an alias is known as its target. When a GET or SET operation references the alias element, the value of the target is returned or replaced. Write access to an alias element is permitted if write access to both the alias and the target is permitted.
LFBまたは構造にコンポーネントが他のLFBの情報（コンポーネント）を参照する必要がある場合があります。これにより、たとえば、ARP LFBが情報を複製することなく、ローカルトランスミッションLFBとIP-> MACアドレステーブルを共有できるようになります。同様に、トラフィック測定LFBがトラフィック執行LFBと情報を共有できるようになります。<Alias>宣言は、これの構成要素を作成します。この構造は、CEとFEに、定義されたデータの操作は、他のいくつかのLFBインスタンスのいくつかの指定された部分に存在するように定義されたデータの操作であることを伝えます。<Alias>要素のコンテンツは、名前付きタイプでなければなりません。エイリアスが参照するコンポーネント（以下で説明するように、エイリアスコンポーネントプロパティによって決定されます）が参照してください。そのコンポーネントは、エイリアスについて宣言されたものと同じタイプでなければなりません。したがって、CEまたはFEがエイリアスコンポーネントを繰り返すと、返される情報のタイプがわかっています。このタイプは、ベースタイプまたは派生タイプにすることができます。エイリアスによって参照される実際の値は、そのターゲットとして知られています。getまたはset操作がエイリアス要素を参照すると、ターゲットの値が返されるか交換されます。エイリアスとターゲットの両方への書き込みアクセスが許可されている場合、エイリアス要素への書き込みアクセスが許可されます。
The target of a component declared by an <alias> element is determined by the information in the component's properties. Like all components, the properties include the support / read / write permission for the alias. In addition, there are several fields (components) in the alias properties that define the target of the alias. These components are the ID of the LFB class of the target, the ID of the LFB instance of the target, and a sequence of integers representing the path within the target LFB instance to the target component. The type of the target element must match the declared type of the alias. Details of the alias property structure are described in Section 4.8 of this document, on properties.
<Alias>要素によって宣言されたコンポーネントのターゲットは、コンポーネントのプロパティ内の情報によって決定されます。すべてのコンポーネントと同様に、プロパティには、エイリアスのサポート /読み取り /書き込み許可が含まれます。さらに、エイリアスのターゲットを定義するエイリアスプロパティには、いくつかのフィールド（コンポーネント）があります。これらのコンポーネントは、ターゲットのLFBクラスのID、ターゲットのLFBインスタンスのID、およびターゲットLFBインスタンス内のターゲットコンポーネントへのパスを表す整数のシーケンスです。ターゲット要素のタイプは、エイリアスの宣言されたタイプと一致する必要があります。エイリアスプロパティ構造の詳細については、プロパティに関するこのドキュメントのセクション4.8で説明されています。
Note that the read / write property of the alias refers to the value. The CE can only determine if it can write the target selection properties of the alias by attempting such a write operation. (Property components do not themselves have properties.)
エイリアスの読み取り /書き込みプロパティは、値を指すことに注意してください。CEは、そのような書き込み操作を試みることにより、エイリアスのターゲット選択プロパティを書き込むことができるかどうかのみを判断できます。（プロパティコンポーネントにはそれ自体がプロパティを持っていません。）
Compound types can also be defined as augmentations of existing compound types. If the existing compound type is a structure, augmentation MAY add new elements to the type. The type of an existing component MAY be replaced in the definition of an augmenting structure, but MAY only be replaced with an augmentation derived from the current type of the existing component. An existing component cannot be deleted. If the existing compound type is an array, augmentation means augmentation of the array element type.
化合物タイプは、既存の化合物タイプの増強として定義することもできます。既存の化合物タイプが構造である場合、増強はタイプに新しい要素を追加する可能性があります。既存のコンポーネントのタイプは、増強構造の定義に置き換えることができますが、現在のタイプの既存のコンポーネントから導出された増強にのみ置き換えることができます。既存のコンポーネントを削除することはできません。既存の化合物タイプがアレイの場合、増強はアレイ要素タイプの増強を意味します。
Augmentation MUST NOT be applied to unions.
増強を組合に適用してはなりません。
One consequence of this is that augmentations are backward compatible with the compound type from which they are derived. As such, augmentations are useful in defining components for LFB subclasses with backward compatibility. In addition to adding new components to a class, the data type of an existing component MAY be replaced by an augmentation of that component, and still meet the compatibility rules for subclasses. This compatibility constraint is why augmentations cannot be applied to unions.
これの1つの結果は、増強が由来する化合物タイプと後方互換性があることです。そのため、拡張は、後方互換性のあるLFBサブクラスのコンポーネントを定義するのに役立ちます。クラスに新しいコンポーネントを追加することに加えて、既存のコンポーネントのデータ型はそのコンポーネントの増強に置き換えられ、サブクラスの互換性ルールを満たすことができます。この互換性の制約は、増強を組合に適用できない理由です。
For example, consider a simple base LFB class A that has only one component (comp1) of type X. One way to derive class A1 from A can be by simply adding a second component (of any type). Another way to derive a class A2 from A can be by replacing the original component (comp1) in A of type X with one of type Y, where Y is an augmentation of X. Both classes A1 and A2 are backward compatible with class A.
たとえば、タイプXの1つのコンポーネント（comp1）のみを備えた単純なベースLFBクラスAを検討します。AからクラスA1を導出する1つの方法は、（任意のタイプの）2番目のコンポーネントを追加するだけです。AからクラスA2を導出する別の方法は、タイプXのAタイプYの1つの元のコンポーネント（comp1）をタイプyの1つに置き換えることです。ここで、yはxの増強です。クラスA1とA2の両方はクラスAと後方互換です。
The syntax for augmentations is to include a <derivedFrom> element in a structure definition, indicating what structure type is being augmented. Component names and component IDs for new components within the augmentation MUST NOT be the same as those in the structure type being augmented. For those components where the data type of an existing component is being replaced with a suitable augmenting data type, the existing component name and component ID MUST be used in the augmentation. Other than the constraint on existing elements, there is no requirement that the new component IDs be sequential with, greater than, or in any other specific relationship to the existing component IDs except different. It is expected that using values sequential within an augmentation, and distinct from the previously used values, will be a common method to enhance human readability.
増強の構文は、構造定義に<派生>要素を含めることであり、どの構造タイプが増強されているかを示します。増強内の新しいコンポーネントのコンポーネント名とコンポーネントIDは、構造タイプの構造タイプのものと同じでなければなりません。既存のコンポーネントのデータ型が適切な拡張データ型に置き換えられているコンポーネントの場合、既存のコンポーネント名とコンポーネントIDを増強で使用する必要があります。既存の要素に対する制約以外に、新しいコンポーネントIDが異なることを除いて、既存のコンポーネントIDとの他の特定の関係を順番に、またはその他の特定の関係で順次順番にする必要はありません。増強内で値を順番に使用すること、以前に使用された値とは異なるものを使用することは、人間の読みやすさを向上させる一般的な方法になることが期待されています。
The (optional) <metadataDefs> element in the library document contains one or more <metadataDef> elements. Each <metadataDef> element defines a metadatum.
ライブラリドキュメントの（オプション）<MetadAtadefs>要素には、1つ以上の<MetadAtadef>要素が含まれています。各<metadatadef>要素は、メタデータを定義します。
Each <metadataDef> element MUST contain a unique name (NMTOKEN). Uniqueness is defined to be over all metadata defined in this library document and in all directly or indirectly included library documents. The <metadataDef> element MUST also contain a brief synopsis, the tag value to be used for this metadata, and value type definition information. Only atomic data types can be used as value types for metadata. The <metadataDef> element MAY contain a detailed description element.
各<Metadatadef>要素には、一意の名前（nmtoken）が含まれている必要があります。一意性は、このライブラリドキュメントで定義されているすべてのメタデータと、直接的または間接的に含まれるライブラリドキュメントで定義されると定義されています。<metadatadef>要素には、このメタデータに使用するタグ値、値タイプ定義情報も含める必要があります。メタデータの値タイプとして使用できる原子データ型のみが使用できます。<metadatadef>要素には、詳細な説明要素が含まれている場合があります。
Two forms of type definitions are allowed. The first form uses the <typeRef> element to refer to an existing atomic data type defined in the <dataTypeDefs> element of the same library document or in one of the included library documents. The usage of the <typeRef> element is identical to how it is used in the <dataTypeDef> elements, except here it can only refer to atomic types. The latter restriction is not enforced by the XML schema.
タイプ定義の2つの形式が許可されています。最初のフォームは、<typeref>要素を使用して、同じライブラリドキュメントの<dataTypedefs>要素または付属のライブラリドキュメントのいずれかで定義された既存の原子データ型を参照します。<typeref>要素の使用法は、<dataTypedef>要素での使用方法と同一ですが、ここではアトミックタイプのみを参照できます。後者の制限は、XMLスキーマによって強制されません。
The second form is an explicit type definition using the <atomic> element. This element is used here in the same way as in the <dataTypeDef> elements.
2番目のフォームは、<atomic>要素を使用した明示的なタイプ定義です。この要素は、<dataTypedef>要素と同じ方法でここで使用されます。
The following example shows both usages:
次の例は、両方の使用法を示しています。
<metadataDefs>
<metadataDef>
<name>NEXTHOPID</name>
<synopsis>Refers to a Next Hop entry in NH LFB</synopsis>
<metadataID>17</metadataID>
<typeRef>int32</typeRef>
</metadataDef>
<metadataDef>
<name>CLASSID</name>
<synopsis>
Result of classification (0 means no match).
</synopsis>
<metadataID>21</metadataID>
<atomic>
<baseType>int32</baseType>
<specialValues>
<specialValue value="0">
<name>NOMATCH</name>
<synopsis>
Classification didn't result in match.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
</metadataDefs>
The (optional) <LFBClassDefs> element can be used to define one or more LFB classes using <LFBClassDef> elements. Each <LFBClassDef> element MUST define an LFB class and include the following elements:
（オプション）<LFBClassDefs>要素を使用して、<LFBClassDef>要素を使用して1つ以上のLFBクラスを定義できます。各<LFBClassDef>要素は、LFBクラスを定義し、次の要素を含める必要があります。
o <name> provides the symbolic name of the LFB class. Example: "ipv4lpm".
o <name> LFBクラスのシンボリック名を提供します。例：「IPv4lpm」。
o <synopsis> provides a short synopsis of the LFB class. Example: "IPv4 Longest Prefix Match Lookup LFB".
o <概要> LFBクラスの短い概要を提供します。例：「IPv4最長のプレフィックスマッチルックアップLFB」。
o <version> is the version indicator.
o <バージョン>はバージョンインジケーターです。
o <derivedFrom> is the inheritance indicator.
o <derivedfrom>は継承指標です。
o <inputPorts> lists the input ports and their specifications.
o <inuptports>入力ポートとその仕様をリストします。
o <outputPorts> lists the output ports and their specifications.
o <OutputPorts>は、出力ポートとその仕様をリストします。
o <components> defines the operational components of the LFB.
o <コンポーネント> LFBの運用コンポーネントを定義します。
o <capabilities> defines the capability components of the LFB.
o <機能> LFBの機能コンポーネントを定義します。
o <description> contains the operational specification of the LFB.
o <説明> LFBの運用仕様が含まれています。
o The LFBClassID attribute of the LFBClassDef element defines the ID for this class. These must be globally unique.
o LFBClassDEF要素のLFBClassID属性は、このクラスのIDを定義します。これらはグローバルにユニークでなければなりません。
o <events> defines the events that can be generated by instances of this LFB.
o <Events>このLFBのインスタンスで生成できるイベントを定義します。
LFB class names must be unique, in order to enable other documents to reference the classes by name, and to enable human readers to understand references to class names. While a complex naming structure could be created, simplicity is preferred. As given in the IANA Considerations section of this document, the IANA maintains a registry of LFB class names and class identifiers, along with a reference to the document defining the class.
LFBクラス名は、他のドキュメントが名前でクラスを参照できるようにし、人間の読者がクラス名への参照を理解できるようにするために一意でなければなりません。複雑な命名構造を作成することができますが、シンプルさが推奨されます。このドキュメントのIANA考慮事項セクションに記載されているように、IANAは、クラスを定義するドキュメントへの参照とともに、LFBクラス名とクラス識別子のレジストリを維持しています。
Below is a skeleton of an example LFB class definition. Note that in order to keep from complicating the XML schema, the order of elements in the class definition is fixed. Elements, if they appear, must appear in the order shown.
以下は、LFBクラス定義の例のスケルトンです。XMLスキーマを複雑にしないようにするために、クラス定義の要素の順序が修正されることに注意してください。要素が表示されている場合は、表示される順序で表示する必要があります。
<LFBClassDefs>
<LFBClassDef LFBClassID="12345">
<name>ipv4lpm</name>
<synopsis>IPv4 Longest Prefix Match Lookup LFB</synopsis>
<version>1.0</version>
<derivedFrom>baseclass</derivedFrom>
<inputPorts> ... </inputPorts>
<inuptports> ... </inputports>
<outputPorts> ... </outputPorts>
<OutputPorts> ... </outputPorts>
<components> ... </components>
<components> ... </components>
<capabilities> ... </capabilities>
<機能> ... </capabilities>
<events> ... </events>
<Events> ... </events>
<description> This LFB represents the IPv4 longest prefix match lookup operation. The modeled behavior is as follows: Blah-blah-blah. </description>
<説明>このLFBは、IPv4最長のプレフィックスマッチルックアップ操作を表します。モデル化された動作は次のとおりです。Blah-blah-blah。</description>
</LFBClassDef> ... </LFBClassDefs>
</lfbclassdef> ... </lfbclassdefs>
The individual components and capabilities will have componentIDs for use by the ForCES protocol. These parallel the componentIDs used in structs, and are used the same way. Component and capability componentIDs must be unique within the LFB class definition.
個々のコンポーネントと機能には、力プロトコルで使用するコンポーネントがあります。これらは、構造体で使用されているコンポーネントと平行し、同じ方法で使用されます。コンポーネントと機能コンポーネントは、LFBクラスの定義内で一意でなければなりません。
Note that the <name>, <synopsis>, and <version> elements are required; all other elements are optional in <LFBClassDef>. However, when they are present, they must occur in the above order.
<name>、<synopsis>、および<バージョン>要素が必要であることに注意してください。他のすべての要素は<lfbclassdef>でオプションです。ただし、それらが存在する場合、上記の順序で発生する必要があります。
The componentID attribute for different items in an LFB class definition (or components in a struct) MUST be distinct. They do not need to be in order, nor do they need to be sequential. For clarity of human readability, and ease of maintenance, it is usual to define at least sequential sets of values. But this is for human ease, not a model or protocol requirement.
LFBクラス定義（または構造体のコンポーネント）の異なるアイテムのコンポーネント属性は異なる必要があります。彼らは整理する必要はありませんし、順番にする必要もありません。人間の読みやすさとメンテナンスの容易さを明確にするために、少なくとも順次の値セットを定義することが通常です。しかし、これは人間の容易さであり、モデルやプロトコルの要件ではありません。
The optional <derivedFrom> element can be used to indicate that this class is a derivative of some other class. The content of this element MUST be the unique name (<name>) of another LFB class. The referred LFB class MUST be defined in the same library document or in one of the included library documents. In the absence of a <derivedFrom>, the class is conceptually derived from the common, empty, base class.
オプションの<derivedfrom>要素を使用して、このクラスが他のクラスの派生物であることを示すことができます。この要素の内容は、別のLFBクラスの一意の名前（<name>）でなければなりません。参照されたLFBクラスは、同じライブラリドキュメントまたは付属のライブラリドキュメントのいずれかで定義する必要があります。<derivedfrom>がない場合、クラスは概念的に一般的な空の基本クラスから派生しています。
It is assumed that a derived class is backward compatible with its base class. A derived class MAY add components to a parent class, but cannot delete components. This also applies to input and output ports, events, and capabilities.
派生クラスは、その基本クラスと後方互換性があると想定されています。派生クラスは、親クラスにコンポーネントを追加する場合がありますが、コンポーネントを削除することはできません。これは、入力ポートと出力ポート、イベント、および機能にも適用されます。
The optional <inputPorts> element is used to define input ports. An LFB class MAY have zero, one, or more inputs. If the LFB class has no input ports, the <inputPorts> element MUST be omitted. The <inputPorts> element can contain one or more <inputPort> elements, one for each port or port group. We assume that most LFBs will have exactly one input. Multiple inputs with the same input type are modeled as one input group. Input groups are defined the same way as input ports by the <inputPort> element, differentiated only by an optional "group" attribute.
オプションの<inuptports>要素は、入力ポートを定義するために使用されます。LFBクラスには、ゼロ、1、またはそれ以上の入力がある場合があります。LFBクラスに入力ポートがない場合、<inuptports>要素を省略する必要があります。<inuptports>要素には、ポートグループまたはポートグループごとに1つ以上の<inuptport>要素を含めることができます。ほとんどのLFBには1つの入力が1つあると仮定します。同じ入力タイプの複数の入力は、1つの入力グループとしてモデル化されています。入力グループは、<inuptport>要素によって入力ポートと同じ方法で定義され、オプションの「グループ」属性によってのみ区別されます。
Multiple inputs with different input types should be avoided if possible (see discussion in Section 4.7.3). Some special LFBs will have no inputs at all. For example, a packet generator LFB does not need an input.
可能であれば、異なる入力タイプを持つ複数の入力を避ける必要があります（セクション4.7.3の説明を参照）。一部の特別なLFBには、入力がまったくありません。たとえば、パケットジェネレーターLFBには入力は必要ありません。
Single input ports and input port groups are both defined by the <inputPort> element; they are differentiated only by an optional "group" attribute.
単一の入力ポートと入力ポートグループはどちらも<inuptport>要素によって定義されます。それらは、オプションの「グループ」属性によってのみ区別されます。
The <inputPort> element MUST contain the following elements:
<inuptport>要素には、次の要素が含まれている必要があります。
o <name> provides the symbolic name of the input. Example: "in". Note that this symbolic name must be unique only within the scope of the LFB class.
o <name>入力のシンボリック名を提供します。例：「in」。この象徴的な名前は、LFBクラスの範囲内でのみ一意でなければならないことに注意してください。
o <synopsis> contains a brief description of the input. Example: "Normal packet input".
o <synopsis>入力の簡単な説明が含まれています。例：「通常のパケット入力」。
o <expectation> lists all allowed frame formats. Example: {"ipv4" and "ipv6"}. Note that this list should refer to names specified in the <frameDefs> element of the same library document or in any included library documents. The <expectation> element can also provide a list of required metadata. Example: {"classid", "vpnid"}. This list should refer to names of metadata defined in the <metadataDefs> element in the same library document or in any included library documents. For each metadatum, it must be specified whether the metadatum is required or optional. For each optional metadatum, a default value must be specified, which is used by the LFB if the metadatum is not provided with a packet.
o <Expectation>許可されているすべてのフレーム形式をリストします。例：{"ipv4"および "ipv6"}。このリストは、同じライブラリドキュメントの<Framedefs>要素または含まれるライブラリドキュメントで指定された名前を参照する必要があることに注意してください。<Axpectation>要素は、必要なメタデータのリストも提供できます。例：{"classID"、 "vpnid"}。このリストは、同じライブラリドキュメントまたは含まれるライブラリドキュメントの<metadatadefs>要素で定義されているメタデータの名前を参照する必要があります。各メタデータについて、メタデータが必要かオプションであるかを指定する必要があります。オプションのメタデータごとに、デフォルト値を指定する必要があります。これは、メタデータにパケットが提供されていない場合はLFBが使用します。
In addition, the optional "group" attribute of the <inputPort> element can specify if the port can behave as a port group, i.e., it is allowed to be instantiated. This is indicated by a "true" value (the default value is "false").
さらに、<inuptport>要素のオプションの「グループ」属性は、ポートがポートグループとして動作できるかどうか、つまりインスタンス化できるかどうかを指定できます。これは、「真の」値（デフォルト値は「false」です）で示されます。
An example <inputPorts> element, defining two input ports, the second one being an input port group is the following:
2つの入力ポートを定義する<inuptports>要素の例は、入力ポートグループです。
<inputPorts>
<inputPort>
<name>in</name>
<synopsis>Normal input</synopsis>
<expectation>
<frameExpected>
<ref>ipv4</ref>
<ref>ipv6</ref>
</frameExpected>
<metadataExpected>
<ref>classid</ref>
<ref>vifid</ref>
<ref dependency="optional" defaultValue="0">vrfid</ref>
</metadataExpected>
</expectation>
</inputPort>
<inputPort group="true">
... another input port ...
</inputPort>
</inputPorts>
For each <inputPort>, the frame type expectations are defined by the <frameExpected> element using one or more <ref> elements (see example above). When multiple frame types are listed, it means that "one of these" frame types is expected. A packet of any other frame type is regarded as incompatible with this input port of the LFB class. The above example lists two frames as expected frame types: "ipv4" and "ipv6".
<inuptport>ごとに、フレームタイプの期待は、1つ以上の<Ref>要素を使用して<FreamExpected>要素によって定義されます（上記の例を参照）。複数のフレームタイプがリストされている場合、「これらの1つ」フレームタイプが予想されることを意味します。他のフレームタイプのパケットは、LFBクラスのこの入力ポートと互換性がないと見なされます。上記の例には、予想されるフレームタイプの2つのフレームが示されています：「IPv4」と「IPv6」。
Metadata expectations are specified by the <metadataExpected> element. In its simplest form, this element can contain a list of <ref> elements, each referring to a metadatum. When multiple instances of metadata are listed by <ref> elements, it means that "all of these" metadata must be received with each packet (except metadata that are marked as "optional" by the "dependency" attribute of the corresponding <ref> element). For a metadatum that is specified "optional", a default value MUST be provided using the "defaultValue" attribute. The above example lists three metadata as expected metadata, two of which are mandatory ("classid" and "vifid"), and one being optional ("vrfid").
メタデータの期待は、<metadataexpected>要素によって指定されます。最も単純な形式では、この要素には<Ref>要素のリストを含めることができ、それぞれがメタデータを指します。メタデータの複数のインスタンスが<Ref>要素によってリストされている場合、「これらすべて」メタデータを各パケットで受信する必要があることを意味します（対応する<Ref>エレメント）。「オプション」が指定されているメタデータの場合、「defaultValue」属性を使用してデフォルト値を提供する必要があります。上記の例には、予想される3つのメタデータが記載されています。そのうち2つは必須（「classID」と「vifid」）、もう1つはオプション（「vrfid」）です。
The schema also allows for more complex definitions of metadata expectations. For example, using the <one-of> element, a list of metadata can be specified to express that at least one of the specified metadata must be present with any packet. An example is the following:
スキーマは、メタデータの期待のより複雑な定義も可能にします。たとえば、<one of of>要素を使用して、指定されたメタデータの少なくとも1つが任意のパケットに存在する必要があることを表すために、メタデータのリストを指定できます。例は次のとおりです。
<metadataExpected>
<one-of>
<ref>prefixmask</ref>
<ref>prefixlen</ref>
</one-of>
</metadataExpected>
The above example specifies that either the "prefixmask" or the "prefixlen" metadata must be provided with any packet.
上記の例では、「プレフィックスマスク」または「プレフィックス」メタデータのいずれかに任意のパケットを提供する必要があることが指定されています。
The two forms can also be combined, as shown in the following example:
次の例に示すように、2つのフォームを組み合わせることもできます。
<metadataExpected>
<ref>classid</ref>
<ref>vifid</ref>
<ref dependency="optional" defaultValue="0">vrfid</ref>
<one-of>
<ref>prefixmask</ref>
<ref>prefixlen</ref>
</one-of>
</metadataExpected>
Although the schema is constructed to allow even more complex definitions of metadata expectations, we do not discuss those here.
スキーマは、メタデータの期待のさらに複雑な定義を可能にするために構築されていますが、ここでは説明しません。
The optional <outputPorts> element is used to define output ports. An LFB class MAY have zero, one, or more outputs. If the LFB class has no output ports, the <outputPorts> element MUST be omitted. The <outputPorts> element MUST contain one or more <outputPort> elements, one for each port or port group. If there are multiple outputs with the same output type, we model them as an output port group. Some special LFBs have no outputs at all (e.g., Dropper).
オプションの<outputports>要素は、出力ポートを定義するために使用されます。LFBクラスには、ゼロ、1、またはそれ以上の出力がある場合があります。LFBクラスに出力ポートがない場合、<OutputPorts>要素を省略する必要があります。<OutputPorts>要素には、ポートグループまたはポートグループごとに1つ以上の1つ以上の<OutputPort>要素が含まれている必要があります。同じ出力タイプの複数の出力がある場合、それらを出力ポートグループとしてモデル化します。一部の特別なLFBには、出力がまったくありません（ドロッパーなど）。
Single output ports and output port groups are both defined by the <outputPort> element; they are differentiated only by an optional "group" attribute.
単一出力ポートと出力ポートグループは、両方とも<OutputPort>要素によって定義されます。それらは、オプションの「グループ」属性によってのみ区別されます。
The <outputPort> element MUST contain the following elements:
<OutputPort>要素には、次の要素が含まれている必要があります。
o <name> provides the symbolic name of the output. Example: "out". Note that the symbolic name must be unique only within the scope of the LFB class.
o <name>出力のシンボリック名を提供します。例：「out」。シンボリック名は、LFBクラスの範囲内でのみ一意でなければならないことに注意してください。
o <synopsis> contains a brief description of the output port. Example: "Normal packet output".
o <synopsis>出力ポートの簡単な説明が含まれています。例：「通常のパケット出力」。
o <product> lists the allowed frame formats. Example: {"ipv4", "ipv6"}. Note that this list should refer to symbols specified in the <frameDefs> element in the same library document or in any included library documents. The <product> element MAY also contain the list of emitted (generated) metadata. Example: {"classid", "color"}. This list should refer to names of metadata specified in the <metadataDefs> element in the same library document or in any included library documents. For each generated metadatum, it should be specified whether the metadatum is always generated or generated only in certain conditions. This information is important when assessing compatibility between LFBs.
o <product>許可されたフレーム形式をリストします。例：{"ipv4"、 "ipv6"}。このリストは、同じライブラリドキュメントまたは含まれるライブラリドキュメントの<framedefs>要素で指定されたシンボルを参照する必要があることに注意してください。<製品>要素には、放出された（生成された）メタデータのリストも含まれている場合があります。例：{"classId"、 "color"}。このリストは、同じライブラリドキュメントまたは含まれるライブラリドキュメントの<metadatadefs>要素で指定されたメタデータの名前を参照する必要があります。生成された各メタデータについて、メタデータが常に特定の条件でのみ生成されるか、生成されるかどうかを指定する必要があります。この情報は、LFB間の互換性を評価する際に重要です。
In addition, the optional "group" attribute of the <outputPort> element can specify if the port can behave as a port group, i.e., it is allowed to be instantiated. This is indicated by a "true" value (the default value is "false").
さらに、<OutputPort>要素のオプションの「グループ」属性は、ポートがポートグループとして動作できるかどうか、つまりインスタンス化できるかどうかを指定できます。これは、「真の」値（デフォルト値は「false」です）で示されます。
The following example specifies two output ports, the second being an output port group:
次の例では、2つの出力ポートを指定します。2つ目は出力ポートグループです。
<outputPorts>
<outputPort>
<name>out</name>
<synopsis>Normal output</synopsis>
<product>
<frameProduced>
<ref>ipv4</ref>
<ref>ipv4bis</ref>
</frameProduced>
<metadataProduced>
<ref>nhid</ref>
<ref>nhtabid</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="true">
<name>exc</name>
<synopsis>Exception output port group</synopsis>
<product>
<frameProduced>
<ref>ipv4</ref>
<ref>ipv4bis</ref>
</frameProduced>
<metadataProduced>
<ref availability="conditional">errorid</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
The types of frames and metadata the port produces are defined inside the <product> element in each <outputPort>. Within the <product> element, the list of frame types the port produces is listed in the <frameProduced> element. When more than one frame is listed, it means that "one of" these frames will be produced.
ポートが生成するフレームとメタデータの種類は、各<OutputPort>の<製品>要素内で定義されています。<product>要素内で、ポートが生成するフレームタイプのリストは、<frameproduced>要素にリストされています。複数のフレームがリストされている場合、これらのフレームの1つが生成されることを意味します。
The list of metadata that is produced with each packet is listed in the optional <metadataProduced> element of the <product>. In its simplest form, this element can contain a list of <ref> elements, each referring to a metadatum type. The meaning of such a list is that "all of" these metadata are provided with each packet, except those that are listed with the optional "availability" attribute set to "conditional". Similar to the <metadataExpected> element of the <inputPort>, the <metadataProduced> element supports more complex forms, which we do not discuss here further.
各パケットで生成されるメタデータのリストは、<製品>のオプションの<メタデータロード化>要素にリストされています。最も単純な形式では、この要素には<Ref>要素のリストを含めることができます。各要素は、それぞれがメタデータタイプを参照しています。このようなリストの意味は、これらのメタデータの「すべて」が各パケットに提供されていることですが、オプションの「可用性」属性が「条件付き」に設定された属性がリストされているものを除きます。<inuptport>の<metadataexpected>要素と同様に、<metadataproduced>要素はより複雑な形式をサポートしますが、ここではこれ以上説明しません。
Operational parameters of the LFBs that must be visible to the CEs are conceptualized in the model as the LFB components. These include, for example, flags, single parameter arguments, complex arguments, and tables. Note that the components here refer to only those operational parameters of the LFBs that must be visible to the CEs. Other variables that are internal to LFB implementation are not regarded as LFB components and hence are not covered.
CESに見える必要があるLFBの運用パラメーターは、モデルでLFBコンポーネントとして概念化されています。これらには、たとえば、フラグ、単一のパラメーター引数、複雑な引数、および表が含まれます。ここのコンポーネントは、CESに見える必要があるLFBの運用パラメーターのみを指していることに注意してください。LFB実装の内部変数は、LFBコンポーネントとは見なされないため、カバーされません。
Some examples for LFB components are:
LFBコンポーネントのいくつかの例は次のとおりです。
o Configurable flags and switches selecting between operational modes of the LFB
o LFBの動作モードを選択する構成可能なフラグとスイッチ
o Number of inputs or outputs in a port group
o ポートグループの入力または出力の数
o Various configurable lookup tables, including interface tables, prefix tables, classification tables, DSCP mapping tables, MAC address tables, etc.
o インターフェイステーブル、プレフィックステーブル、分類テーブル、DSCPマッピングテーブル、Macアドレステーブルなど、さまざまな構成可能なルックアップテーブル。
o Packet and byte counters
o パケットおよびバイトカウンター
o Various event counters
o さまざまなイベントカウンター
o Number of current inputs or outputs for each input or output group
o 各入力グループまたは出力グループの現在の入力または出力の数
The ForCES model supports the definition of access permission restrictions on what the CE can do with an LFB component. The following categories are supported by the model:
Forceモデルは、CEがLFBコンポーネントで何ができるかについてのアクセス許可制限の定義をサポートしています。次のカテゴリは、モデルによってサポートされています。
o No-access components. This is useful for completeness, and to allow for defining objects that are used by other things, but not directly referencable by the CE. It is also useful for an FE that is reporting that certain defined, and typically accessible, components are not supported for CE access by a reporting FE.
o アクセスなしコンポーネント。これは、完全性に役立ち、他のもので使用されているがCEでは直接参照できないオブジェクトを定義できるようにします。また、特定の定義された、通常はアクセス可能なレポートコンポーネントがCEアクセスのためにサポートされていないことを報告しているFEにも役立ちます。
o Read-only components.
o 読み取り専用コンポーネント。
o Read-write components.
o 読み取りワイトコンポーネント。
o Write-only components. This could be any configurable data for which read capability is not provided to the CEs (e.g., the security key information).
o 書き込み専用コンポーネント。これは、CESに読み取り機能が提供されない構成可能なデータ（セキュリティキー情報など）である可能性があります。
o Read-reset components. The CE can read and reset this resource, but cannot set it to an arbitrary value. Example: Counters.
o 読み取り - リセットコンポーネント。CEはこのリソースを読み取り、リセットできますが、任意の価値に設定することはできません。例：カウンター。
o Firing-only components. A write attempt to this resource will trigger some specific actions in the LFB, but the actual value written is ignored.
o 発射のみのコンポーネント。このリソースに対する書き込みの試みは、LFBでいくつかの特定のアクションをトリガーしますが、実際の値は無視されます。
The LFB class MUST define only one possible access mode for a given component.
LFBクラスは、特定のコンポーネントに対して1つの可能なアクセスモードのみを定義する必要があります。
The components of the LFB class are listed in the <components> element. Each component is defined by an <component> element. A <component> element contains some or all of the following elements, some of which are mandatory:
LFBクラスのコンポーネントは、<components>要素にリストされています。各コンポーネントは、<コンポーネント>要素によって定義されます。<コンポーネント>要素には、次の要素の一部またはすべてが含まれていますが、その一部は必須です。
o <name> MUST occur, and defines the name of the component. This name must be unique among the components of the LFB class. Example: "version".
o <name>発生する必要があり、コンポーネントの名前を定義します。この名前は、LFBクラスのコンポーネントの中で一意でなければなりません。例：「バージョン」。
o <synopsis> is also mandatory, and provides a brief description of the purpose of the component.
o <synopsis>も必須であり、コンポーネントの目的の簡単な説明を提供します。
o <optional/> is an optional element, and if present indicates that this component is optional.
o <optional/>はオプションの要素であり、存在する場合、このコンポーネントがオプションであることを示します。
o The data type of the component can be defined either via a reference to a predefined data type or by providing a local definition of the type. The former is provided by using the <typeRef> element, which must refer to the unique name of an existing data type defined in the <dataTypeDefs> element in the same library document or in any of the included library documents. When the data type is defined locally (unnamed type), one of the following elements can be used: <atomic>, <array>, <struct>, or <union>. Their usage is identical to how they are used inside <dataTypeDef> elements (see Section 4.5). Some form of data type definition MUST be included in the component definition.
o コンポーネントのデータ型は、事前定義されたデータ型への参照を介して、またはタイプのローカル定義を提供することにより定義できます。前者は、同じライブラリドキュメントまたは付属のライブラリドキュメントのいずれかで<dataTypeDefs>要素で定義されている既存のデータ型の一意の名前を参照する必要があります。データ型がローカルで定義されている場合（名前のないタイプ）、次の要素のいずれかを使用できます：<Atomic>、<Array>、<struct>、または<Union>。それらの使用法は、<dataTypedef>要素内での使用方法と同じです（セクション4.5を参照）。コンポーネント定義に何らかの形式のデータ型定義を含める必要があります。
o The <defaultValue> element is optional, and if present is used to specify a default value for a component. If a default value is specified, the FE must ensure that the component has that value when the LFB is initialized or reset. If a default value is not specified for a component, the CE MUST make no assumptions as to what the value of the component will be upon initialization. The CE must either read the value or set the value, if it needs to know what it is.
o <DefaultValue>要素はオプションであり、存在する場合はコンポーネントのデフォルト値を指定するために使用されます。デフォルト値が指定されている場合、FEは、LFBが初期化またはリセットされたときにコンポーネントがその値を確保することを確認する必要があります。コンポーネントにデフォルト値が指定されていない場合、CEは、初期化時にコンポーネントの値が何であるかについて仮定してはなりません。CEは、値を読み取るか、値を設定する必要があります。
o The <description> element MAY also appear. If included, it provides a longer description of the meaning or usage of the particular component being defined.
o <説明>要素も表示される場合があります。含まれている場合、定義されている特定のコンポーネントの意味または使用法の長い説明を提供します。
The <component> element also MUST have a componentID attribute, which is a numeric value used by the ForCES protocol.
<component>要素には、力プロトコルで使用される数値であるコンポーネント属性も必要です。
In addition to the above elements, the <component> element includes an optional "access" attribute, which can take any of the following values: "read-only", "read-write", "write-only", "read-reset", and "trigger-only". The default access mode is "read-write".
上記の要素に加えて、<component>要素には、「読み取り専用」、「読み取りワイト」、「書き込みのみ」、「読み取り」、次の値のいずれかをとることができるオプションの「アクセス」属性が含まれています。リセット "、および「トリガーのみ」。デフォルトのアクセスモードは「Read-Write」です。
Whether optional components are supported, and whether components defined as read-write can actually be written, can be determined for a given LFB instance by the CE by reading the property information of that component. An access control setting of "trigger-only" means that this component is included only for use in event detection.
オプションのコンポーネントがサポートされているかどうか、およびread-writeとして定義されたコンポーネントを実際に記述できるかどうかは、そのコンポーネントのプロパティ情報を読み取ることにより、CEによって特定のLFBインスタンスについて決定できます。「トリガーのみ」のアクセス制御設定は、このコンポーネントがイベント検出でのみ使用するために含まれることを意味します。
The following example defines two components for an LFB:
次の例では、LFBの2つのコンポーネントを定義します。
<components>
<component access="read-only" componentID="1">
<name>foo</name>
<synopsis>number of things</synopsis>
<typeRef>uint32</typeRef>
</component>
<component access="read-write" componentID="2">
<name>bar</name>
<synopsis>number of this other thing</synopsis>
<atomic>
<baseType>uint32</baseType>
<rangeRestriction>
<allowedRange min="10" max="2000"/>
</rangeRestriction>
</atomic>
<defaultValue>10</defaultValue>
</component>
</components>
The first component ("foo") is a read-only 32-bit unsigned integer, defined by referring to the built-in "uint32" atomic type. The second component ("bar") is also an integer, but uses the <atomic> element to provide additional range restrictions. This component has access mode of read-write allowing it to be both read and written. A default value of 10 is provided for bar. Although the access for bar is read-write, some implementations MAY offer only more restrictive access, and this would be reported in the component properties.
最初のコンポーネント（ "foo"）は、内蔵の「uint32」アトミックタイプを参照することで定義される読み取り専用の32ビットの符号なし整数です。2番目のコンポーネント（ "bar"）も整数ですが、<原子>要素を使用して追加の範囲制限を提供します。このコンポーネントには、読み取りワイトのアクセスモードがあり、読み取りと書き込みの両方を可能にします。BARには10のデフォルト値が提供されます。BARのアクセスは読み取りワイトですが、一部の実装はより制限的なアクセスのみを提供する場合があり、これはコンポーネントプロパティで報告されます。
Note that not all components are likely to exist at all times in a particular implementation. While the capabilities will frequently indicate this non-existence, CEs may attempt to reference non-existent or non-permitted components anyway. The ForCES protocol mechanisms should include appropriate error indicators for this case.
特定の実装では、すべてのコンポーネントが常に存在する可能性が高いわけではないことに注意してください。機能は頻繁にこの非存在を示しますが、CESはとにかく存在しないコンポーネントまたは浸透していないコンポーネントを参照しようとする場合があります。力プロトコルメカニズムには、この場合の適切なエラーインジケーターを含める必要があります。
The mechanism defined above for non-supported components can also apply to attempts to reference non-existent array elements or to set read-only components.
サポートされていないコンポーネントに対して上記で定義されたメカニズムは、存在しないアレイ要素を参照したり、読み取り専用コンポーネントを設定したりする試みにも適用できます。
The LFB class specification provides some flexibility for the FE implementation regarding how the LFB class is implemented. For example, the instance may have some limitations that are not inherent from the class definition, but rather the result of some implementation limitations. Some of these limitations are captured by the property information of the LFB components. The model allows for the notion of additional capability information.
LFBクラスの仕様は、LFBクラスの実装方法に関するFE実装の柔軟性を提供します。たとえば、インスタンスには、クラスの定義から固有のものではなく、いくつかの実装の制限の結果であるいくつかの制限がある場合があります。これらの制限のいくつかは、LFBコンポーネントのプロパティ情報によってキャプチャされます。このモデルにより、追加の機能情報の概念が可能になります。
Such capability-related information is expressed by the capability components of the LFB class. The capability components are always read-only attributes, and they are listed in a separate <capabilities> element in the <LFBClassDef>. The <capabilities> element contains one or more <capability> elements, each defining one capability component. The format of the <capability> element is almost the same as the <component> element. It differs in two aspects: it lacks the access mode attribute (because it is always read-only), and it lacks the <defaultValue> element (because default value is not applicable to read-only attributes).
このような機能関連情報は、LFBクラスの機能コンポーネントによって表されます。機能コンポーネントは常に読み取り専用属性であり、<lfbclassdef>の個別の<機能>要素にリストされています。<機能>要素には、それぞれが1つの機能コンポーネントを定義する1つ以上の<機能>要素が含まれています。<capabity>要素の形式は、<component>要素とほぼ同じです。2つの側面が異なります。アクセスモード属性がない（常に読み取り専用であるため）、<DefaultValue>要素（デフォルト値が読み取り専用属性に適用されないため）がありません。
Some examples of capability components follow:
機能コンポーネントのいくつかの例が次のとおりです。
o The version of the LFB class with which this LFB instance complies
o このLFBインスタンスが準拠しているLFBクラスのバージョン
o Supported optional features of the LFB class
o LFBクラスのオプション機能をサポートしています
o Maximum number of configurable outputs for an output group
o 出力グループの構成可能な出力の最大数
o Metadata pass-through limitations of the LFB
o LFBのメタデータパススルー制限
o Additional range restriction on operational components The following example lists two capability attributes:
o 運用コンポーネントの追加範囲制限次の例には、2つの機能属性を示します。
<capabilities>
<capability componentID="3">
<name>version</name>
<synopsis>
LFB class version this instance is compliant with.
</synopsis>
<typeRef>version</typeRef>
</capability>
<capability componentID="4">
<name>limitBar</name>
<synopsis>
Maximum value of the "bar" attribute.
</synopsis>
<typeRef>uint16</typeRef>
</capability>
</capabilities>
The <events> element contains the information about the occurrences for which instances of this LFB class can generate notifications to the CE. High-level view on the declaration and operation of LFB events is described in Section 3.2.5.
<Events>要素には、このLFBクラスのインスタンスがCEに通知を生成できる発生に関する情報が含まれています。LFBイベントの宣言と運用に関する高レベルのビューについては、セクション3.2.5で説明しています。
The <events> element contains 0 or more <event> elements, each of which declares a single event. The <event> element has an eventID attribute giving the unique (per LFB class) ID of the event. The element will include:
<tevents>要素には0つ以上の<Event>要素が含まれており、それぞれが単一のイベントを宣言します。<Event>要素には、イベントの一意の（LFBクラスごとの）IDを与えるeventID属性があります。要素には次のものが含まれます。
o <eventTarget> element indicating which LFB field (component) is tested to generate the event.
o <EventTarget>イベントを生成するためにどのLFBフィールド（コンポーネント）がテストされているかを示す要素。
o <condition> element indicating what condition on the field will generate the event from a list of defined conditions.
o <condition>フィールド上のどの条件が定義された条件のリストからイベントを生成するかを示す要素。
o <eventReports> element indicating what values are to be reported in the notification of the event.
o <EventReports>イベントの通知で報告される値を示す要素。
The example below demonstrates the different constructs.
以下の例は、さまざまな構成要素を示しています。
The <events> element has a baseID attribute value, which is normally <events baseID="number">. The value of the baseID is the starting componentID for the path that identifies events. It must not be the same as the componentID of any top-level components (including capabilities) of the LFB class. In derived LFBs (i.e., ones with a <derivedFrom> element) where the parent LFB class has an events declaration, the baseID must not be present in the derived LFB <events> element. Instead, the baseID value from the parent LFB class is used. In the example shown, the baseID is 7.
<events>要素には、baseID属性値があります。これは通常、<events baseid = "number">です。BaseIDの値は、イベントを識別するパスの開始コンポーネントです。LFBクラスのトップレベルコンポーネント（機能を含む）のコンポーネントと同じであってはなりません。親LFBクラスにイベント宣言がある場合、派生したLFB（つまり、<derivedfrom>要素を持つもの）では、派生したLFB <Events>要素にBaseIDが存在してはなりません。代わりに、親LFBクラスのBaseID値が使用されます。示されている例では、BaseIDは7です。
<events baseID="7">
<event eventID="7">
<name>Foochanged</name>
<synopsis>
An example event for a scalar
</synopsis>
<eventTarget>
<eventField>foo</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<!-- report the new state -->
<eventReport>
<eventField>foo</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="8">
<name>Goof1changed</name>
<synopsis>
An example event for a complex structure
</synopsis>
<eventTarget>
<!-- target is goo.f1 -->
<eventField>goo</eventField>
<eventField>f1</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<!-- report the new state of goo.f1 -->
<eventReport>
<eventField>goo</eventField>
<eventField>f1</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="9">
<name>NewbarEntry</name>
<synopsis>
Event for a new entry created on table bar
</synopsis>
<eventTarget>
<eventField>bar</eventField>
<eventSubscript>_barIndex_</eventSubscript>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>bar</eventField>
<eventSubscript>_barIndex_</eventSubscript>
</eventReport>
<eventReport>
<eventField>foo</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="10">
<name>Gah11changed</name>
<synopsis>
Event for table gah, entry index 11 changing
</synopsis>
<eventTarget>
<eventField>gah</eventField>
<eventSubscript>11</eventSubscript>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>gah</eventField>
<eventSubscript>11</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="11">
<name>Gah10field1</name>
<synopsis>
Event for table gah, entry index 10, column field1 changing
</synopsis>
<eventTarget>
<eventField>gah</eventField>
<eventSubscript>10</eventSubscript>
<eventField>field1</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>gah</eventField>
<eventSubscript>10</eventSubscript>
</eventReport>
</eventReports>
</event>
</events>
The <eventTarget> element contains information identifying a field in the LFB that is to be monitored for events.
<EventTarget>要素には、イベントを監視するLFBのフィールドを識別する情報が含まれています。
The <eventTarget> element contains one or more <eventField>s each of which MAY be followed by one or more <eventSubscript> elements. Each of these two elements represents the textual equivalent of a path select component of the LFB.
<EventTarget>要素には、それぞれ1つ以上の<EventField>が含まれ、その後に1つ以上の<EventSubscript>要素が続く場合があります。これらの2つの要素はそれぞれ、LFBのパス選択コンポーネントに相当するテキストを表します。
The <eventField> element contains the name of a component in the LFB or a component nested in an array or structure within the LFB. The name used in <eventField> MUST identify a valid component within the containing LFB context. The first element in an <eventTarget> MUST be an <eventField> element. In the example shown, four LFB components foo, goo, bar, and gah are used as <eventField>s.
<EventField>要素には、LFBのコンポーネントの名前またはLFB内の配列または構造にネストされたコンポーネントの名前が含まれています。<EventField>で使用される名前は、含有LFBコンテキスト内の有効なコンポーネントを識別する必要があります。<EventTarget>の最初の要素は、<EventField>要素でなければなりません。示されている例では、4つのLFBコンポーネントfoo、goo、bar、およびgahが<eventfield> sとして使用されます。
In the simple case, an <eventField> identifies an atomic component. This is the case illustrated in the event named Foochanged. <eventField> is also used to address complex components such as arrays or structures.
簡単な場合、<EventField>は原子成分を識別します。これは、FooChangedという名前のイベントに示されているケースです。<EventField>は、配列や構造などの複雑なコンポーネントに対処するためにも使用されます。
The first defined event, Foochanged, demonstrates how a scalar LFB component, foo, could be monitored to trigger an event.
最初に定義されたイベントであるFooChangedは、スカラーLFBコンポーネントのFOOを監視してイベントをトリガーする方法を示しています。
The second event, Goof1changed, demonstrates how a member of the complex structure goo could be monitored to trigger an event.
2番目のイベントであるGoof1Changedは、複雑な構造Gooのメンバーを監視してイベントをトリガーする方法を示しています。
The events named NewbarEntry, Gah11changed, and Gah10field1 represent monitoring of arrays bar and gah in differing details.
Newbarentry、Gah11Changed、およびGah10Field1という名前のイベントは、アレイバーとGAHの監視を異なる詳細で表しています。
If an <eventField> identifies a complex component, then a further <eventField> MAY be used to refine the path to the target element. Defined event Goof1changed demonstrates how a second <eventField> is used to point to member f1 of the structure goo.
<EventField>が複雑なコンポーネントを識別する場合、さらに<EventField>を使用してターゲット要素へのパスを改良することができます。定義されたイベントGoof1Changedは、2番目の<EventField>が構造GooのメンバーF1を指す方法を示しています。
If an <eventField> identifies an array, then the following rules apply:
<EventField>が配列を識別する場合、次のルールが適用されます。
o <eventSubscript> elements MUST be present as the next XML element after an <eventField> that identifies an array component. <eventSubscript> MUST NOT occur other than after an array reference, as it is only meaningful in that context.
o <EventSubscript>要素は、配列コンポーネントを識別する<EventField>の後に次のXML要素として存在する必要があります。<EventSubscript>は、そのコンテキストでのみ意味があるため、配列参照後以外に発生してはなりません。
o An <eventSubscript> contains either:
o <eventsubscript>には次のいずれかが含まれます。
* A numeric value to indicate that the event applies to a specific entry (by index) of the array. As an example, event Gah11changed shows how table gah's index 11 is being targeted for monitoring.
* イベントが配列の特定のエントリ（インデックス別）に適用されることを示す数値。例として、イベントGAH11Changedは、テーブルGAHのインデックス11が監視のターゲットを絞っていることを示しています。
Or
また
* It is expected that the more common usage is to have the event being defined across all elements of the array (i.e., a wildcard for all indices). In that case, the value of the <eventSubscript> MUST be a name rather than a numeric value. That same name can then be used as the value of <eventSubscript> in <eventReport> elements as described below. An example of a wild card table index is shown in event NewBarentry where the <eventSubscript> value is named _barIndex_
* より一般的な使用法は、アレイのすべての要素（つまり、すべてのインデックスのワイルドカード）でイベントを定義することであると予想されます。その場合、<eventsubscript>の値は、数値ではなく名前でなければなりません。その名前は、以下に説明するように、<EventSubscript>の<EventSubscript>の値として使用できます。ワイルドカードテーブルインデックスの例は、<EventSubscript>値が_Barindex_という名前のNewBarentryの場合に示されています。
o An <eventField> MAY follow an <eventSubscript> to further refine the path to the target element. (Note: this is in the same spirit as the case where <eventField> is used to further refine <eventField> in the earlier example of a complex structure example of Goof1changed.) The example event Gah10field1 illustrates how the column field1 of table gah is monitored for changes.
o <EventField>は、<EventSubscript>に従って、ターゲット要素へのパスをさらに改善することができます。（注：これは、Goof1Changedの複雑な構造例の以前の例で<EventField>をさらに洗練するために<EventField>が使用される場合と同じ精神です。）イベントGAH10FIELD1の例は、テーブルGAHの列フィールド1がどのようになっているかを示しています。変更について監視されています。
It should be emphasized that the name in an <eventSubscript> element in defined event NewbarEntry is not a component name. It is a variable name for use in the <eventReport> elements (described in Section 4.7.6.3) of the given LFB definition. This name MUST be distinct from any component name that can validly occur in the <eventReport> clause.
定義されたイベントNewBarentryの<eventsubscript>要素の名前はコンポーネント名ではないことを強調する必要があります。これは、指定されたLFB定義の<EventReport>要素（セクション4.7.6.3で説明）で使用するための変数名です。この名前は、<EventReport>句で有効に発生する可能性のあるコンポーネント名とは異なる必要があります。
The event condition element represents a condition that triggers a notification. The list of conditions is:
イベント条件要素は、通知をトリガーする条件を表します。条件のリストは次のとおりです。
<eventCreated/>: The target must be an array, ending with a subscript indication. The event is generated when an entry in the array is created. This occurs even if the entry is created by CE direction. The event example NewbarEntry demonstrates the <eventCreated/> condition.
<eventCreated/>：ターゲットはアレイでなければならず、添え字表示で終わります。アレイ内のエントリが作成されると、イベントが生成されます。これは、エントリがCE方向によって作成されている場合でも発生します。イベントの例NewBarentryは、<eventCreated/>>条件を示しています。
<eventDeleted/>: The target must be an array, ending with a subscript indication. The event is generated when an entry in the array is destroyed. This occurs even if the entry is destroyed by CE direction.
<eventDeleted/>：ターゲットはアレイでなければならず、添え字表示で終わります。このイベントは、配列のエントリが破壊されたときに生成されます。これは、エントリがCE方向によって破壊されたとしても発生します。
<eventChanged/>: The event is generated whenever the target component changes in any way. For binary components such as up/down, this reflects a change in state. It can also be used with numeric attributes, in which case any change in value results in a detected trigger. Event examples Foochanged, Gah11changed, and Gah10field1 illustrate the <eventChanged/> condition.
<eventChanged/>：ターゲットコンポーネントが何らかの方法で変更されるたびにイベントが生成されます。アップ/ダウンなどのバイナリコンポーネントの場合、これは状態の変化を反映しています。また、数値属性で使用することもできます。その場合、値の変更は検出されたトリガーになります。イベントの例は、foochanged、gah11changed、およびgah10field1が<eventChanged/>>>>を示しています。
<eventGreaterThan/>: The event is generated whenever the target component becomes greater than the threshold. The threshold is an event property.
<eventGreaterthan/>：ターゲットコンポーネントがしきい値より大きくなると、イベントが生成されます。しきい値はイベントプロパティです。
<eventLessThan/>: The event is generated whenever the target component becomes less than the threshold. The threshold is an event property.
<eventlessthan/>：ターゲットコンポーネントがしきい値よりも少なくなると、イベントが生成されます。しきい値はイベントプロパティです。
The <eventReports> element of an <event> declares the information to be delivered by the FE along with the notification of the occurrence of the event.
<EventReports> <Event>の要素は、イベントの発生の通知とともに、FEによって配信される情報を宣言します。
The <eventReports> element contains one or more <eventReport> elements. Each <eventReport> element identifies a piece of data from the LFB class to be reported. The notification carries that data as if the collection of <eventReport> elements had been defined in a structure. The syntax is exactly the same as used in the <eventTarget> element, using <eventField> and <eventSubscript> elements, and so the same rules apply. Each <eventReport> element thus MUST identify a component in the LFB class. <eventSubcript> MAY contain integers. If they contain names, they MUST be names from <eventSubscript> elements of the <eventTarget> in the event. The selection for the report will use the value for the subscript that identifies that specific element triggering the event. This can be used to reference the component causing the event, or to reference related information in parallel tables.
<EventReports>要素には、1つ以上の<EventRePort>要素が含まれています。各<EventReport>要素は、報告されるLFBクラスのデータの一部を識別します。通知には、<EventReport>要素のコレクションが構造内で定義されているかのようにデータが含まれています。構文は、<EventTarget>要素で使用されているものとまったく同じで、<EventField>および<EventSubscript>要素を使用しているため、同じルールが適用されます。したがって、各<EventReport>要素は、LFBクラスのコンポーネントを識別する必要があります。<eventsubcript>には整数が含まれている場合があります。名前が含まれている場合、イベントの<EventSubscript> <EventTarget>の要素の名前でなければなりません。レポートの選択は、イベントをトリガーする特定の要素を識別する添え字の値を使用します。これを使用して、イベントを引き起こすコンポーネントを参照したり、並列テーブルで関連情報を参照することもできます。
In the example shown, in the case of the event Foochanged, the report will carry the value of foo. In the case of the defined event NewbarEntry acting on LFB component bar, which is an array, there are two items that are reported as indicated by the two <eventReport> declarations:
示されている例では、イベントの場合、レポートにはFOOの価値があります。アレイであるLFBコンポーネントバーに作用する定義されたイベントNewBarentryの場合、2つの<EventReport>宣言で示されているように報告される2つの項目があります。
o The first <eventReport> details what new entry was added in the table bar. Recall that _barIndex_ is declared as the event's <eventTarget> <eventSubcript> and that by virtue of using a name instead of a numeric value, the <eventSubcript> is implied to be a wildcard and will carry whatever index of the new entry.
o 最初の<EventReport>は、テーブルバーに追加された新しいエントリを詳述しています。_Barindex_はイベントの<EventTarget> <EventSubcript>として宣言され、数値の代わりに名前を使用することにより、<EventSubcript>はワイルドカードであると暗示されており、新しいエントリのインデックスを運ぶことを思い出してください。
o The second <eventReport> includes the value of LFB component foo at the time the new entry was created in bar. Reporting foo in this case is provided to demonstrate the flexibility of event reporting.
o 2番目の<EventReport>には、新しいエントリがBARで作成された時点でのLFBコンポーネントFOOの値が含まれています。この場合のFOOのレポートは、イベントレポートの柔軟性を実証するために提供されます。
This event reporting structure is designed to allow the LFB designer to specify information that is likely not known a priori by the CE and is likely needed by the CE to process the event. While the structure allows for pointing at large blocks of information (full arrays or complex structures), this is not recommended. Also, the variable reference/subscripting in reporting only captures a small portion of the kinds of related information. Chaining through index fields stored in a table, for example, is not supported. In general, the <eventReports> mechanism is an optimization for cases that have been found to be common, saving the CE from having to query for information it needs to understand the event. It does not represent all possible information needs.
このイベントレポート構造は、LFB設計者がCEで先験的に不明でない可能性が高く、イベントを処理するためにCEが必要とする可能性が高い情報を指定できるように設計されています。構造により、情報の大きなブロック（完全な配列または複雑な構造）を指すことはできますが、これは推奨されません。また、レポートの変数参照/サブスクリップは、関連情報の種類のごく一部のみをキャプチャします。たとえば、テーブルに保存されているインデックスフィールドを介してチェーンはサポートされていません。一般に、<EventReports>メカニズムは、一般的であることがわかったケースの最適化であり、CEがイベントを理解するために必要な情報をクエリする必要がないことを節約します。すべての可能な情報ニーズを表すわけではありません。
If any components referenced by the eventReport are optional, then the report MUST use a protocol format that supports optional elements and allows for the non-existence of such elements. Any components that do not exist are not reported.
EventReportで参照されるコンポーネントがオプションである場合、レポートはオプションの要素をサポートし、そのような要素を存在させるプロトコル形式を使用する必要があります。存在しないコンポーネントは報告されていません。
The high-level view of the declaration and operation of LFB events is described in Section 3.2.5.
LFBイベントの宣言と運用の高レベルのビューについては、セクション3.2.5で説明しています。
The <eventTarget> provides additional components used in the path to reference the event. The path constitutes the baseID for events, followed by the ID for the specific event, followed by a value for each <eventSubscript> element if it exists in the <eventTarget>.
<EventTarget>は、イベントを参照するためにパスで使用される追加のコンポーネントを提供します。パスはイベントのBaseIDを構成し、その後、特定のイベントのIDが続き、<EventTarget>に存在する場合は<EventSubscript>要素ごとに値が続きます。
The event path will uniquely identify a specific occurrence of the event in the event notification to the CE. In the example provided above, at the end of Section 4.7.6, a notification with path of 7.7 uniquely identifies the event to be that caused by the change of foo; an event with path 7.9.100 uniquely identifies the event to be that caused by a creation of table bar entry with index/subscript 100.
イベントパスは、CEへのイベント通知でイベントの特定の発生を一意に識別します。上記の例では、セクション4.7.6の最後に、7.7のパスを持つ通知が、FOOの変更によって引き起こされるイベントと一意に識別されます。パス7.9.100のイベントは、インデックス/サブスクリプト100を備えたテーブルバーエントリの作成によって引き起こされるイベントを一意に識別します。
As described in Section 4.8.5, event elements have properties associated with them. These properties include the subscription information indicating whether the CE wishes the FE to generate event reports for the event at all, thresholds for events related to level crossing, and filtering conditions that may reduce the set of event notifications generated by the FE. Details of the filtering conditions that can be applied are given in that section. The filtering conditions allow the FE to suppress floods of events that could result from oscillation around a condition value. For FEs that do not wish to support filtering, the filter properties can be either read-only or not supported.
セクション4.8.5で説明されているように、イベント要素にはそれらに関連付けられたプロパティがあります。これらのプロパティには、CEがFEがイベントのイベントレポートを生成することを望んでいるかどうかを示すサブスクリプション情報、レベルの交差に関連するイベントのしきい値、およびFEによって生成されるイベント通知のセットを減らす可能性のあるフィルタリング条件が含まれます。適用できるフィルタリング条件の詳細については、そのセクションに記載されています。フィルタリング条件により、FEは条件値の周りの振動から生じる可能性のあるイベントの洪水を抑制することができます。フィルタリングをサポートしたくないFESの場合、フィルタープロパティは読み取り専用またはサポートされていない場合があります。
In addition to identifying the event sources, the CE also uses the event path to activate runtime control of the event via the event properties (defined in Section 4.8.5) utilizing SET-PROP as defined in the ForCES protocol [RFC5810] operation.
イベントソースの識別に加えて、CEはイベントパスを使用して、イベントプロパティ（セクション4.8.5で定義されている）を介してイベントのランタイム制御をアクティブにします（セクション4.8.5で定義）。
To activate event generation on the FE, a SET-PROP message referencing the event and registration property of the event is issued to the FE by the CE with any prefix of the path of the event. So, for an event defined on the example table bar, a SET-PROP with a path of 7.9 will subscribe the CE to all occurrences of that event on any entry of the table. This is particularly useful for the <eventCreated/> and <eventDestroyed/> conditions on tables. Events using those conditions will generally be defined with a field/ subscript sequence that identifies an array and ends with an <eventSubscript> element. Thus, the event notification will indicate which array entry has been created or destroyed. A typical subscriber will subscribe for the array, as opposed to a specific entry in an array, so it will use a shorter path.
FEでイベント生成をアクティブにするために、イベントのイベントと登録プロパティを参照するセットプロップメッセージが、イベントのパスの任意のプレフィックスを使用してCEによってFEに発行されます。したがって、サンプルテーブルバーで定義されているイベントの場合、7.9のパスを持つセットプロップは、テーブルのエントリでそのイベントのすべての発生にCEをサブスクライブします。これは、テーブル上の<eventCreated/>および<eventDestroyed/>>>> <eventDestroyed/>に特に役立ちます。これらの条件を使用したイベントは、通常、配列を識別し、<EventSubscript>要素で終了するフィールド/サブスクリプトシーケンスで定義されます。したがって、イベント通知は、どの配列エントリが作成または破壊されたかを示します。典型的なサブスクライバーは、配列内の特定のエントリとは対照的に、アレイを購読するため、より短いパスを使用します。
In the example provided, subscribing to 7.8 implies receiving all declared events from table bar. Subscribing to 7.8.100 implies receiving an event when subscript/index 100 table entry is created.
提供されている例では、7.8を購読することは、テーブルバーから宣言されたすべてのイベントを受信することを意味します。7.8.100を購読することは、添え字/インデックス100テーブルエントリが作成されたときにイベントを受信することを意味します。
Threshold and filtering conditions can only be applied to individual events. For events defined on elements of an array, this specification does not allow for defining a threshold or filtering condition on an event for all elements of an array.
しきい値とフィルタリング条件は、個々のイベントにのみ適用できます。配列の要素で定義されたイベントの場合、この仕様では、配列のすべての要素のイベントのしきい値またはフィルタリング条件を定義することはできません。
The <description> element of the <LFBClass> provides unstructured text (in XML sense) to explain what the LFB does to a human user.
<lfbclass>の<説明>要素は、LFBが人間のユーザーに何をするかを説明するために、構造化されていないテキスト（XMLの意味）を提供します。
Components of LFBs have properties that are important to the CE. The most important property is the existence / readability / writeability of the element. Depending on the type of the component, other information may be of importance.
LFBのコンポーネントには、CEにとって重要な特性があります。最も重要な特性は、要素の存在 /読みやすさ /書き込み性です。コンポーネントのタイプに応じて、他の情報が重要になる場合があります。
The model provides the definition of the structure of property information. There is a base class of property information. For the array, alias, and event components, there are subclasses of property information providing additional fields. This information is accessed by the CE (and updated where applicable) via the ForCES protocol. While some property information is writeable, there is no mechanism currently provided for checking the properties of a property element. Writeability can only be checked by attempting to modify the value.
このモデルは、プロパティ情報の構造の定義を提供します。プロパティ情報の基本クラスがあります。配列、エイリアス、イベントコンポーネントには、追加のフィールドを提供するプロパティ情報のサブクラスがあります。この情報は、Force Protocolを介してCEから（および該当する場合は更新）によってアクセスされます。一部のプロパティ情報は書き込み可能ですが、プロパティ要素のプロパティをチェックするために現在提供されているメカニズムはありません。writeabilityは、値を変更しようとすることによってのみチェックできます。
The basic property definition, along with the scalar dataTypeDef for accessibility, is below. Note that this access permission information is generally read-only.
基本的なプロパティ定義は、アクセシビリティのためのScalar DatatypeDEFとともに、以下です。このアクセス許可情報は通常、読み取り専用であることに注意してください。
<dataTypeDef>
<name>accessPermissionValues</name>
<synopsis>
The possible values of component access permission
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>None</name>
<synopsis>Access is prohibited</synopsis>
</specialValue>
<specialValue value="1">
<name> Read-Only </name>
<synopsis>
Access to the component is read only
</synopsis>
</specialValue>
<specialValue value="2">
<name>Write-Only</name>
<synopsis>
The component MAY be written, but not read
</synopsis>
</specialValue>
<specialValue value="3">
<name>Read-Write</name>
<synopsis>
The component MAY be read or written
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>baseElementProperties</name>
<synopsis>basic properties, accessibility</synopsis>
<struct>
<component componentID="1">
<name>accessibility</name>
<synopsis>
does the component exist, and
can it be read or written
</synopsis>
<typeRef>accessPermissionValues</typeRef>
</component>
</struct>
</dataTypeDef>
The properties for an array add a number of important pieces of information. These properties are also read-only.
配列のプロパティは、多くの重要な情報を追加します。これらのプロパティも読み取り専用です。
<dataTypeDef>
<name>arrayElementProperties</name>
<synopsis>Array Element Properties definition</synopsis>
<struct>
<derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2">
<name>entryCount</name>
<synopsis>the number of entries in the array</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>highestUsedSubscript</name>
<synopsis>the last used subscript in the array</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>firstUnusedSubscript</name>
<synopsis>
The subscript of the first unused array element
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
The properties of a string specify the actual octet length and the maximum octet length for the element. The maximum length is included because an FE implementation MAY limit a string to be shorter than the limit in the LFB class definition.
文字列のプロパティは、実際のオクテットの長さと要素の最大オクテット長を指定します。FEの実装により、文字列がLFBクラス定義の制限よりも短く制限される可能性があるため、最大長が含まれています。
<dataTypeDef>
<name>stringElementProperties</name>
<synopsis>string Element Properties definition </synopsis>
<struct>
<derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2">
<name>stringLength</name>
<synopsis>the number of octets in the string</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>maxStringLength</name>
<synopsis>
the maximum number of octets in the string
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
The properties of an octetstring specify the actual length and the maximum length, since the FE implementation MAY limit an octetstring to be shorter than the LFB class definition.
OctetStringのプロパティは、FEの実装ではOctetStringがLFBクラスの定義よりも短くなることを制限する可能性があるため、実際の長さと最大長を指定します。
<dataTypeDef>
<name>octetstringElementProperties</name>
<synopsis>octetstring Element Properties definition
</synopsis>
<struct>
<derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2">
<name>octetstringLength</name>
<synopsis>
the number of octets in the octetstring
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>maxOctetstringLength</name>
<synopsis>
the maximum number of octets in the octetstring
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
The properties for an event add three (usually) writeable fields. One is the subscription field. 0 means no notification is generated. Any non-zero value (typically 1 is used) means that a notification is generated. The hysteresis field is used to suppress generation of notifications for oscillations around a condition value, and is described below (Section 4.8.5.2). The threshold field is used for the <eventGreaterThan/> and <eventLessThan/> conditions. It indicates the value to compare the event target against. Using the properties allows the CE to set the level of interest. FEs that do not support setting the threshold for events will make this field read-only.
イベントのプロパティは、3つの（通常）書き込み可能なフィールドを追加します。1つはサブスクリプションフィールドです。0は、通知が生成されないことを意味します。ゼロ以外の値（通常1が使用されます）は、通知が生成されることを意味します。ヒステリシスフィールドは、条件値に関する振動の通知の生成を抑制するために使用され、以下に説明します（セクション4.8.5.2）。しきい値フィールドは、<eventgreaterthan/>および<eventlessthan/>条件に使用されます。イベントのターゲットを比較する値を示します。プロパティを使用すると、CEが関心のあるレベルを設定できます。イベントのしきい値の設定をサポートしていないFESは、このフィールドに読み取り専用になります。
<dataTypeDef>
<name>eventElementProperties</name>
<synopsis>event Element Properties definition</synopsis>
<struct>
<derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2">
<name>registration</name>
<synopsis>
has the CE registered to be notified of this event
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>threshold</name>
<synopsis> comparison value for level crossing events
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>eventHysteresis</name>
<synopsis> region to suppress event recurrence notices
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name>eventCount</name>
<synopsis> number of occurrences to suppress
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="6">
<name>eventInterval</name>
<synopsis> time interval in ms between notifications
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
The event properties have values for controlling several filter conditions. Support of these conditions is optional, but all conditions SHOULD be supported. Events that are reliably known not to be subject to rapid occurrence or other concerns MAY not support all filter conditions.
イベントプロパティには、いくつかのフィルター条件を制御する値があります。これらの条件のサポートはオプションですが、すべての条件をサポートする必要があります。迅速な発生やその他の懸念の対象ではないことが確実に知られているイベントは、すべてのフィルター条件をサポートしない場合があります。
Currently, three different filter condition variables are defined. These are eventCount, eventInterval, and eventHysteresis. Setting the condition variables to 0 (their default value) means that the condition is not checked.
現在、3つの異なるフィルター条件変数が定義されています。これらは、EventCount、EventInterval、およびEventhysteresisです。条件変数を0（デフォルト値）に設定すると、条件がチェックされないことがわかります。
Conceptually, when an event is triggered, all configured conditions are checked. If no filter conditions are triggered, or if any trigger conditions are met, the event notification is generated. If there are filter conditions, and no condition is met, then no event notification is generated. Event filter conditions have reset behavior when an event notification is generated. If any condition is passed, and the notification is generated, the notification reset behavior is performed on all conditions, even those that had not passed. This provides a clean definition of the interaction of the various event conditions.
概念的には、イベントがトリガーされると、構成されたすべての条件がチェックされます。フィルター条件がトリガーされていない場合、またはトリガー条件が満たされている場合、イベント通知が生成されます。フィルター条件があり、条件が満たされない場合、イベント通知は生成されません。イベントフィルターの条件には、イベント通知が生成されると、動作がリセットされます。任意の条件が渡され、通知が生成された場合、通知のリセット動作は、すべての条件でさえ、合格していない条件で実行されます。これは、さまざまなイベント条件の相互作用のきれいな定義を提供します。
An example of the interaction of conditions is an event with an eventCount property set to 5 and an eventInterval property set to 500 milliseconds. Suppose that a burst of occurrences of this event is detected by the FE. The first occurrence will cause a notification to be sent to the CE. Then, if four more occurrences are detected rapidly (less than 0.5 seconds) they will not result in notifications. If two more occurrences are detected, then the second of those will result in a notification. Alternatively, if more than 500 milliseconds has passed since the notification and an occurrence is detected, that will result in a notification. In either case, the count and time interval suppression is reset no matter which condition actually caused the notification.
条件の相互作用の例は、イベントプロパティが5に設定されたイベントと500ミリ秒に設定されたイベントインターバルプロパティです。このイベントの発生のバーストがFEによって検出されたと仮定します。最初の発生により、通知がCEに送信されます。その後、さらに4つの発生が急速に検出された場合（0.5秒未満）、通知は発生しません。さらに2回の発生が検出された場合、2番目の発生が通知になります。あるいは、通知と発生が検出されてから500ミリ秒以上が通過した場合、通知が発生します。どちらの場合でも、実際に通知を引き起こした状態に関係なく、カウントと時間間隔の抑制がリセットされます。
Events with numeric conditions can have hysteresis filters applied to them. The hysteresis level is defined by a property of the event. This allows the FE to notify the CE of the hysteresis applied, and if it chooses, the FE can allow the CE to modify the hysteresis. This applies to <eventChanged/> for a numeric field, and to <eventGreaterThan/> and <eventLessThan/>. The content of a
数値条件のあるイベントには、ヒステリシスフィルターが適用されます。ヒステリシスレベルは、イベントのプロパティによって定義されます。これにより、FEは適用されたヒステリシスのCEに通知することができ、それが選択した場合、FEはCEがヒステリシスを変更できるようにすることができます。これは、数値フィールドの<eventChanged/>、および<eventgreaterthan/>および<eventlessthan/>に適用されます。aのコンテンツ
<variance> element is a numeric value. When supporting hysteresis, the FE MUST track the value of the element and make sure that the condition has become untrue by at least the hysteresis from the event property. To be specific, if the hysteresis is V, then:
<分散>要素は数値です。ヒステリシスをサポートする場合、FEは要素の値を追跡し、少なくともイベントプロパティからのヒステリシスによって条件が真実ではないことを確認する必要があります。具体的には、ヒステリシスがVの場合、次のとおりです。
o For an <eventChanged/> condition, if the last notification was for value X, then the <changed/> notification MUST NOT be generated until the value reaches X +/- V.
o <eventChanged/>条件の場合、最後の通知が値xの場合、値がx/-vに達するまで<変更/>通知を生成してはなりません。
o For an <eventGreaterThan/> condition with threshold T, once the event has been generated at least once it MUST NOT be generated again until the field first becomes less than or equal to T - V, and then exceeds T.
o しきい値tの<eventGreaterthan/>条件の場合、イベントが生成されると、フィールドが最初にt -v以下になり、次にTを超えるまで、再び生成する必要はありません。
o For an <eventLessThan/> condition with threshold T, once the event has been generate at least once it MUST NOT be generated again until the field first becomes greater than or equal to T + V, and then becomes less than T.
o しきい値tの<eventlessthan/>条件の場合、イベントが生成されると、フィールドが最初にt v以上になり、次にtよりも少なくなるまで生成する必要はありません。
Events MAY have a count filtering condition. This property, if set to a non-zero value, indicates the number of occurrences of the event that should be considered redundant and not result in a notification. Thus, if this property is set to 1, and no other conditions apply, then every other detected occurrence of the event will result in a notification. This particular meaning is chosen so that the value 1 has a distinct meaning from the value 0.
イベントにはカウントフィルタリング条件があります。このプロパティは、ゼロ以外の値に設定されている場合、冗長であると見なされ、通知をもたらさないイベントの発生数を示します。したがって、このプロパティが1に設定され、他の条件が適用されない場合、イベントの他のすべての検出された発生は通知になります。この特定の意味は、値1が値0から明確な意味を持つように選択されます。
A conceptual implementation (not required) for this might be an internal suppression counter. Whenever an event is triggered, the counter is checked. If the counter is 0, a notification is generated. Whether or not a notification is generated, the counter is incremented. If the counter exceeds the configured value, it is set to 0.
これに概念的な実装（不要）は、内部抑制カウンターである可能性があります。イベントがトリガーされるたびに、カウンターがチェックされます。カウンターが0の場合、通知が生成されます。通知が生成されるかどうかにかかわらず、カウンターが増加します。カウンターが構成された値を超えると、0に設定されます。
Events MAY have a time filtering condition. This property represents the minimum time interval (in the absence of some other filtering condition being passed) between generating notifications of detected events. This condition MUST only be passed if the time since the last notification of the event is longer than the configured interval in milliseconds.
イベントには、フィルタリング条件がある場合があります。このプロパティは、検出されたイベントの通知の生成間の最小時間間隔（他のいくつかのフィルタリング条件が渡されない場合）を表します。この条件は、イベントの最後の通知以来の時間がミリ秒単位で構成された間隔よりも長い場合にのみ合格する必要があります。
Conceptually, this can be thought of as a stored timestamp that is compared with the detection time, or as a timer that is running that resets a suppression flag. In either case, if a notification is generated due to passing any condition then the time interval detection MUST be restarted.
概念的には、これは、検出時間と比較される保存されたタイムスタンプ、または抑制フラグをリセットする実行中のタイマーと考えることができます。どちらの場合でも、条件を渡すために通知が生成される場合、時間間隔の検出を再起動する必要があります。
The properties for an alias add three (usually) writeable fields. These combine to identify the target component to which the subject alias refers.
エイリアスのプロパティは、3つの（通常）書き込み可能なフィールドを追加します。これらは組み合わせて、サブジェクトエイリアスが参照するターゲットコンポーネントを識別します。
<dataTypeDef>
<name>aliasElementProperties</name>
<synopsis>alias Element Properties definition</synopsis>
<struct>
<derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2">
<name>targetLFBClass</name>
<synopsis>the class ID of the alias target</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>targetLFBInstance</name>
<synopsis>the instance ID of the alias target</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>targetComponentPath</name>
<synopsis>
the path to the component target
each 4 octets is read as one path element,
using the path construction in the ForCES protocol,
[2].
</synopsis>
<typeRef>octetstring[128]</typeRef>
</component>
</struct>
</dataTypeDef>
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:lfb="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
targetNamespace="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
attributeFormDefault="unqualified"
elementFormDefault="qualified">
<xsd:annotation>
<xsd:documentation xml:lang="en">
Schema for Defining LFB Classes and associated types (frames,
data types for LFB attributes, and metadata).
</xsd:documentation>
</xsd:annotation>
<xsd:element name="description" type="xsd:string"/>
<xsd:element name="synopsis" type="xsd:string"/>
<!-- Document root element: LFBLibrary -->
<xsd:element name="LFBLibrary">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="load" type="loadType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="frameDefs" type="frameDefsType"
minOccurs="0"/>
<xsd:element name="dataTypeDefs" type="dataTypeDefsType"
minOccurs="0"/>
<xsd:element name="metadataDefs" type="metadataDefsType"
minOccurs="0"/>
<xsd:element name="LFBClassDefs" type="LFBClassDefsType"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="provides" type="xsd:Name" use="required"/>
</xsd:complexType>
<!-- Uniqueness constraints -->
<xsd:key name="frame">
<xsd:selector xpath="lfb:frameDefs/lfb:frameDef"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="dataType">
<xsd:selector xpath="lfb:dataTypeDefs/lfb:dataTypeDef"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="metadataDef">
<xsd:selector xpath="lfb:metadataDefs/lfb:metadataDef"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="LFBClassDef">
<xsd:selector xpath="lfb:LFBClassDefs/lfb:LFBClassDef"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
</xsd:element>
<xsd:complexType name="loadType">
<xsd:attribute name="library" type="xsd:Name" use="required"/>
<xsd:attribute name="location" type="xsd:anyURI" use="optional"/>
</xsd:complexType>
<xsd:complexType name="frameDefsType">
<xsd:sequence>
<xsd:element name="frameDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="dataTypeDefsType">
<xsd:sequence>
<xsd:element name="dataTypeDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<!--
Predefined (built-in) atomic data-types are:
char, uchar, int16, uint16, int32, uint32, int64, uint64,
string[N], string, byte[N], boolean, octetstring[N],
float32, float64
-->
<xsd:group name="typeDeclarationGroup">
<xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/>
<xsd:element name="array" type="arrayType"/>
<xsd:element name="struct" type="structType"/>
<xsd:element name="union" type="structType"/>
<xsd:element name="alias" type="typeRefNMTOKEN"/>
</xsd:choice>
</xsd:group>
<xsd:simpleType name="typeRefNMTOKEN">
<xsd:restriction base="xsd:token">
<xsd:pattern value="\c+"/>
<xsd:pattern value="string\[\d+\]"/>
<xsd:pattern value="byte\[\d+\]"/>
<xsd:pattern value="octetstring\[\d+\]"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="atomicType">
<xsd:sequence>
<xsd:element name="baseType" type="typeRefNMTOKEN"/>
<xsd:element name="rangeRestriction"
type="rangeRestrictionType" minOccurs="0"/>
<xsd:element name="specialValues" type="specialValuesType"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="rangeRestrictionType">
<xsd:sequence>
<xsd:element name="allowedRange" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="min" type="xsd:integer"
use="required"/>
<xsd:attribute name="max" type="xsd:integer"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="specialValuesType">
<xsd:sequence>
<xsd:element name="specialValue" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
</xsd:sequence>
<xsd:attribute name="value" type="xsd:token"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="arrayType">
<xsd:sequence>
<xsd:group ref="typeDeclarationGroup"/>
<xsd:element name="contentKey" minOccurs="0"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="contentKeyField" maxOccurs="unbounded"
type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="contentKeyID" use="required"
type="xsd:integer"/>
</xsd:complexType>
<!--declare keys to have unique IDs -->
<xsd:key name="contentKeyID">
<xsd:selector xpath="lfb:contentKey"/>
<xsd:field xpath="@contentKeyID"/>
</xsd:key>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="type" use="optional"
default="variable-size">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="fixed-size"/>
<xsd:enumeration value="variable-size"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="length" type="xsd:integer" use="optional"/>
<xsd:attribute name="maxLength" type="xsd:integer"
use="optional"/>
</xsd:complexType>
<xsd:complexType name="structType">
<xsd:sequence>
<xsd:element name="derivedFrom" type="typeRefNMTOKEN"
minOccurs="0"/>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<xsd:attribute name="componentID" use="required"
type="xsd:unsignedInt"/>
</xsd:complexType>
<!-- key declaration to make componentIDs unique in a struct
-->
<xsd:key name="structComponentID">
<xsd:selector xpath="lfb:component"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="metadataDefsType">
<xsd:sequence>
<xsd:element name="metadataDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="metadataID" type="xsd:integer"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="LFBClassDefsType">
<xsd:sequence>
<xsd:element name="LFBClassDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="version" type="versionType"/>
<xsd:element name="derivedFrom" type="xsd:NMTOKEN"
minOccurs="0"/>
<xsd:element name="inputPorts" type="inputPortsType"
minOccurs="0"/>
<xsd:element name="outputPorts" type="outputPortsType"
minOccurs="0"/>
<xsd:element name="components" type="LFBComponentsType"
minOccurs="0"/>
<xsd:element name="capabilities"
type="LFBCapabilitiesType" minOccurs="0"/>
<xsd:element name="events"
type="eventsType" minOccurs="0"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="LFBClassID" use="required"
type="xsd:unsignedInt"/>
</xsd:complexType>
<!-- Key constraint to ensure unique attribute names within
a class:
-->
<xsd:key name="components">
<xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="capabilities">
<xsd:selector xpath="lfb:capabilities/lfb:capability"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="componentIDs">
<xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
<xsd:key name="capabilityIDs">
<xsd:selector xpath="lfb:capabilities/lfb:capability"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="versionType">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="[1-9][0-9]*\.([1-9][0-9]*|0)"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="inputPortsType">
<xsd:sequence>
<xsd:element name="inputPort" type="inputPortType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="inputPortType">
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="expectation" type="portExpectationType"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="group" type="xsd:boolean" use="optional"
default="0"/>
</xsd:complexType>
<xsd:complexType name="portExpectationType">
<xsd:sequence>
<xsd:element name="frameExpected" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<!-- ref must refer to a name of a defined frame type -->
<xsd:element name="ref" type="xsd:string"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="metadataExpected" minOccurs="0">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="metadataInputRefType"/>
<xsd:element name="one-of"
type="metadataInputChoiceType"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="metadataInputChoiceType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="xsd:NMTOKEN"/>
<xsd:element name="one-of" type="metadataInputChoiceType"/>
<xsd:element name="metadataSet" type="metadataInputSetType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataInputSetType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="metadataInputRefType"/>
<xsd:element name="one-of" type="metadataInputChoiceType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataInputRefType">
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="dependency" use="optional"
default="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="required"/>
<xsd:enumeration value="optional"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="defaultValue" type="xsd:token"
use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="outputPortsType">
<xsd:sequence>
<xsd:element name="outputPort" type="outputPortType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="outputPortType">
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="product" type="portProductType"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="group" type="xsd:boolean" use="optional"
default="0"/>
</xsd:complexType>
<xsd:complexType name="portProductType">
<xsd:sequence>
<xsd:element name="frameProduced">
<xsd:complexType>
<xsd:sequence>
<!-- ref must refer to a name of a defined frame type
-->
<xsd:element name="ref" type="xsd:NMTOKEN"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="metadataProduced" minOccurs="0">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata
-->
<xsd:element name="ref" type="metadataOutputRefType"/>
<xsd:element name="one-of"
type="metadataOutputChoiceType"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="metadataOutputChoiceType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="xsd:NMTOKEN"/>
<xsd:element name="one-of" type="metadataOutputChoiceType"/>
<xsd:element name="metadataSet" type="metadataOutputSetType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataOutputSetType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="metadataOutputRefType"/>
<xsd:element name="one-of" type="metadataOutputChoiceType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataOutputRefType">
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="availability" use="optional"
default="unconditional">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="unconditional"/>
<xsd:enumeration value="conditional"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="LFBComponentsType">
<xsd:sequence>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
<xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="access" use="optional"
default="read-write">
<xsd:simpleType>
<xsd:list itemType="accessModeType"/>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="componentID" use="required"
type="xsd:unsignedInt"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="accessModeType">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="read-only"/>
<xsd:enumeration value="read-write"/>
<xsd:enumeration value="write-only"/>
<xsd:enumeration value="read-reset"/>
<xsd:enumeration value="trigger-only"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="LFBCapabilitiesType">
<xsd:sequence>
<xsd:element name="capability" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<xsd:attribute name="componentID" use="required"
type="xsd:integer"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="eventsType">
<xsd:sequence>
<xsd:element name="event" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="eventTarget" type="eventPathType"/>
<xsd:element ref="eventCondition"/>
<xsd:element name="eventReports" type="eventReportsType"
minOccurs="0"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="eventID" use="required"
type="xsd:integer"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="baseID" type="xsd:integer"
use="optional"/>
</xsd:complexType>
<!-- the substitution group for the event conditions -->
<xsd:element name="eventCondition" abstract="true"/>
<xsd:element name="eventCreated"
substitutionGroup="eventCondition"/>
<xsd:element name="eventDeleted"
substitutionGroup="eventCondition"/>
<xsd:element name="eventChanged"
substitutionGroup="eventCondition"/>
<xsd:element name="eventGreaterThan"
substitutionGroup="eventCondition"/>
<xsd:element name="eventLessThan"
substitutionGroup="eventCondition"/>
<xsd:complexType name="eventPathType">
<xsd:sequence>
<xsd:element ref="eventPathPart" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<!-- the substitution group for the event path parts -->
<xsd:element name="eventPathPart" type="xsd:string"
abstract="true"/>
<xsd:element name="eventField" type="xsd:string"
substitutionGroup="eventPathPart"/>
<xsd:element name="eventSubscript" type="xsd:string"
substitutionGroup="eventPathPart"/>
<xsd:complexType name="eventReportsType">
<xsd:sequence>
<xsd:element name="eventReport" type="eventPathType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="booleanType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="0"/>
<xsd:enumeration value="1"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
A ForCES forwarding element handles traffic on behalf of a ForCES control element. While the standards will describe the protocol and mechanisms for this control, different implementations and different instances will have different capabilities. The CE MUST be able to determine what each instance it is responsible for is actually capable of doing. As stated previously, this is an approximation. The CE is expected to be prepared to cope with errors in requests and variations in detail not captured by the capabilities information about an FE.
フォワー転送要素は、力制御要素に代わってトラフィックを処理します。標準では、この制御のプロトコルとメカニズムを説明しますが、さまざまな実装と異なるインスタンスには異なる機能があります。CEは、それが責任を負う各インスタンスが実際に行うことができるものを判断できる必要があります。前述のように、これは近似です。CEは、FEに関する機能情報によってキャプチャされない要求とバリエーションの詳細なバリエーションのエラーに対処する準備ができていると予想されます。
In addition to its capabilities, an FE will have information that can be used in understanding and controlling the forwarding operations. Some of this information will be read-only, while others parts may also be writeable.
その機能に加えて、FEには、転送操作の理解と制御に使用できる情報があります。この情報の一部は読み取り専用ですが、他の部品も書き込み可能です。
In order to make the FE information easily accessible, the information is represented in an LFB. This LFB has a class, FEObject. The LFBClassID for this class is 1. Only one instance of this class will ever be present in an FE, and the instance ID of that instance in the protocol is 1. Thus, by referencing the components of class:1, instance:1 a CE can get the general information about the FE. The FEObject LFB class is described in this section.
FE情報を簡単にアクセスできるようにするために、情報はLFBで表されます。このLFBにはクラス、Feobjectがあります。このクラスのLFBClassidは1です。このクラスの1つのインスタンスのみがFEに存在し、プロトコルのそのインスタンスのインスタンスIDは1です。したがって、クラスのコンポーネントを参照することにより：1、インスタンス：1 aCEは、FEに関する一般情報を取得できます。Feobject LFBクラスについては、このセクションで説明します。
There will also be an FEProtocol LFB class. LFBClassID 2 is reserved for that class. There will be only one instance of that class as well. Details of that class are defined in the ForCES protocol [RFC5810] document.
Feprotocol LFBクラスもあります。LFBClassid 2はそのクラスのために予約されています。そのクラスのインスタンスも1つしかありません。そのクラスの詳細は、フォースプロトコル[RFC5810]ドキュメントで定義されています。
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="FEObject">
<dataTypeDefs>
<dataTypeDef>
<name>LFBAdjacencyLimitType</name>
<synopsis>Describing the Adjacent LFB</synopsis>
<struct>
<component componentID="1">
<name>NeighborLFB</name>
<synopsis>ID for that LFB class</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>ViaPorts</name>
<synopsis>
the ports on which we can connect
</synopsis>
<array type="variable-size">
<typeRef>string</typeRef>
</array>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>PortGroupLimitType</name>
<synopsis>
Limits on the number of ports in a given group
</synopsis>
<struct>
<component componentID="1">
<name>PortGroupName</name>
<synopsis>Group Name</synopsis>
<typeRef>string</typeRef>
</component>
<component componentID="2">
<name>MinPortCount</name>
<synopsis>Minimum Port Count</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>MaxPortCount</name>
<synopsis>Max Port Count</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>SupportedLFBType</name>
<synopsis>table entry for supported LFB</synopsis>
<struct>
<component componentID="1">
<name>LFBName</name>
<synopsis>
The name of a supported LFB class
</synopsis>
<typeRef>string</typeRef>
</component>
<component componentID="2">
<name>LFBClassID</name>
<synopsis>the id of a supported LFB class</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>LFBVersion</name>
<synopsis>
The version of the LFB class used
by this FE.
</synopsis>
<typeRef>string</typeRef>
</component>
<component componentID="4">
<name>LFBOccurrenceLimit</name>
<synopsis>
the upper limit of instances of LFBs of this class
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<!-- For each port group, how many ports can exist
-->
<component componentID="5">
<name>PortGroupLimits</name>
<synopsis>Table of Port Group Limits</synopsis>
<optional/>
<array type="variable-size">
<typeRef>PortGroupLimitType</typeRef>
</array>
</component>
<!-- for the named LFB Class, the LFB Classes it may follow -->
<component componentID="6">
<name>CanOccurAfters</name>
<synopsis>
List of LFB classes that this LFB class can follow
</synopsis>
<optional/>
<array type="variable-size">
<typeRef>LFBAdjacencyLimitType</typeRef>
</array>
</component>
<!-- for the named LFB Class, the LFB Classes that may follow it
-->
<component componentID="7">
<name>CanOccurBefores</name>
<synopsis>
List of LFB classes that can follow this LFB class
</synopsis>
<optional/>
<array type="variable-size">
<typeRef>LFBAdjacencyLimitType</typeRef>
</array>
</component>
<component componentID="8">
<name>UseableParentLFBClasses</name>
<synopsis>
List of LFB classes from which this class has
inherited, and which the FE is willing to allow
for references to instances of this class.
</synopsis>
<optional/>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>FEStateValues</name>
<synopsis>The possible values of status</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>AdminDisable</name>
<synopsis>
FE is administratively disabled
</synopsis>
</specialValue>
<specialValue value="1">
<name>OperDisable</name>
<synopsis>FE is operatively disabled</synopsis>
</specialValue>
<specialValue value="2">
<name>OperEnable</name>
<synopsis>FE is operating</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FEConfiguredNeighborType</name>
<synopsis>Details of the FE's Neighbor</synopsis>
<struct>
<component componentID="1">
<name>NeighborID</name>
<synopsis>Neighbors FEID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>InterfaceToNeighbor</name>
<synopsis>
FE's interface that connects to this neighbor
</synopsis>
<optional/>
<typeRef>string</typeRef>
</component>
<component componentID="3">
<name>NeighborInterface</name>
<synopsis>
The name of the interface on the neighbor to
which this FE is adjacent. This is required
in case two FEs are adjacent on more than
one interface.
</synopsis>
<optional/>
<typeRef>string</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>LFBSelectorType</name>
<synopsis>
Unique identification of an LFB class-instance
</synopsis>
<struct>
<component componentID="1">
<name>LFBClassID</name>
<synopsis>LFB Class Identifier</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>LFBInstanceID</name>
<synopsis>LFB Instance ID</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>LFBLinkType</name>
<synopsis>
Link between two LFB instances of topology
</synopsis>
<struct>
<component componentID="1">
<name>FromLFBID</name>
<synopsis>LFB src</synopsis>
<typeRef>LFBSelectorType</typeRef>
</component>
<component componentID="2">
<name>FromPortGroup</name>
<synopsis>src port group</synopsis>
<typeRef>string</typeRef>
</component>
<component componentID="3">
<name>FromPortIndex</name>
<synopsis>src port index</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>ToLFBID</name>
<synopsis>dst LFBID</synopsis>
<typeRef>LFBSelectorType</typeRef>
</component>
<component componentID="5">
<name>ToPortGroup</name>
<synopsis>dst port group</synopsis>
<typeRef>string</typeRef>
</component>
<component componentID="6">
<name>ToPortIndex</name>
<synopsis>dst port index</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="1">
<name>FEObject</name>
<synopsis>Core LFB: FE Object</synopsis>
<version>1.0</version>
<components>
<component access="read-write" componentID="1">
<name>LFBTopology</name>
<synopsis>the table of known Topologies</synopsis>
<array type="variable-size">
<typeRef>LFBLinkType</typeRef>
</array>
</component>
<component access="read-write" componentID="2">
<name>LFBSelectors</name>
<synopsis>
table of known active LFB classes and
instances
</synopsis>
<array type="variable-size">
<typeRef>LFBSelectorType</typeRef>
</array>
</component>
<component access="read-write" componentID="3">
<name>FEName</name>
<synopsis>name of this FE</synopsis>
<typeRef>string[40]</typeRef>
</component>
<component access="read-write" componentID="4">
<name>FEID</name>
<synopsis>ID of this FE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component access="read-only" componentID="5">
<name>FEVendor</name>
<synopsis>vendor of this FE</synopsis>
<typeRef>string[40]</typeRef>
</component>
<component access="read-only" componentID="6">
<name>FEModel</name>
<synopsis>model of this FE</synopsis>
<typeRef>string[40]</typeRef>
</component>
<component access="read-only" componentID="7">
<name>FEState</name>
<synopsis>State of this FE</synopsis>
<typeRef>FEStateValues</typeRef>
</component>
<component access="read-write" componentID="8">
<name>FENeighbors</name>
<synopsis>table of known neighbors</synopsis>
<optional/>
<array type="variable-size">
<typeRef>FEConfiguredNeighborType</typeRef>
</array>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>ModifiableLFBTopology</name>
<synopsis>
Whether Modifiable LFB is supported
</synopsis>
<optional/>
<typeRef>boolean</typeRef>
</capability>
<capability componentID="31">
<name>SupportedLFBs</name>
<synopsis>List of all supported LFBs</synopsis>
<optional/>
<array type="variable-size">
<typeRef>SupportedLFBType</typeRef>
</array>
</capability>
</capabilities>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
The FE capability information is contained in the capabilities element of the class definition. As described elsewhere, capability information is always considered to be read-only.
FE機能情報は、クラス定義の機能要素に含まれています。他の場所で説明されているように、機能情報は常に読み取り専用と見なされます。
The currently defined capabilities are ModifiableLFBTopology and SupportedLFBs. Information as to which components of the FEObject LFB are supported is accessed by the properties information for those components.
現在定義されている機能は、modifiablelfbtopologyとsupportedlfbsです。Feobject LFBのコンポーネントがどのコンポーネントがサポートされているかについての情報は、これらのコンポーネントのプロパティ情報によってアクセスされます。
This component has a boolean value that indicates whether the LFB topology of the FE may be changed by the CE. If the component is absent, the default value is assumed to be true, and the CE presumes that the LFB topology may be changed. If the value is present and set to false, the LFB topology of the FE is fixed. If the topology is fixed, the SupportedLFBs element may be omitted, and the list of supported LFBs is inferred by the CE from the LFB topology information. If the list of supported LFBs is provided when ModifiableLFBTopology is false, the CanOccurBefore and CanOccurAfter information should be omitted.
このコンポーネントには、FEのLFBトポロジがCEによって変更されるかどうかを示すブール値があります。コンポーネントが存在しない場合、デフォルト値は真であると想定され、CEはLFBトポロジが変更される可能性があると推定します。値が存在し、偽に設定されている場合、FEのLFBトポロジは固定されています。トポロジが固定されている場合、supportedLFBS要素は省略され、サポートされているLFBのリストがLFBトポロジ情報からCEによって推測されます。修正されたLFBSのリストがModifiablelfBtopologyが虚偽の場合に提供される場合、Canoccurbe foreとcanoccurafter情報を省略する必要があります。
One capability that the FE should include is the list of supported LFB classes. The SupportedLFBs component, is an array that contains the information about each supported LFB class. The array structure type is defined as the SupportedLFBType dataTypeDef.
FEに含める必要がある1つの機能は、サポートされているLFBクラスのリストです。supportedlfbsコンポーネントは、サポートされている各LFBクラスに関する情報を含む配列です。配列構造タイプは、supportedlfbtype datatypedefとして定義されます。
Each entry in the SupportedLFBs array describes an LFB class that the FE supports. In addition to indicating that the FE supports the class, FEs with modifiable LFB topology SHOULD include information about how LFBs of the specified class may be connected to other LFBs. This information SHOULD describe which LFB classes the specified LFB class may succeed or precede in the LFB topology. The FE SHOULD include information as to which port groups may be connected to the given adjacent LFB class. If port group information is omitted, it is assumed that all port groups may be used. This capability information on the acceptable ordering and connection of LFBs MAY be omitted if the implementor concludes that the actual constraints are such that the information would be misleading for the CE.
supportedLFBSアレイの各エントリは、FEがサポートするLFBクラスを説明しています。FEがクラスをサポートすることを示すことに加えて、修正可能なLFBトポロジを持つFESには、指定されたクラスのLFBが他のLFBに接続される方法に関する情報を含める必要があります。この情報は、指定されたLFBクラスがLFBトポロジで成功または先行する可能性のあるLFBクラスを説明する必要があります。FEには、特定の隣接するLFBクラスにどのポートグループが接続されるかに関する情報を含める必要があります。ポートグループの情報が省略されている場合、すべてのポートグループが使用されると想定されます。実装者が実際の制約がCEに対して誤解を招くようなものであると結論付けている場合、LFBの許容可能な順序と接続に関するこの機能情報は省略される場合があります。
This component has as its value the name of the LFB class being described.
このコンポーネントには、その値として、説明されているLFBクラスの名前があります。
LFBClassID is the numeric ID of the LFB class being described. While conceptually redundant with the LFB name, both are included for clarity and to allow consistency checking.
LFBClassidは、説明されているLFBクラスの数値IDです。LFB名で概念的に冗長になっていますが、どちらも明確にし、一貫性チェックを許可するために含まれています。
LFBVersion is the version string specifying the LFB class version supported by this FE. As described above in versioning, an FE can support only a single version of a given LFB class.
LFBversionは、このFEでサポートされているLFBクラスバージョンを指定するバージョン文字列です。バージョン化で上記のように、FEは特定のLFBクラスの単一バージョンのみをサポートできます。
This component, if present, indicates the largest number of instances of this LFB class the FE can support. For FEs that do not have the capability to create or destroy LFB instances, this can either be omitted or be the same as the number of LFB instances of this class contained in the LFB list attribute.
このコンポーネントは、存在する場合、FEがサポートできるこのLFBクラスの最大数のインスタンスを示します。LFBインスタンスを作成または破壊する機能がないFESの場合、これは省略またはLFBリスト属性に含まれるこのクラスのLFBインスタンスの数と同じであることができます。
The PortGroupLimits component is an array of information about the port groups supported by the LFB class. The structure of the port group limit information is defined by the PortGroupLimitType dataTypeDef.
PortGrouplimitsコンポーネントは、LFBクラスでサポートされているポートグループに関する情報の配列です。ポートグループ制限情報の構造は、PortGrouplimittype DatatypEdefによって定義されます。
Each PortGroupLimits array entry contains information describing a single port group of the LFB class. Each array entry contains the name of the port group in the PortGroupName component, the fewest number of ports that can exist in the group in the MinPortCount component, and the largest number of ports that can exist in the group in the MaxPortCount component.
各portgrouplimits配列エントリには、LFBクラスの単一のポートグループを説明する情報が含まれています。各配列エントリには、PortgroupNameコンポーネントのポートグループの名前、MinportCountコンポーネントのグループに存在する可能性のある最も少ないポート、およびMaxportCountコンポーネントのグループに存在する可能性のある最大数のポートが含まれています。
The CanOccurAfters component is an array that contains the list of LFBs the described class can occur after. The array entries are defined in the LFBAdjacencyLimitType dataTypeDef.
Canoccuraftersコンポーネントは、説明されたクラスがその後発生する可能性のあるLFBのリストを含む配列です。配列エントリは、LFBADJACENCYLIMITTYPE DATATYPEDEFで定義されています。
The array entries describe a permissible positioning of the described LFB class, referred to here as the SupportedLFB. Specifically, each array entry names an LFB that can topologically precede that LFB class. That is, the SupportedLFB can have an input port connected to an output port of an LFB that appears in the CanOccurAfters array. The LFB class that the SupportedLFB can follow is identified by the NeighborLFB component (of the LFBAdjacencyLimitType dataTypeDef) of the CanOccurAfters array entry. If this neighbor can only be connected to a specific set of input port groups, then the viaPort component is included. This component is an array, with one entry for each input port group of the SupportedLFB that can be connected to an output port of the NeighborLFB.
アレイエントリは、ここではsupportedLFBと呼ばれる、説明されているLFBクラスの許容される位置を記述しています。具体的には、各配列エントリは、そのLFBクラスにトポロジカルに先行できるLFBに名前を付けます。つまり、supportedLFBには、Canoccuraftersアレイに表示されるLFBの出力ポートに接続された入力ポートを持つことができます。Canoccuraftersアレイエントリのneverylfbコンポーネント（lfbadjacencylimittype datatypedef）によってsupportedlfbが従うことができるLFBクラスは識別されます。この隣接が入力ポートグループの特定のセットにのみ接続できる場合、ViaPortコンポーネントが含まれています。このコンポーネントは配列であり、supportedlfbの入力ポートグループごとに1つのエントリがあり、neverylfbの出力ポートに接続できます。
(For example, within a SupportedLFBs entry, each array entry of the CanOccurAfters array must have a unique NeighborLFB, and within each such array entry each viaPort must represent a distinct and valid input port group of the SupportedLFB. The LFB class definition schema does not include these uniqueness constraints.)
（たとえば、supportedLFBSエントリ内では、Canoccuraftersアレイの各配列エントリには一意のneighbourlfbが必要であり、各そのような配列エントリ内で各Viaportは、supportedLFBの明確で有効な入力ポートグループを表す必要があります。これらの独自性の制約を含めます。）
The CanOccurBefores array holds the information about which LFB classes can follow the described class. Structurally, this element parallels CanOccurAfters, and uses the same type definition for the array entries.
Canoccurbeforesアレイは、どのLFBクラスが説明されているクラスに従うことができるかに関する情報を保持します。構造的には、この要素はCanoccuraftersに類似しており、配列エントリに同じタイプ定義を使用します。
The array entries list those LFB classes that the SupportedLFB may precede in the topology. In this component, the entries in the viaPort component of the array value represent the output port groups of the SupportedLFB that may be connected to the NeighborLFB. As with CanOccurAfters, viaPort may have multiple entries if multiple output ports may legitimately connect to the given NeighborLFB class.
配列エントリには、サポートがトポロジに先行する可能性のあるLFBクラスがリストされています。このコンポーネントでは、Array値のVIAPORTコンポーネントのエントリは、NeighborLLFBに接続される可能性のあるSupportEdLFBの出力ポートグループを表します。Canoccuraftersと同様に、複数の出力ポートが指定されたNeighbourlFBクラスに合法的に接続できる場合、ViaPortには複数のエントリがある場合があります。
(And a similar set of uniqueness constraints applies to the CanOccurBefore clauses, even though an LFB may occur both in CanOccurAfter and CanOccurBefore.)
（そして、CanoccurafterとCanoccurbeの両方でLFBが発生する可能性がある場合でも、同様の一連のユニーク性の制約がカノクルベ条項に適用されます。）
The UseableParentLFBClasses array, if present, is used to hold a list of parent LFB class IDs. All the entries in the list must be IDs of classes from which the SupportedLFB class being described has inherited (either directly or through an intermediate parent.) (If an FE includes improper values in this list, improper manipulations by the CE are likely, and operational failures are likely.) In addition, the FE, by including a given class in the last, is indicating to the CE that a given parent class may be used to manipulate an instance of this supported LFB class.
usableParentlfbclassesアレイは、存在する場合、親LFBクラスIDのリストを保持するために使用されます。リスト内のすべてのエントリは、記述されているsupportedLFBクラスが継承するクラスのIDでなければなりません（直接または中間の親を介して）（FEがこのリストに不適切な値を含む場合、CEによる不適切な操作が可能性が高くなります。さらに、FEは、最後に特定のクラスを含めることにより、特定の親クラスを使用してこのサポートされているLFBクラスのインスタンスを操作するために使用できることをCEに示しています。
By allowing such substitution, the FE allows for the case where an instantiated LFB may be of a class not known to the CE, but could still be manipulated. While it is hoped that such situations are rare, it is desirable for this to be supported. This can occur if an FE locally defines certain LFB instances, or if an earlier CE had configured some LFB instances. It can also occur if the FE would prefer to instantiate a more recent, more specific and suitable LFB class rather than a common parent.
そのような代替を許可することにより、FEは、インスタンス化されたLFBがCEに知られていないクラスであるが、それでも操作される可能性がある場合を許可します。そのような状況がまれであることが期待されていますが、これがサポートされることが望ましいです。これは、FEが特定のLFBインスタンスをローカルに定義する場合、または以前のCEがいくつかのLFBインスタンスを構成した場合に発生する可能性があります。また、FEが一般的な親ではなく、より最近、より具体的で適切なLFBクラスをインスタンス化することを好む場合にも発生する可能性があります。
In order to permit this, the FE MUST be more restrained in assigning LFB instance IDs. Normally, instance IDs are qualified by the LFB class. However, if two LFB classes share a parent, and if that parent is listed in the UseableParentLFBClasses for both specific LFB classes, then all the instances of both (or any, if multiple classes are listing the common parent) MUST use distinct instances. This permits the FE to determine which LFB instance is intended by CE manipulation operations even when a parent class is used.
これを許可するには、LFBインスタンスIDの割り当てにより、FEはより抑制される必要があります。通常、インスタンスIDはLFBクラスによって資格があります。ただし、2つのLFBクラスが親を共有し、その親が両方の特定のLFBクラスの使用可能なParentLFBClassesにリストされている場合、両方のすべてのインスタンス（または複数のクラスが共通の親をリストしている場合）のすべてのインスタンスが異なるインスタンスを使用する必要があります。これにより、FEは、親クラスが使用されている場合でも、CE操作操作によってどのLFBインスタンスが意図されるかを決定できます。
While it would be desirable to include class-capability-level information, this is not included in the model. While such information belongs in the FE Object in the supported class table, the contents of that information would be class specific. The currently expected encoding structures for transferring information between the CE and FE are such that allowing completely unspecified information would be likely to induce parse errors. We could specify that the information be encoded in an octetstring, but then we would have to define the internal format of that octet string.
クラスの能力レベルの情報を含めることが望ましいが、これはモデルに含まれていない。そのような情報は、サポートされているクラステーブルのFEオブジェクトに属しますが、その情報の内容はクラス固有のものになります。CEとFEの間に情報を転送するための現在予想されるエンコーディング構造は、完全に不特定の情報が解析エラーを誘導する可能性が高いようになります。情報をオクテットストリングでエンコードすることを指定できますが、そのオクテット文字列の内部形式を定義する必要があります。
As there also are not currently any defined LFB class-level capabilities that the FE needs to report, this information is not present now, but may be added in a future version of the FE object. (This is an example of a case where versioning, rather than inheritance, would be needed, since the FE object must have class ID 1 and instance ID 1 so that the protocol behavior can start by finding this object.)
現在、FEが報告する必要がある定義されたLFBクラスレベルの機能もないため、この情報は現在存在していませんが、FEオブジェクトの将来のバージョンに追加される可能性があります。（これは、FEオブジェクトにはクラスID 1とインスタンスID 1が必要であるため、このオブジェクトを見つけることで開始できるため、継承ではなくバージョン化が必要になる場合の例です。）
The <components> element is included if the class definition contains the definition of the components of the FE object that are not considered "capabilities". Some of these components are writeable and some are read-only, which is determinable by examining the property information of the components.
クラス定義に「機能」とは見なされないFEオブジェクトのコンポーネントの定義が含まれている場合、<コンポーネント>要素が含まれています。これらのコンポーネントの一部は書き込み可能で、一部は読み取り専用です。これは、コンポーネントのプロパティ情報を調べることで決定可能です。
This component carries the overall state of the FE. The possible values are the strings AdminDisable, OperDisable, and OperEnable. The starting state is OperDisable, and the transition to OperEnable is controlled by the FE. The CE controls the transition from OperEnable to/from AdminDisable. For details, refer to the ForCES protocol document [RFC5810].
このコンポーネントには、Feの全体的な状態があります。考えられる値は、文字列が許容できる、操作可能で、操作可能です。開始状態は操作可能であり、Operenableへの移行はFeによって制御されます。CEは、操作可能なoperenableからの移行を制御します。詳細については、フォースプロトコルドキュメント[RFC5810]を参照してください。
The LFBSelectors component is an array of information about the LFBs currently accessible via ForCES in the FE. The structure of the LFB information is defined by the LFBSelectorType dataTypeDef.
LFBSElectorsコンポーネントは、FEの力を介して現在アクセス可能なLFBに関する情報の配列です。LFB情報の構造は、LFBSElectortype DatatypEdefによって定義されます。
Each entry in the array describes a single LFB instance in the FE. The array entry contains the numeric class ID of the class of the LFB instance and the numeric instance ID for this instance.
配列内の各エントリは、FEの単一のLFBインスタンスについて説明します。配列エントリには、LFBインスタンスのクラスの数値クラスIDと、このインスタンスの数値インスタンスIDが含まれています。
The optional LFBTopology component contains information about each inter-LFB link inside the FE, where each link is described in an LFBLinkType dataTypeDef. The LFBLinkType component contains sufficient information to identify precisely the end points of a link. The FromLFBID and ToLFBID components specify the LFB instances at each end of the link, and MUST reference LFBs in the LFB instance table. The FromPortGroup and ToPortGroup MUST identify output and input port groups defined in the LFB classes of the LFB instances identified by FromLFBID and ToLFBID. The FromPortIndex and ToPortIndex components select the entries from the port groups that this link connects. All links are uniquely identified by the FromLFBID, FromPortGroup, and FromPortIndex fields. Multiple links may have the same ToLFBID, ToPortGroup, and ToPortIndex as this model supports fan-in of inter-LFB links but not fan-out.
オプションのLFBTopologyコンポーネントには、FE内の各LFBリンクに関する情報が含まれています。各リンクはLFBlinkType DatatypEdefで説明されています。LFBLINKTYPEコンポーネントには、リンクのエンドポイントを正確に識別するのに十分な情報が含まれています。fromfbidおよびtolfbidコンポーネントは、リンクの両端にLFBインスタンスを指定し、LFBインスタンステーブルでLFBを参照する必要があります。FromPortGroupとToportGroupは、fromFbidおよびTolfBidによって識別されたLFBインスタンスのLFBクラスで定義された出力および入力ポートグループを識別する必要があります。FromPortIndexおよびToportIndexコンポーネントは、このリンクが接続するポートグループからエントリを選択します。すべてのリンクは、fromlfbid、fromportgroup、およびfromportindexフィールドによって一意に識別されます。複数のリンクは、このモデルがLFB間リンクのファンインをサポートしているがファンアウトではなく、同じTolfBid、ToportGroup、およびToportIndexを持っている場合があります。
The FENeighbors component is an array of information about manually configured adjacencies between this FE and other FEs. The content of the array is defined by the FEConfiguredNeighborType dataTypeDef.
Feneighborsコンポーネントは、このFEと他のFESの間の手動で構成された隣接に関する情報の配列です。配列の内容は、feconfiguredneighbortype datatypedefによって定義されます。
This array is intended to capture information that may be configured on the FE and is needed by the CE, where one array entry corresponds to each configured neighbor. Note that this array is not intended to represent the results of any discovery protocols, as those will have their own LFBs. This component is optional.
この配列は、FEで構成されている情報をキャプチャすることを目的としており、CEが必要とします。ここでは、1つの配列エントリが構成された各隣接に対応します。この配列は、発見プロトコルの結果を表すことを意図していないことに注意してください。これらには独自のLFBがあるためです。このコンポーネントはオプションです。
While there may be many ways to configure neighbors, the FE-ID is the best way for the CE to correlate entities. And the interface identifier (name string) is the best correlator. The CE will be able to determine the IP address and media-level information about the neighbor from the neighbor directly. Omitting that information from this table avoids the risk of incorrect double configuration.
Neighborsを構成するには多くの方法があるかもしれませんが、FE-IDはCEがエンティティを相関させるための最良の方法です。インターフェイス識別子（名前文字列）が最適な相関者です。CEは、隣人からの隣人に関するIPアドレスとメディアレベルの情報を直接決定することができます。このテーブルからその情報を省略すると、誤った二重構成のリスクが回避されます。
Information about the intended forms of exchange with a given neighbor is not captured here; only the adjacency information is included.
特定の隣人との意図した交換形態に関する情報は、ここでは捉えられていません。隣接情報のみが含まれています。
This is the ID in some space meaningful to the CE for the neighbor.
これは、隣人にとってCEにとって意味のあるいくつかのスペースのIDです。
This identifies the interface through which the neighbor is reached.
これは、隣人に到達するインターフェイスを識別します。
This identifies the interface on the neighbor through which the neighbor is reached. The interface identification is needed when either only one side of the adjacency has configuration information or the two FEs are adjacent on more than one interface.
これは、隣人に到達する隣人のインターフェイスを識別します。隣接の片側のみが構成情報を持っているか、2つのFEが複数のインターフェイスに隣接している場合、インターフェイス識別が必要です。
This section describes how the proposed FE model meets the requirements outlined in Section 5 of RFC 3654 [RFC3654]. The requirements can be separated into general requirements (Section 5, 5.1 - 5.4) and the specification of the minimal set of logical functions that the FE model must support (Section 5.5).
このセクションでは、提案されたFEモデルが、RFC 3654 [RFC3654]のセクション5で概説されている要件をどのように満たしているかについて説明します。要件は、一般的な要件（セクション5、5.1-5.4）に分離でき、FEモデルがサポートする必要がある最小限の論理関数の仕様（セクション5.5）に分けることができます。
The general requirement on the FE model is that it be able to express the logical packet processing capability of the FE, through both a capability and a state model. In addition, the FE model is expected to allow flexible implementations and be extensible to allow defining new logical functions.
FEモデルの一般的な要件は、機能モデルと状態モデルの両方を介して、FEの論理パケット処理機能を表現できることです。さらに、FEモデルは、柔軟な実装を可能にし、新しい論理関数を定義できるように拡張可能になることが期待されています。
A major component of the proposed FE model is the Logical Functional Block (LFB) model. Each distinct logical function in an FE is modeled as an LFB. Operational parameters of the LFB that must be visible to the CE are conceptualized as LFB components. These components express the capability of the FE and support flexible implementations by allowing an FE to specify which optional features are supported. The components also indicate whether they are configurable by the CE for an LFB class. Configurable components provide the CE some flexibility in specifying the behavior of an LFB. When multiple LFBs belonging to the same LFB class are instantiated on an FE, each of those LFBs could be configured with different component settings. By querying the settings of the components for an instantiated LFB, the CE can determine the state of that LFB.
提案されたFEモデルの主要なコンポーネントは、論理関数ブロック（LFB）モデルです。FEのそれぞれの異なる論理関数は、LFBとしてモデル化されています。CEに見える必要があるLFBの運用パラメーターは、LFBコンポーネントとして概念化されます。これらのコンポーネントは、FEの機能を表現し、FEがどのオプション機能がサポートされているかを指定できるようにすることにより、柔軟な実装をサポートします。コンポーネントは、LFBクラスのCEで構成可能であるかどうかも示します。構成可能なコンポーネントは、LFBの動作を指定する際の柔軟性をCEに提供します。同じLFBクラスに属する複数のLFBがFEでインスタンス化される場合、これらのLFBはそれぞれ異なるコンポーネント設定で構成できます。インスタンス化されたLFBのコンポーネントの設定を照会することにより、CEはそのLFBの状態を決定できます。
Instantiated LFBs are interconnected in a directed graph that describes the ordering of the functions within an FE. This directed graph is described by the topology model. The combination of the components of the instantiated LFBs and the topology describe the packet processing functions available on the FE (current state).
インスタンス化されたLFBは、FE内の関数の順序を説明する指向グラフに相互接続されています。この指示されたグラフは、トポロジモデルによって説明されています。インスタンス化されたLFBとトポロジのコンポーネントの組み合わせは、FE（電流状態）で利用可能なパケット処理機能を説明しています。
Another key component of the FE model is the FE components. The FE components are used mainly to describe the capabilities of the FE, but they also convey information about the FE state.
FEモデルのもう1つの重要なコンポーネントは、FEコンポーネントです。Feコンポーネントは、主にFeの機能を記述するために使用されますが、Fe状態に関する情報も伝えます。
The FE model includes only the definition of the FE Object LFB itself. Meeting the full set of working group requirements requires other LFBs. The class definitions for those LFBs will be provided in other documents.
FEモデルには、FEオブジェクトLFB自体の定義のみが含まれます。ワーキンググループ要件の完全なセットを満たすには、他のLFBが必要です。これらのLFBのクラス定義は、他のドキュメントで提供されます。
The actual model of the forwarding plane in a given NE is something the CE must learn and control by communicating with the FEs (or by other means). Most of this communication will happen in the post-association phase using the ForCES protocol. The following types of information must be exchanged between CEs and FEs via the ForCES protocol [RFC5810]:
特定のNEにおける転送面の実際のモデルは、FES（または他の手段）と通信することにより、CEが学習および制御しなければならないものです。この通信のほとんどは、力プロトコルを使用して、アサシエーション後の段階で発生します。次の種類の情報は、力プロトコル[RFC5810]を介してCESとFESの間で交換する必要があります。
1. FE topology query,
1. FEトポロジクエリ、
2. FE capability declaration, 3. LFB topology (per FE) and configuration capabilities query,
2. FE機能宣言、3。LFBトポロジ（FEあたり）および構成機能クエリ、
4. LFB capability declaration,
4. LFB機能宣言、
5. State query of LFB components,
5. LFBコンポーネントの状態クエリ、
6. Manipulation of LFB components, and
6. LFBコンポーネントの操作、および
7. LFB topology reconfiguration.
7. LFBトポロジー再構成。
Items 1 through 5 are query exchanges, where the main flow of information is from the FEs to the CEs. Items 1 through 4 are typically queried by the CE(s) in the beginning of the post-association (PA) phase, though they may be repeatedly queried at any time in the PA phase. Item 5 (state query) will be used at the beginning of the PA phase, and often frequently during the PA phase (especially for the query of statistical counters).
項目1〜5は、情報の主な流れがFESからCESへのクエリ交換です。項目1〜4は通常、PAフェーズでいつでも繰り返し照会される場合がありますが、通常、Association（PA）フェーズの開始時にCE（S）によって照会されます。項目5（状態クエリ）は、PAフェーズの開始時に、そして多くの場合PAフェーズで頻繁に使用されます（特に統計カウンターのクエリに対して）。
Items 6 and 7 are "command" types of exchanges, where the main flow of information is from the CEs to the FEs. Messages in Item 6 (the LFB re-configuration commands) are expected to be used frequently. Item 7 (LFB topology re-configuration) is needed only if dynamic LFB topologies are supported by the FEs and it is expected to be used infrequently.
項目6と7は、情報の主な流れがCESからFESへの「コマンド」タイプの交換です。項目6（LFB再構成コマンド）のメッセージは、頻繁に使用されると予想されます。項目7（LFBトポロジの再構成）は、動的LFBトポロジがFESによってサポートされており、まれに使用されることが予想される場合にのみ必要です。
The inter-FE topology (Item 1 above) can be determined by the CE in many ways. Neither this document nor the ForCES protocol [RFC5810] document mandates a specific mechanism. The LFB class definition does include the capability for an FE to be configured with, and to provide to the CE in response to a query, the identity of its neighbors. There may also be defined specific LFB classes and protocols for neighbor discovery. Routing protocols may be used by the CE for adjacency determination. The CE may be configured with the relevant information.
FE間トポロジ（上記の項目1）は、多くの点でCEによって決定できます。このドキュメントもフォースプロトコル[RFC5810]ドキュメントは、特定のメカニズムを義務付けていません。LFBクラスの定義には、Feが構成される機能が含まれており、クエリに応じて隣人のアイデンティティに応じてCEに提供する機能が含まれています。また、近隣発見のための特定のLFBクラスとプロトコルが定義される場合があります。ルーティングプロトコルは、隣接する決定にCEで使用できます。CEは、関連情報で構成される場合があります。
The relationship between the FE model and the seven post-association messages is visualized in Figure 12:
FEモデルと7つの関連付け後のメッセージの関係を図12で視覚化します。
+--------+
..........-->| CE |
/----\ . +--------+
\____/ FE Model . ^ |
| |................ (1),2 | | 6, 7
| | (off-line) . 3, 4, 5 | |
\____/ . | v
. +--------+
e.g., RFCs ..........-->| FE |
+--------+
Figure 12: Relationship between the FE model and the ForCES protocol messages, where (1) is part of the ForCES base protocol, and the rest are defined by the FE model.
図12：FEモデルと力プロトコルメッセージとの関係。（1）はForce Base Protocolの一部であり、残りはFEモデルによって定義されます。
The actual encoding of these messages is defined by the ForCES protocol [RFC5810] document and is beyond the scope of the FE model. Their discussion is nevertheless important here for the following reasons:
これらのメッセージの実際のエンコードは、Force Protocol [RFC5810]ドキュメントによって定義され、FEモデルの範囲を超えています。それにもかかわらず、彼らの議論は次の理由でここで重要です。
o These PA model components have considerable impact on the FE model. For example, some of the above information can be represented as components of the LFBs, in which case such components must be defined in the LFB classes.
o これらのPAモデルコンポーネントは、FEモデルに大きな影響を与えます。たとえば、上記の情報の一部はLFBのコンポーネントとして表すことができます。その場合、そのようなコンポーネントはLFBクラスで定義する必要があります。
o The understanding of the type of information that must be exchanged between the FEs and CEs can help to select the appropriate protocol format and the actual encoding method (such as XML, TLVs).
o FESとCESの間で交換する必要がある情報の種類を理解することは、適切なプロトコル形式と実際のエンコード方法（XML、TLVなど）を選択するのに役立ちます。
o Understanding the frequency of these types of messages should influence the selection of the protocol format (efficiency considerations).
o これらのタイプのメッセージの頻度を理解することは、プロトコル形式の選択に影響を与えるはずです（効率の考慮事項）。
The remaining sub-sections of this section address each of the seven message types.
このセクションの残りのサブセクションは、7つのメッセージタイプのそれぞれに対応しています。
An FE may contain zero, one, or more external ingress ports. Similarly, an FE may contain zero, one, or more external egress ports. In other words, not every FE has to contain any external ingress or egress interfaces. For example, Figure 13 shows two cascading FEs. FE #1 contains one external ingress interface but no external egress interface, while FE #2 contains one external egress interface but no ingress interface. It is possible to connect these two FEs together via their internal interfaces to achieve the complete ingress-to-egress packet processing function. This provides the flexibility to spread the functions across multiple FEs and interconnect them together later for certain applications.
FEには、ゼロ、1、またはより多くの外部侵入ポートが含まれる場合があります。同様に、FEにはゼロ、1つ、またはそれ以上の外部出力ポートが含まれる場合があります。言い換えれば、すべてのFEが外部イングレスまたは出力インターフェイスを含む必要があるわけではありません。たとえば、図13は、2つのカスケードFESを示しています。FE＃1には1つの外部イングレスインターフェイスが含まれていますが、外部出口インターフェイスはありませんが、FE＃2には1つの外部出力インターフェイスが含まれていますが、イングレスインターフェイスは含まれていません。これらの2つのFESを内部インターフェイスを介して接続して、完全なイングレス間のパケット処理機能を実現することができます。これにより、複数のFESに関数を広げ、特定のアプリケーションのために後でそれらを相互接続する柔軟性が提供されます。
While the inter-FE communication protocol is out of scope for ForCES, it is up to the CE to query and understand how multiple FEs are inter-connected to perform a complete ingress-egress packet processing function, such as the one described in Figure 13. The inter-FE topology information may be provided by FEs, may be hard-coded into CE, or may be provided by some other entity (e.g., a bus manager) independent of the FEs. So while the ForCES protocol [RFC5810] supports FE topology query from FEs, it is optional for the CE to use it, assuming that the CE has other means to gather such topology information.
Inter-FE通信プロトコルは力の範囲外ですが、図13で説明するような完全な侵入侵入パケット処理機能を実行するために複数のFEがどのように接続されているかをクエリして理解するのはCE次第です。FE間トポロジー情報はFESによって提供されるか、CEにハードコーディングされるか、FESとは無関係に他のエンティティ（バスマネージャーなど）によって提供される場合があります。したがって、Force Protocol [RFC5810]はFESからのFEトポロジークエリをサポートしていますが、CEがそのようなトポロジ情報を収集する他の手段があると仮定して、CEがそれを使用することはオプションです。
+-----------------------------------------------------+
| +---------+ +------------+ +---------+ |
input| | | | | | output |
---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+
| | port | |Decompressor| |Forwarder| FE | |
| +---------+ +------------+ +---------+ #1 | |
+-----------------------------------------------------+ V
|
+-----------------------<-----------------------------+
|
| +----------------------------------------+
V | +------------+ +----------+ |
| input | | | | output |
+->--+->|Header |-->| Egress |---------+-->
| |Compressor | | port | FE |
| +------------+ +----------+ #2 |
+----------------------------------------+
Figure 13: An example of two FEs connected together.
図13：一緒に接続された2つのFESの例。
Once the inter-FE topology is discovered by the CE after this query, it is assumed that the inter-FE topology remains static. However, it is possible that an FE may go down during the NE operation, or a board may be inserted and a new FE activated, so the inter-FE topology will be affected. It is up to the ForCES protocol to provide a mechanism for the CE to detect such events and deal with the change in FE topology. FE topology is outside the scope of the FE model.
このクエリの後、CEによってFE間トポロジが発見されると、FE間トポロジは静的なままであると想定されます。ただし、NE操作中にFEが下がるか、ボードが挿入され、新しいFEがアクティブ化される可能性があるため、FE間トポロジが影響を受ける可能性があります。CEがそのようなイベントを検出し、FEトポロジの変化に対処するためのメカニズムを提供するのは、力プロトコル次第です。FEトポロジーは、FEモデルの範囲外です。
FEs will have many types of limitations. Some of the limitations must be expressed to the CEs as part of the capability model. The CEs must be able to query these capabilities on a per-FE basis. Examples are the following:
FESには多くの種類の制限があります。制限の一部は、機能モデルの一部としてCESに表現する必要があります。CESは、これらの機能をPERごとに照会できる必要があります。例は次のとおりです。
o Metadata passing capabilities of the FE. Understanding these capabilities will help the CE to evaluate the feasibility of LFB topologies, and hence to determine the availability of certain services.
o Feのメタデータの合格能力。これらの機能を理解することは、CEがLFBトポロジの実現可能性を評価し、したがって特定のサービスの可用性を決定するのに役立ちます。
o Global resource query limitations (applicable to all LFBs of the FE).
o グローバルリソースクエリの制限（FEのすべてのLFBに適用）。
o LFB supported by the FE.
o FEでサポートされているLFB。
o LFB class instantiation limit.
o LFBクラスのインスタンスリミット。
o LFB topological limitations (linkage constraint, ordering, etc.).
o LFBトポロジーの制限（リンケージの制約、注文など）。
The ForCES protocol must provide the means for the CEs to discover the current set of LFB instances in an FE and the interconnections between the LFBs within the FE. In addition, sufficient information should be available to determine whether the FE supports any CE-initiated (dynamic) changes to the LFB topology, and if so, determine the allowed topologies. Topology configurability can also be considered as part of the FE capability query as described in Section 7.2.
Force Protocolは、CESがFEのLFBインスタンスの現在のセットとFe内のLFB間の相互接続を発見する手段を提供する必要があります。さらに、FEがLFBトポロジーのCEに関与した（動的）変化をサポートするかどうかを判断するのに十分な情報が利用可能である必要があります。もしそうなら、許可されたトポロジを決定します。トポロジの構成可能性は、セクション7.2で説明されているように、FE機能クエリの一部と見なすこともできます。
LFB class specifications define a generic set of capabilities. When an LFB instance is implemented (instantiated) on a vendor's FE, some additional limitations may be introduced. Note that we discuss only those limitations that are within the flexibility of the LFB class specification. That is, the LFB instance will remain compliant with the LFB class specification despite these limitations. For example, certain features of an LFB class may be optional, in which case it must be possible for the CE to determine whether or not an optional feature is supported by a given LFB instance. Also, the LFB class definitions will probably contain very few quantitative limits (e.g., size of tables), since these limits are typically imposed by the implementation. Therefore, quantitative limitations should always be expressed by capability arguments.
LFBクラスの仕様は、一般的な機能セットを定義します。ベンダーのFEにLFBインスタンスが実装（インスタンス化された）場合、いくつかの追加の制限が導入される場合があります。LFBクラスの仕様の柔軟性の範囲内にある制限のみを議論することに注意してください。つまり、LFBインスタンスは、これらの制限にもかかわらず、LFBクラスの仕様に準拠したままです。たとえば、LFBクラスの特定の機能がオプションである場合があります。この場合、CEは、特定のLFBインスタンスによってオプションの機能がサポートされているかどうかを判断することができなければなりません。また、LFBクラスの定義には、おそらくこれらの制限が実装によって課されるため、定量的な制限がほとんど含まれていません（例：テーブルのサイズ）。したがって、定量的な制限は、常に能力引数によって表現する必要があります。
LFB instances in the model of a particular FE implementation will possess limitations on the capabilities defined in the corresponding LFB class. The LFB class specifications must define a set of capability arguments, and the CE must be able to query the actual capabilities of the LFB instance via querying the value of such arguments. The capability query will typically happen when the LFB is first detected by the CE. Capabilities need not be re-queried in case of static limitations. In some cases, however, some capabilities may change in time (e.g., as a result of adding/removing other LFBs, or configuring certain components of some other LFB when the LFBs share physical resources), in which case additional mechanisms must be implemented to inform the CE about the changes.
特定のFE実装のモデルのLFBインスタンスは、対応するLFBクラスで定義された機能に制限があります。LFBクラスの仕様は、一連の機能引数を定義する必要があり、CEはそのような引数の値を照会することにより、LFBインスタンスの実際の機能を照会できる必要があります。通常、機能クエリは、LFBがCEによって最初に検出されたときに発生します。静的な制限がある場合に、機能を再征服する必要はありません。ただし、場合によっては、一部の機能が時間に変化する場合があります（例えば、他のLFBを追加/削除したり、LFBが物理リソースを共有しているときに他のLFBの特定のコンポーネントを構成したりした場合）。CEに変更について通知します。
The following two broad types of limitations will exist:
次の2つの広範な制限が存在します。
o Qualitative restrictions. For example, a standardized multi-field classifier LFB class may define a large number of classification fields, but a given FE may support only a subset of those fields.
o 定性的制限。たとえば、標準化されたマルチフィールド分類器LFBクラスは、多数の分類フィールドを定義できますが、特定のFEはこれらのフィールドのサブセットのみをサポートする場合があります。
o Quantitative restrictions, such as the maximum size of tables, etc.
o テーブルの最大サイズなどの定量的制限。
The capability parameters that can be queried on a given LFB class will be part of the LFB class specification. The capability parameters should be regarded as special components of the LFB. The actual values of these components may, therefore, be obtained using the same component query mechanisms as used for other LFB components.
特定のLFBクラスで照会できる機能パラメーターは、LFBクラスの仕様の一部になります。機能パラメーターは、LFBの特別なコンポーネントと見なす必要があります。したがって、これらのコンポーネントの実際の値は、他のLFBコンポーネントに使用されるのと同じコンポーネントクエリメカニズムを使用して取得できます。
Capability components are read-only arguments. In cases where some implementations may allow CE modification of the value, the information must be represented as an operational component, not a capability component.
機能コンポーネントは読み取り専用の引数です。いくつかの実装が値のCE変更を可能にする場合、情報は機能コンポーネントではなく、運用コンポーネントとして表現する必要があります。
Assuming that capabilities will not change frequently, the efficiency of the protocol/schema/encoding is of secondary concern.
機能が頻繁に変わらないと仮定すると、プロトコル/スキーマ/エンコードの効率は二次的な懸念事項です。
Much of this restrictive information is captured by the component property information, and so can be accessed uniformly for all information within the model.
この制限情報の多くはコンポーネントプロパティ情報によってキャプチャされるため、モデル内のすべての情報に対して均一にアクセスできます。
This feature must be provided by all FEs. The ForCES protocol and the data schema/encoding conveyed by the protocol must together satisfy the following requirements to facilitate state query of the LFB components:
この機能は、すべてのFESで提供する必要があります。プロトコルによって伝えられる力プロトコルとデータスキーマ/エンコーディングは、LFBコンポーネントの状態クエリを促進するために、次の要件を一緒に満たす必要があります。
o Must permit FE selection. This is primarily to refer to a single FE, but referring to a group of (or all) FEs may optionally be supported.
o FEの選択を許可する必要があります。これは主に単一のFeを指すためのものですが、FESの（またはすべての）グループを参照することは、オプションでサポートされる場合があります。
o Must permit LFB instance selection. This is primarily to refer to a single LFB instance of an FE, but optionally addressing of a group of (or all) LFBs may be supported.
o LFBインスタンスの選択を許可する必要があります。これは主にFEの単一のLFBインスタンスを指すためのものですが、オプションでは（またはすべての）LFBのグループのアドレス指定がサポートされる場合があります。
o Must support addressing of individual components of an LFB.
o LFBの個々のコンポーネントのアドレス指定をサポートする必要があります。
o Must provide efficient encoding and decoding of the addressing info and the configured data.
o アドレス指定情報と構成されたデータの効率的なエンコードとデコードを提供する必要があります。
o Must provide efficient data transmission of the component state over the wire (to minimize communication load on the CE-FE link).
o ワイヤ上のコンポーネント状態の効率的なデータ送信を提供する必要があります（CE-FEリンクの通信負荷を最小限に抑えるには）。
The FE model provides for the definition of LFB classes. Each class has a globally unique identifier. Information within the class is represented as components and assigned identifiers within the scope of that class. This model also specifies that instances of LFB classes have identifiers. The combination of class identifiers, instance identifiers, and component identifiers is used by the protocol to reference the LFB information in the protocol operations.
FEモデルは、LFBクラスの定義を提供します。各クラスには、グローバルに一意の識別子があります。クラス内の情報は、そのクラスの範囲内でコンポーネントとして表され、割り当てられた識別子として表されます。このモデルは、LFBクラスのインスタンスに識別子があることも指定しています。クラス識別子、インスタンス識別子、およびコンポーネント識別子の組み合わせは、プロトコルでプロトコル操作のLFB情報を参照するために使用されます。
Operations that will be needed to reconfigure LFB topology are as follows:
LFBトポロジを再構成するために必要な操作は次のとおりです。
o Create a new instance of a given LFB class on a given FE.
o 特定のFEで特定のLFBクラスの新しいインスタンスを作成します。
o Connect a given output of LFB x to the given input of LFB y.
o LFB Xの特定の出力をLFB Yの指定された入力に接続します。
o Disconnect: remove a link between a given output of an LFB and a given input of another LFB.
o 切断：LFBの特定の出力と別のLFBの特定の入力との間のリンクを削除します。
o Delete a given LFB (automatically removing all interconnects to/ from the LFB).
o 特定のLFBを削除します（すべての相互接続をLFBに自動的に削除します）。
This section contains an example LFB definition. While some properties of LFBs are shown by the FE Object LFB, this endeavors to show how a data plane LFB might be build. This example is a fictional case of an interface supporting a coarse WDM optical interface that carries frame relay traffic. The statistical information (including error statistics) is omitted.
このセクションには、LFB定義の例が含まれています。LFBの一部のプロパティはFEオブジェクトLFBによって示されていますが、これはデータプレーンLFBがどのように構築されるかを示すために努力しています。この例は、フレームリレートラフィックを運ぶ粗いWDM光学インターフェイスをサポートするインターフェイスの架空のケースです。統計情報（エラー統計を含む）は省略されています。
Later portions of this example include references to protocol operations. The operations described are operations the protocol needs to support. The exact format and fields are purely informational here, as the ForCES protocol [RFC5810] document defines the precise syntax and semantics of its operations.
この例の後の部分には、プロトコル操作への参照が含まれています。説明されている操作は、プロトコルがサポートする必要がある操作です。Force Protocol [RFC5810]ドキュメントは、その操作の正確な構文とセマンティクスを定義するため、正確な形式とフィールドは純粋に情報に基づいています。
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="LaserFrameLFB">
<frameDefs>
<frameDef>
<name>FRFrame</name>
<synopsis>
A frame relay frame, with DLCI without
stuffing)
</synopsis>
</frameDef>
<frameDef>
<name>IPFrame</name>
<synopsis>An IP Packet</synopsis>
</frameDef>
</frameDefs>
<dataTypeDefs>
<dataTypeDef>
<name>frequencyInformationType</name>
<synopsis>
Information about a single CWDM frequency
</synopsis>
<struct>
<component componentID="1">
<name>LaserFrequency</name>
<synopsis>encoded frequency(channel)</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>FrequencyState</name>
<synopsis>state of this frequency</synopsis>
<typeRef>PortStatusValues</typeRef>
</component>
<component componentID="3">
<name>LaserPower</name>
<synopsis>current observed power</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>FrameRelayCircuits</name>
<synopsis>
Information about circuits on this Frequency
</synopsis>
<array>
<typeRef>frameCircuitsType</typeRef>
</array>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>frameCircuitsType</name>
<synopsis>
Information about a single Frame Relay Circuit
</synopsis>
<struct>
<component componentID="1">
<name>DLCI</name>
<synopsis>DLCI of the circuit</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>CircuitStatus</name>
<synopsis>state of the circuit</synopsis>
<typeRef>PortStatusValues</typeRef>
</component>
<component componentID="3">
<name>isLMI</name>
<synopsis>is this the LMI circuit</synopsis>
<typeRef>boolean</typeRef>
</component>
<component componentID="4">
<name>associatedPort</name>
<synopsis>
which input / output port is associated
with this circuit
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>PortStatusValues</name>
<synopsis>
The possible values of status. Used for both
administrative and operational status
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>Disabled </name>
<synopsis>the component is disabled</synopsis>
</specialValue>
<specialValue value="1">
<name>Enabled</name>
<synopsis>FE is operatively enabled</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
</dataTypeDefs>
<metadataDefs>
<metadataDef>
<name>DLCI</name>
<synopsis>The DLCI the frame arrived on</synopsis>
<metadataID>12</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>LaserChannel</name>
<synopsis>The index of the laser channel</synopsis>
<metadataID>34</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
</metadataDefs>
<LFBClassDefs>
<!-- dummy classid, but needs to be a valid value -->
<LFBClassDef LFBClassID="255">
<name>FrameLaserLFB</name>
<synopsis>Fictional LFB for Demonstrations</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="true">
<name>LMIfromFE</name>
<synopsis>
Ports for LMI traffic, for transmission
</synopsis>
<expectation>
<frameExpected>
<ref>FRFrame</ref>
</frameExpected>
<metadataExpected>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataExpected>
</expectation>
</inputPort>
<inputPort>
<name>DatafromFE</name>
<synopsis>
Ports for data to be sent on circuits
</synopsis>
<expectation>
<frameExpected>
<ref>IPFrame</ref>
</frameExpected>
<metadataExpected>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>LMItoFE</name>
<synopsis>
Ports for LMI traffic for processing
</synopsis>
<product>
<frameProduced>
<ref>FRFrame</ref>
</frameProduced>
<metadataProduced>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="true">
<name>DatatoFE</name>
<synopsis>
Ports for Data traffic for processing
</synopsis>
<product>
<frameProduced>
<ref>IPFrame</ref>
</frameProduced>
<metadataProduced>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>AdminPortState</name>
<synopsis>is this port allowed to function</synopsis>
<typeRef>PortStatusValues</typeRef>
</component>
<component access="read-write" componentID="2">
<name>FrequencyInformation</name>
<synopsis>
table of information per CWDM frequency
</synopsis>
<array type="variable-size">
<typeRef>frequencyInformationType</typeRef>
</array>
</component>
</components>
<capabilities>
<capability componentID="31">
<name>OperationalState</name>
<synopsis>
whether the port over all is operational
</synopsis>
<typeRef>PortStatusValues</typeRef>
</capability>
<capability componentID="32">
<name>MaximumFrequencies</name>
<synopsis>
how many laser frequencies are there
</synopsis>
<typeRef>uint16</typeRef>
</capability>
<capability componentID="33">
<name>MaxTotalCircuits</name>
<synopsis>
Total supportable Frame Relay Circuits, across
all laser frequencies
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
<events baseID="61">
<event eventID="1">
<name>FrequencyState</name>
<synopsis>
The state of a frequency has changed
</synopsis>
<eventTarget>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrequencyState</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<!-- report the new state -->
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrequencyState</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>CreatedFrequency</name>
<synopsis>A new frequency has appeared</synopsis>
<eventTarget>
<eventField>FrequencyInformation></eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserFrequency</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="3">
<name>DeletedFrequency</name>
<synopsis>
A frequency Table entry has been deleted
</synopsis>
<eventTarget>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
</eventTarget>
<eventDeleted/>
</event>
<event eventID="4">
<name>PowerProblem</name>
<synopsis>
there are problems with the laser power level
</synopsis>
<eventTarget>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserPower</eventField>
</eventTarget>
<eventLessThan/>
<eventReports>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserPower</eventField>
</eventReport>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserFrequency</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="5">
<name>FrameCircuitChanged</name>
<synopsis>
the state of an Fr circuit on a frequency
has changed
</synopsis>
<eventTarget>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrameRelayCircuits</eventField>
<eventSubscript>FrameCircuitIndex</eventSubscript>
<eventField>CircuitStatus</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrameRelayCircuits</eventField>
<eventSubscript>FrameCircuitIndex</eventSubscript>
<eventField>CircuitStatus</eventField>
</eventReport>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrameRelayCircuits</eventField>
<eventSubscript>FrameCircuitIndex</eventSubscript>
<eventField>DLCI</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
This LFB is designed to handle data packets coming in from or going out to the external world. It is not a full port, and it lacks many useful statistics, but it serves to show many of the relevant behaviors. The following paragraphs describe a potential operational device and how it might use this LFB definition.
このLFBは、外界から入ったり外に出たりするデータパケットを処理するように設計されています。それは完全なポートではなく、多くの有用な統計がありませんが、関連する行動の多くを示すのに役立ちます。次の段落では、潜在的な動作デバイスと、このLFB定義の使用方法について説明します。
Packets arriving without error from the physical interface come in on a frame relay DLCI on a laser channel. These two values are used by the LFB to look up the handling for the packet. If the handling indicates that the packet is LMI, then the output index is used to select an LFB port from the LMItoFE port group. The packet is sent as a full frame relay frame (without any bit or byte stuffing) on the selected port. The laser channel and DLCI are sent as metadata, even though the DLCI is also still in the packet.
物理インターフェイスからエラーなしで到着するパケットは、レーザーチャネルのフレームリレーDLCIに届きます。これらの2つの値は、LFBによってパケットの処理を検索するために使用されます。ハンドリングがパケットがLMIであることを示している場合、出力インデックスを使用してLmitofeポートグループからLFBポートを選択します。パケットは、選択したポートにフルフレームリレーフレーム（ビットまたはバイトの詰め物なし）として送信されます。DLCIもまだパケットに含まれていても、レーザーチャネルとDLCIはメタデータとして送信されます。
Good packets that arrive and are not LMI and have a frame relay type indicator of IP are sent as IP packets on the port in the DatatoFE port group, using the same index field from the table based on the laser channel and DLCI. The channel and DLCI are attached as metadata for other use (classifiers, for example).
LMIではなく、IPのフレームリレータイプインジケーターを持つ優れたパケットは、レーザーチャネルとDLCIに基づいてテーブルから同じインデックスフィールドを使用して、DatatofeポートグループのポートのIPパケットとして送信されます。チャネルとDLCIは、他の使用のためのメタデータとして接続されています（たとえば、分類子）。
The current definition does not specify what to do if the frame relay type information is not IP.
現在の定義では、フレームリレータイプ情報がIPではない場合、何をすべきかを指定しません。
Packets arriving on input ports arrive with the laser channel and frame relay DLCI as metadata. As such, a single input port could have been used. With the structure that is defined (which parallels the output structure), the selection of channel and DLCI could be restricted by the arriving input port group (LMI vs. data) and port index. As an alternative LFB design, the structures could require a 1-1 relationship between DLCI and the LFB port, in which case no metadata would be needed. This would however be quite complex and noisy. The intermediate level of structure here allows parallelism between input and output, without requiring excessive ports.
入力ポートに到着するパケットは、メタデータとしてレーザーチャネルとフレームリレーDLCIを使用して到着します。そのため、単一の入力ポートを使用できた可能性があります。定義された構造（出力構造に匹敵する）を使用すると、チャネルとDLCIの選択は、到着する入力ポートグループ（LMI対データ）とポートインデックスによって制限される可能性があります。代替LFB設計として、構造にはDLCIとLFBポートの間の1-1の関係が必要になる場合があります。その場合、メタデータは必要ありません。しかし、これは非常に複雑で騒々しいでしょう。ここでの構造の中間レベルは、過度のポートを必要とせずに、入力と出力間の並列性を可能にします。
When a CE chooses to establish a DLCI on a specific laser channel, it sends a SET request directed to this LFB. The request might look like
CEが特定のレーザーチャネルにDLCIを確立することを選択すると、このLFBに向けられた設定要求を送信します。リクエストは次のように見えるかもしれません
T = SET
T = PATH-DATA
Path: flags = none, length = 4, path = 2, channel, 4, entryIdx
DataRaw: DLCI, Enabled(1), false, out-idx
which would establish the DLCI as enabled, with traffic going to a specific entry of the output port group DatatoFE. (The CE would ensure that the output port is connected to the right place before issuing this request.)
これにより、DLCIが有効になり、トラフィックが出力ポートグループDatatofeの特定のエントリに移動するようになります。（CEは、このリクエストを発行する前に、出力ポートが適切な場所に接続されていることを確認します。）
The response would confirm the creation of the specified entry. This table is structured to use separate internal indices and DLCIs. An alternative design could have used the DLCI as index, trading off complexities.
応答は、指定されたエントリの作成を確認します。このテーブルは、個別の内部インデックスとDLCIを使用するように構成されています。代替設計では、DLCIをインデックスとして使用し、複雑さを取引することができました。
One could also imagine that the FE has an LMI LFB. Such an LFB would be connected to the LMItoFE and LMIfromFE port groups. It would process LMI information. It might be the LFB's job to set up the frame relay circuits. The LMI LFB would have an alias entry that points to the frame relay circuits table it manages, so that it can manipulate those entities.
また、FEにLMI LFBがあることを想像することもできます。このようなLFBは、LmitofeおよびLmifromfeポートグループに接続されます。LMI情報を処理します。フレームリレー回路をセットアップするのはLFBの仕事かもしれません。LMI LFBには、管理するフレームリレーサーキットテーブルを指すエイリアスエントリがあり、それらのエンティティを操作できます。
The LFB will receive invalid packets over the wire. Many of these will simply result in incrementing counters. The LFB designer might also specify some error rate measures. This puts more work on the FE, but allows for more meaningful alarms.
LFBは、ワイヤー上に無効なパケットを受け取ります。これらの多くは、単にカウンターを増やすことになります。LFBデザイナーは、いくつかのエラー率測定を指定する場合があります。これにより、FEでより多くの作業が行われますが、より意味のあるアラームが可能になります。
There may be some error conditions that should cause parts of the packet to be sent to the CE. The error itself is not something that can cause an event in the LFB. There are two ways this can be handled.
パケットの一部をCEに送信する必要があるエラー条件がある場合があります。エラー自体は、LFBでイベントを引き起こす可能性のあるものではありません。これを処理できる2つの方法があります。
One way is to define a specific component to count the error, and a component in the LFB to hold the required portion of the packet. The component could be defined to hold the portion of the packet from the most recent error. One could then define an event that occurs whenever the error count changes, and declare that reporting the event includes the LFB field with the packet portion. For rare but extremely critical errors, this is an effective solution. It ensures reliable delivery of the notification. And it allows the CE to control if it wants the notification.
1つの方法は、特定のコンポーネントを定義してエラーをカウントすること、およびLFBのコンポーネントがパケットの必要な部分を保持することです。コンポーネントを定義して、最新のエラーからパケットの部分を保持することができます。その後、エラーカウントが変更されるたびに発生するイベントを定義し、イベントの報告にはパケット部分のLFBフィールドが含まれることを宣言できます。まれであるが非常に重要なエラーの場合、これは効果的なソリューションです。通知の信頼できる配信を保証します。また、CEが通知を必要とするかどうかを制御できます。
Another approach is for the LFB to have a port that connects to a redirect sink. The LFB would attach the laser channel, the DLCI, and the error indication as metadata, and ship the packet to the CE.
別のアプローチは、LFBがリダイレクトシンクに接続するポートを持つことです。LFBは、レーザーチャネル、DLCI、およびエラー表示をメタデータとして取り付け、パケットをCEに出荷します。
Other aspects of error handling are discussed under events below.
エラー処理の他の側面については、以下のイベントで説明します。
This LFB is defined to have two top-level components. One reflects the administrative state of the LFB. This allows the CE to disable the LFB completely.
このLFBは、2つのトップレベルコンポーネントを持つように定義されています。LFBの管理状態を反映しています。これにより、CEはLFBを完全に無効にすることができます。
The other component is the table of information about the laser channels. It is a variable-sized array. Each array entry contains an identifier for what laser frequency this entry is associated with, whether that frequency is operational, the power of the laser at that frequency, and a table of information about frame relay circuits on this frequency. There is no administrative status since a CE can disable an entry simply by removing it. (Frequency and laser power of a non-operational channel are not particularly useful. Knowledge about what frequencies can be supported would be a table in the capabilities section.)
他のコンポーネントは、レーザーチャネルに関する情報の表です。可変サイズの配列です。各配列エントリには、このエントリが関連付けられているレーザー周波数の識別子が含まれています。その周波数が動作しているかどうか、その周波数でのレーザーのパワー、およびこの周波数のフレームリレー回路に関する情報の表が含まれています。CEはエントリを削除するだけでエントリを無効にできるため、管理ステータスはありません。（非運用チャネルの周波数とレーザーパワーは特に有用ではありません。サポートできる周波数に関する知識は、機能セクションのテーブルになります。）
The frame relay circuit information contains the DLCI, the operational circuit status, whether this circuit is to be treated as carrying LMI information, and which port in the output port group of the LFB traffic is to be sent to. As mentioned above, the circuit index could, in some designs, be combined with the DLCI.
フレームリレー回路情報には、この回路がLMI情報を運ぶものとして扱われるかどうか、およびLFBトラフィックの出力ポートグループのどのポートが送信されるかどうか、DLCI、運用回路ステータスであるDLCIが含まれています。上記のように、回路指数は、一部の設計では、DLCIと組み合わせることができます。
The capability information for this LFB includes whether the underlying interface is operational, how many frequencies are supported, and how many total circuits, across all channels, are permitted. The maximum number for a given laser channel can be determined from the properties of the FrameRelayCircuits table. A GET-PROP on path 2.channel.4 will give the CE the properties of that FrameRelayCircuits array which include the number of entries used, the first available entry, and the maximum number of entries permitted.
このLFBの機能情報には、基礎となるインターフェイスが動作しているかどうか、サポートされている周波数の数、すべてのチャネルにわたる合計回路の数が含まれます。特定のレーザーチャネルの最大数は、FramerelayCircuitsテーブルのプロパティから決定できます。Path 2.Channel.4のGet-Propは、使用したエントリ数、最初の利用可能なエントリ、および許可されているエントリの最大数を含むFramerelayCircuitsアレイのプロパティをCEに提供します。
This LFB is defined to be able to generate several events in which the CE may be interested. There are events to report changes in operational state of frequencies, and the creation and deletion of frequency entries. There is an event for changes in status of individual frame relay circuits. So an event notification of 61.5.3.11 would indicate that there had been a circuit status change on subscript 11 of the circuit table in subscript 3 of the frequency table. The event report would include the new status of the circuit and the DLCI of the circuit. Arguably, the DLCI is redundant, since the CE presumably knows the DLCI based on the circuit index. It is included here to show including two pieces of information in an event report.
このLFBは、CEが興味を持っている可能性のあるいくつかのイベントを生成できるように定義されています。周波数の運用状態の変化、および周波数エントリの作成と削除を報告するイベントがあります。個々のフレームリレー回路のステータスの変更に関するイベントがあります。したがって、61.5.3.11のイベント通知は、周波数表のサブスクリプト3の回路テーブルのサブスクリプト11に回路ステータスの変更があったことを示します。イベントレポートには、回路の新しいステータスと回路のDLCIが含まれます。おそらく、CEは回路指数に基づいてDLCIを知っているため、DLCIは冗長です。ここには、イベントレポートに2つの情報を含めて表示されます。
As described above, the event declaration defines the event target, the event condition, and the event report content. The event properties indicate whether the CE is subscribed to the event, the specific threshold for the event, and any filter conditions for the event.
上記のように、イベント宣言では、イベントのターゲット、イベント条件、およびイベントレポートの内容を定義します。イベントのプロパティは、CEがイベントにサブスクライブされているかどうか、イベントの特定のしきい値、およびイベントのフィルター条件を示します。
Another event shown is a laser power problem. This event is generated whenever the laser falls below the specified threshold. Thus, a CE can register for the event of laser power loss on all circuits. It would do this by:
示されている別のイベントは、レーザーパワーの問題です。このイベントは、レーザーが指定されたしきい値を下回るたびに生成されます。したがって、CEはすべての回路でレーザーパワー損失のイベントに登録できます。これを行います：
T = SET-PROP
Path-TLV: flags=0, length = 2, path = 61.4
Path-TLV: flags = property-field, length = 1, path = 2
Content = 1 (register)
Path-TLV: flags = property-field, length = 1, path = 3
Content = 15 (threshold)
This would set the registration for the event on all entries in the table. It would also set the threshold for the event, causing reporting if the power falls below 15. (Presumably, the CE knows what the scale is for power, and has chosen 15 as a meaningful problem level.) If a laser oscillates in power near the 15 mark, one could get a lot of notifications. (If it flips back and forth between 14 and 15, each flip down will generate an event.) Suppose that the CE decides to suppress this oscillation somewhat on laser channel 5. It can do this by setting the hysteresis property on that event. The request would look like:
これにより、テーブル内のすべてのエントリのイベントの登録が設定されます。また、イベントのしきい値を設定し、パワーが15を下回った場合に報告を引き起こします（おそらく、CEはスケールが電力のためのものを知っており、意味のある問題レベルとして15を選択しました。）15マーク、多くの通知を取得できます。（14〜15の間で前後に逆さまになると、各フリップダウンがイベントを生成します。）CEがレーザーチャネル5でこの振動を多少抑制することを決定したと仮定します。このイベントにヒステリシスプロパティを設定することでこれを行うことができます。リクエストは次のようになります：
T = SET-PROP
Path-TLV: flags=0, length = 3, path = 61.4.5
Path-TLV: flags = property-field, length = 1, path = 4
Content = 2 (hysteresis)
Setting the hysteresis to 2 suppresses a lot of spurious notifications. When the level first falls below 10, a notification is generated. If the power level increases to 10 or 11, and then falls back below 10, an event will not be generated. The power has to recover to at least 12 and fall back below 10 to generate another event. One common cause of this form of oscillation is when the actual value is right near the border. If it is really 9.5, tiny changes might flip it back and forth between 9 and 10. A hysteresis level of 1 will suppress this sort of condition. Many other events have oscillations that are somewhat wider, so larger hysteresis settings can be used with those.
ヒステリシスを2に設定すると、多くの偽の通知が抑制されます。レベルが最初に10を下回ると、通知が生成されます。パワーレベルが10または11に上昇してから10を下回ると、イベントは生成されません。パワーは、少なくとも12に回復し、別のイベントを生成するために10未満に戻る必要があります。この形式の振動の一般的な原因の1つは、実際の値が国境の近くにある場合です。本当に9.5の場合、小さな変化は9〜10の間に行き来する可能性があります。他の多くのイベントには、やや広い振動があるため、それらでより大きなヒステリシス設定を使用できます。
The ForCES model creates the need for a unique XML namespace for ForCES library definition usage, and unique class names and numeric class identifiers.
Forceモデルは、Force Libraryの定義使用量と一意のクラス名と数値クラス識別子のための一意のXML名空間の必要性を作成します。
IANA has registered a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
IANAは、RFC 3688 [RFC3688]のガイドラインに従って、新しいXMLネームスペースを登録しています。
URI: The URI for this namespace is
urn:ietf:params:xml:ns:forces:lfbmodel:1.0
Registrant Contact: IESG
登録者の連絡先：IESG
XML: none, this is an XML namespace
XML：なし、これはXMLネームスペースです
In order to have well defined ForCES LFB Classes, and well defined identifiers for those classes, IANA has created a registry of LFB class names, corresponding class identifiers, and the document that defines the LFB class. The registry policy is simply first come, first served (FCFS) with regard to LFB class names. With regard to LFB class identifiers, identifiers less than 65536 are reserved for assignment by IETF Standards-Track RFCs. Identifiers equal to or above 65536, in the 32-bit class ID space, are available for assignment on a first come, first served basis. All registry entries must be documented in a stable, publicly available form.
明確に定義されたLFBクラス、およびそれらのクラスの明確に定義された識別子を持つために、IANAはLFBクラス名、対応するクラス識別子、およびLFBクラスを定義するドキュメントのレジストリを作成しました。レジストリポリシーは、LFBクラス名に関して最初に最初に提供される（FCFS）に最初に来ることです。LFBクラス識別子に関しては、65536未満の識別子がIETF標準トラックRFCによる割り当てのために予約されています。32ビットクラスIDスペースの65536以下の識別子は、先着順で割り当てられます。すべてのレジストリエントリは、安定した公開されているフォームで文書化する必要があります。
Since this registry provides for FCFS allocation of a portion of the class identifier space, it is necessary to define rules for naming classes that are using that space. As these can be defined by anyone, the needed rule is to keep the FCFS class names from colliding with IETF-defined class names. Therefore, all FCFS class names MUST start with the string "Ext-".
このレジストリは、クラス識別子スペースの一部のFCFS割り当てを提供するため、そのスペースを使用しているクラスを命名するためのルールを定義する必要があります。これらは誰でも定義できるため、必要なルールは、FCFSクラス名がIETF定義のクラス名と衝突しないようにすることです。したがって、すべてのFCFSクラス名は、文字列「ext-」から開始する必要があります。
Table 1 tabulates the above information.
表1には、上記の情報が集計されています。
IANA has created a registry of ForCES LFB Class Names and the corresponding ForCES LFB Class Identifiers, with the location of the definition of the ForCES LFB Class, in accordance with the rules in the following table.
IANAは、次の表のルールに従って、LFBクラス名と対応する力LFBクラス識別子の定義の位置を作成し、LFBクラスの定義の位置を作成しました。
+----------------+------------+---------------+---------------------+
| LFB Class Name | LFB Class | Place Defined | Description |
| | Identifier | | |
+----------------+------------+---------------+---------------------+
| Reserved | 0 | RFC 5812 | Reserved |
| | | | -------- |
| FE Object | 1 | RFC 5812 | Defines ForCES |
| | | | Forwarding Element |
| | | | information |
| FE Protocol | 2 | [2] | Defines parameters |
| Object | | | for the ForCES |
| | | | protocol operation |
| | | | -------- |
| IETF defined | 3-65535 | Standards | Reserved for IETF |
| LFBs | | Track RFCs | defined RFCs |
| | | | -------- |
| ForCES LFB | >65535 | Any Publicly | First Come, First |
| Class names | | Available | Served for any use |
| beginning EXT- | | Document | |
+----------------+------------+---------------+---------------------+
Table 1
表1
The following are the authors who were instrumental in the creation of earlier releases of this document.
以下は、このドキュメントの以前のリリースの作成に貢献した著者です。
Ellen Delganes, Intel Corp. Lily Yang, Intel Corp. Ram Gopal, Nokia Research Center Alan DeKok, Infoblox, Inc. Zsolt Haraszti, Clovis Solutions
Ellen Delganes、Intel Corp. Lily Yang、Intel Corp. Ram Gopal、Nokia Research Center Alan Dekok、Infoblox、Inc。Zsolt Haraszti、Clovis Solutions
Many of the colleagues in our companies and participants in the ForCES mailing list have provided invaluable input into this work. Particular thanks to Evangelos Haleplidis for help getting the XML right.
当社の会社の同僚の多くとフォースメーリングリストの参加者は、この作業に貴重な入力を提供しています。XMLを正しく理解してくれたEvangelos Haleplidisに特に感謝します。
The FE model describes the representation and organization of data sets and components in the FEs. The ForCES framework document [RFC3746] provides a comprehensive security analysis for the overall ForCES architecture. For example, the ForCES protocol entities must be authenticated per the ForCES requirements before they can access the information elements described in this document via ForCES. Access to the information contained in the FE model is accomplished via the ForCES protocol, which is defined in separate documents, and thus the security issues will be addressed there.
FEモデルでは、FESのデータセットとコンポーネントの表現と組織について説明しています。Force Framework Document [RFC3746]は、全体的な力アーキテクチャの包括的なセキュリティ分析を提供します。たとえば、Force Protocolエンティティは、Forceを介してこのドキュメントで説明されている情報要素にアクセスする前に、Force要件ごとに認証されなければなりません。FEモデルに含まれる情報へのアクセスは、個別のドキュメントで定義されているフォースプロトコルを介して達成されるため、セキュリティの問題に対処します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010.
[RFC5810] Doria、A.、Ed。、Hadi Salim、J.、Ed。、Haas、R.、Ed。、Khosravi、H.、Ed。、Wang、W.、Ed。、Dong、L.、Gopal、R。、およびJ. Halpern、「転送および制御要素分離（Force）プロトコル仕様」、RFC 5810、2010年3月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[Schema1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, http://www.w3.org/TR/xmlshcema-1/, May 2001.
[Schema1] Thompson、H.、Beech、D.、Maloney、M。、およびN. Mendelsohn、「XML Schema Part 1：Structures」、W3C Rec-Xmlschema-1、http：//www.w3.org/tr/XMLSHCEMA-1/、2001年5月。
[Schema2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, http://www.w3.org/TR/xmlschema-2/, May 2001.
[Schema2] Biron、P。and A. Malhotra、「XML Schema Part 2：Datatypes」、W3C Rec-Xmlschema-2、http：//www.w3.org/tr/xmlschema-2/、2001年5月。
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3654] Khosravi、H。およびT. Anderson、「IP制御と転送の分離の要件」、RFC 3654、2003年11月。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004.
[RFC3746] Yang、L.、Dantu、R.、Anderson、T。、およびR. Gopal、「転送および制御要素分離（Forces）フレームワーク」、RFC 3746、2004年4月。
[RFC3317] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie, "Differentiated Services Quality of Service Policy Information Base", RFC 3317, March 2003.
[RFC3317] Chan、K.、Sahita、R.、Hahn、S。、およびK. McCloghrie、「差別化されたサービスサービスポリシー情報ベース」、RFC 3317、2003年3月。
[RFC3318] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, "Framework Policy Information Base", RFC 3318, March 2003.
[RFC3318] Sahita、R.、Hahn、S.、Chan、K。、およびK. McCloghrie、「Framework Policy Information Base」、RFC 3318、2003年3月。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003.
[RFC3444] Pras、A。およびJ. Schoenwaelder、「情報モデルとデータモデルの違いについて」、RFC 3444、2003年1月。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470] Hollenbeck、S.、Rose、M。、およびL. Masinter、「IETFプロトコル内の拡張マークアップ言語（XML）の使用に関するガイドライン」、BCP 70、RFC 3470、2003年1月。
[UNICODE] Davis, M. and M. Suignard, "UNICODE Security Considerations", http://www.unicode.org/reports/tr36/tr36-3.html , July 2005.
[Unicode] Davis、M。and M. Suignard、「Unicodeセキュリティに関する考慮事項」、http：//www.unicode.org/reports/tr36/tr36-3.html、2005年7月。
Authors' Addresses
著者のアドレス
Joel Halpern Self P.O. Box 6049 Leesburg, VA 20178 USA
Joel Halpern Self P.O.Box 6049 Leesburg、VA 20178 USA
Phone: +1 703 371 3043
EMail: jmh@joelhalpern.com
Jamal Hadi Salim Znyx Networks Ottawa, Ontario Canada
Jamal Hadi Salim Znyx Networks Ottawa、オンタリオカナダ
EMail: hadi@mojatatu.com