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.
この文書は、転送と制御素子分離（のForCES）プロトコルで使用される転送要素（FE）モデルを定義します。制御要素（CEは）それに応じのFEを制御することができるように、モデルは、機能、状態、強制的プロトコルのコンテキスト内で転送要素の構成を表しています。具体的には、モデルは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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................5
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]はのForCESプロトコルを使用してネットワーク要素（NE）内の1つ以上の別個の転送要素（FE）を設定し、管理することができる要素（CES）を制御することにより、フレームワークを指定します。 ForCESアーキテクチャは、様々な機能の転送要素はのForCESネットワーク要素に参加することを可能にします。この様々な機能の含意はCEがNEでのFEによって提供される機能についてのみ、最小限の仮定を行うことができるということです。 CEがFEでの転送動作を設定し、制御することができます前に、CEは自分のFEの能力や状態を照会し、発見する必要があります。 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）とデータモデル（DMS）が異なっていることを観察しました。 「IMの主な目的は、使用される任意の特定の実装やプロトコルとは無関係に、概念レベルで管理オブジェクトをモデル化することです」。 「DMSは、逆に、抽象化の低いレベルで定義され、多くの詳細が含まれる。これらは、実装のために意図されており、プロトコル固有の構築物が含まれます」。時には両者の間に明確な線を引くことは困難です。この文書に記載されFEモデルは、主に情報モデルであるが、そのようなLFB（論理的な機能ブロック）クラススキーマおよびFEスキーマの明示的な定義として、データモデルのいくつかの局面を含みます。なお、このFEモデルのForCESプロトコルにおける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]はのForCES FEモデルが満たすべき要件を定義します。要約すると、FEモデルを定義する必要があります。
o Logically separable and distinct packet forwarding operations in an FE data path (Logical Functional Blocks or LFBs);
FEデータパスにおけるO論理的に分離した別個のパケット転送動作（論理的な機能ブロックまたはLFBs）。
o The possible topological relationships (and hence the sequence of packet forwarding operations) between the various LFBs;
種々LFBs間の可能な位相関係（したがって、パケット転送動作のシーケンス）O。
o The possible operational capabilities (e.g., capacity limits, constraints, optional features, granularity of configuration) of each type of LFB;
可能な動作能力LFBの各タイプの（例えば、容量制限、制約、オプション機能、構成の粒度）O。
o The possible configurable parameters (e.g., components) of each type of LFB; and
LFBの各種類の可能な構成可能なパラメータ（例えば、成分）O。そして
o Metadata that may be exchanged between LFBs.
LFBsとの間で交換されてもよいOメタデータ。
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モデルは有向グラフで相互接続された別個の論理的な機能ブロック（LFBs）を使用して抽象化に基づいて、および受信、処理、修正、およびメタデータと一緒にパケットを送信します。 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トポロジーモデルが正しくパケット上の一連の操作をキャプチャする必要があります。特定LFBsによるメタデータの生成は常に、トポロジ・グラフにおける後続LFBsによってそのメタデータの使用に先行しなければなりません。これは、論理的に一貫性のある動作のために必要とされます。さらに、その後さらなる処理のための入力として使用されているパケットフィールドの変更は、正確さを確保するために、その特定の実施のためのモデルで指定された順序で発生しなければなりません。
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.
ForCESベースプロトコル[RFC5810]はCEとFEとの間の通信チャネルを維持するために、CEとFEによって使用されます。 ForCESプロトコルは、イントラFEトポロジを照会し、発見するために使用することができます。 LFBトポロジを含むFE内の特定のデータ経路の実装の詳細は、各個々のLFBの動作能力と属性とともに、のForCESプロトコルの情報要素内の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
オブジェクトの正式な定義は（FEとLFBs内）を設定および管理されることなく、体系的なファッションの力メッセージの様々なペイロードを指定することは困難です。 FEモデル文書は、FE内LFBsの状態を説明し、操作するためのクラスおよびコンポーネントのセットを定義します。これらのクラス定義自体は、一般的には表示されません
ForCES protocol. Rather, ForCES protocol operations will reference classes defined in this model, including relevant components and the defined operations.
ForCESプロトコル。むしろ、のForCESプロトコルの動作は、関連するコンポーネントと定義される操作を含むこのモデルで定義されたクラスを参照します。
Section 7 provides more detailed discussion on how the FE model should be used by the ForCES protocol.
セクション7は、FEモデルのForCESプロトコルによって使用されるべき方法のより詳細な説明を提供します。
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モデルを表現するために、正式なデータモデリング言語を使用することが有益です。形式言語の使用はLFBsの間で一貫性と論理的な互換性を強制することができます。完全な仕様は、データモデリング言語を使用して書き込まれます。 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は、広く利用可能なツールをサポートして読める人間と機械の両方であるという利点を持っているので、このドキュメントの仕様記述言語として選択されています。この文書では、[RFC3470]で定義されるように、LFBライブラリ文書の構造を定義するXMLスキーマを使用し、[SCHEMA1]と[SCHEMA2]。これらLFBクラス定義は、のForCESプロトコルで送信されていないが、これらの定義は、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.
LFBライブラリ文書の構造を定義するXMLスキーマを使用することにより、我々は、このドキュメントで取り上げたい意味記述と制限して行くための構文の制限の非常に明確なセットを持っています。それは構文の変更が必要であると判断された場合には当然の帰結として、その後、新しいスキーマが必要になります。これは、新しいスキーマの名前空間を識別するために、別の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モデルの概念的な概要を提供します。 FE機能とLFBトポロジー情報を含むそのコンポーネントと、一般的なLFBモデルとFEオブジェクトLFBの定義：第4及び第5節では、FEモデルの二つの主要な側面を詳細に、FEモデルのコアを構成します。セクション7は、FEモデルはのForCESプロトコルで使用されるべき方法を説明しながら部6は、直接、RFC 3654 [RFC3654]で定義のForCES要件によって課さモデル要件に対処します。
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.
コンプライアンスの用語（MUST、SHOULD、MAY、NOTなければならない）の使用は、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.
ForCES要件に関連付けられている用語は、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モデリング、LFBs間の論理的な相互接続（LFBトポロジ）、およびFE機能など、FEレベルの属性、。 FEモデルは、のForCESプロトコル[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処理のきめ細かい、論理的に分離可能な態様を表すテンプレート。ほとんどのLFBsは、データパスの処理をパケットに関連します。 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を通って流れるように、それは各LFBが特定LFBクラスのインスタンスを1つのまたは複数LFBインスタンス、流れます。同じLFBクラスの複数のインスタンスは、FEのデータパスに存在することができます。我々は暗黙の参照が与えられた文脈に明らかであると考えていたときに私たちは、多くの場合、LFBクラスとLFBのインスタンスを区別せずにLFBsを参照していることに注意してください。
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は、モデリングのために必要な構造の正式な定義を提供するために使用されます。情報の4種類のLFBモデルで定義されています。 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.
element：要素は、一般的用語のXMLの使用状況に合わせて、このドキュメントで使用されています。これは、XML文書の一部をタグ付けされたXMLを指します。正確な定義については、W3CからXML仕様のフルセットを参照してください。 ForCES正式なモデルは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からパケット単位の状態を通信するために使用されるが、ネットワークを介して送信されていません。 FEモデルは、どのようなメタデータを定義し、識別された生成、及びLFBsによって消費されるが、パケットごとの状態は、実際のハードウェア内に実装されていないどのようにしています。メタデータは、リダイレクトパケットに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.
ForCESコンポーネント：のForCESコンポーネントは、明確に定義され、一意に識別およびアドレス指定可能のForCESモデル構築ブロックです。コンポーネントは、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コンポーネントはCEに見えなければならないLFBsの動作パラメータを定義するのForCES成分です。
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データ定義で使用される複雑なデータ構造の一部であるのForCESコンポーネント。データの構造化されたセットを構成する個々の部品は、構造コンポーネントと呼ばれます。これらは、それ自体がテーブルや構造を含む、任意の有効なデータ型を使用できます。
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.
プロパティ：のForCESコンポーネントは、読みやすさ、それらに関連付けられた特性を有します。他の例としては、可変サイズのコンポーネントの長さを含みます。これらの特性は、読み取るための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トポロジは、論理配線一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）内の複数のFEが相互接続されている方法の表現です。時にはこれは、イントラFEトポロジ（すなわち、LFBトポロジー）と区別するために、インターFEトポロジと呼ばれています。個々のFEは、フルFEトポロジのグローバルな知識を持っていないかもしれませんが、他のFEとの接続のローカルビューは、FEモデルの一部であると考えられています。 FEトポロジはのForCESベースのプロトコルによって、あるいは他の手段によって発見されました。
Inter-FE Topology: See FE Topology.
インター-FEトポロジ：FEトポロジを参照してください。
Intra-FE Topology: See LFB Topology.
イントラ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クラスライブラリは、ほとんどのフェスに見られる最も一般的な機能として同定されており、したがってのForCESワーキンググループで最初に定義されるべきである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.
この文書全体で使用される重要なのForCESの概念のいくつかは、このセクションで紹介されています。これらは、異なるモデル構造のアドレス指定能力と状態の抽象化、FEとLFBモデル構築、およびユニークが含まれます。これらの態様の詳細は、このセクションの目的は、高いレベルでこれらの概念を議論し、次のセクションでの詳細な説明のための基礎を築くことにあるセクション4とセクション5に記載されています。
The ForCES FE model includes both a capability and a state abstraction.
ForCES 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.
状態モデルは、FE / LFBの現在の状態を記述するO、すなわち、瞬時値または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節は、能力モデルと状態モデルとの違いを説明し、2はFEモデルで組み合わせることができる方法を説明します。
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.
このドキュメントにレイアウトのForCESモデル構築は、FEは、操作のために、その構造についての情報を提供することができます。これは、FEによって提供LFBsの個々のインスタンスについて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強制モデルは、FEがサポートすることができることを論理的な機能ブロック（LFBs）のクラスを定義するための構成を含みます。これらのクラスは、これと他の文書で定義されています。そのようなクラスの定義は、監視、強制的目的のためのLFBクラスのインスタンスを制御するための情報コンテンツを提供します。各LFBモデルクラスは正式に運用LFBコンポーネント、LFB能力、およびLFBイベントを定義します。基本的に、3.2節ではのForCESモデルの基本的な機能ビルディング・ブロックとしてLFBsの概念を導入しています。
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、FEオブジェクトLFBクラスおよびそのクラスの特異LFBインスタンスとして表さLFBモデルを用いて定義されます。 FEオブジェクトクラスは、粗いレベルで、FEレベルで、すなわち、すべての可能な能力またはFEの機能に関するすべての詳細をFE特に能力情報を提供するコンポーネントを定義します。 FEレベルの情報の一部は、FE内のデータ経路（S）に沿ってLFBインスタンス間の論理相互接続を発現LFBトポロジです。 3.3節は、LFBトポロジについて説明します。 FEオブジェクトもLFBクラスFEがサポートできるかについての情報が含まれています。
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.
ForCESモデルは、それが定義され、異なる構築物の固有の識別を可能にします。これは、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:
ForCESプロトコル[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.
FE内でO、各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は、FE状態、能力、強制的プロトコルを介してCE-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：FE機能、状態、及び力によりCE-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].
1が完全にFE能力を表すために、オブジェクトモデルを構築しようとすることができますが、他の努力は、このアプローチが重要な仕事であることが判明しました。主な困難は、分類、キュー、バッファプール、およびFEが提供できるメートルの最大数などの詳細な制限を説明する際に生じます。私たちは、シンプルさと柔軟性の間の良好なバランスが、エラー報告メカニズムを粗いレベルの能力の報告を組み合わせることにより、FEモデルのために達成することができることを信じています。それは、CEは、それがサポートすることはできませんいくつかの特定の動作を設定するにはFEを指示しようとした場合、FEは、問題を示すエラーを返します、です。同様のアプローチの例は、DiffservのPIB RFC 3317 [RFC3317]とフレームワーク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レベルのコンポーネントを定義が記載されて情報。すべての情報がLFBsとして表されるので、これはFEオブジェクトLFBクラスの単一のインスタンスによって提供されます。既知のLFBクラスと既知のインスタンス識別との単一のインスタンスを使用して、のForCESプロトコルは、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のレベルは、これらの個々LFBs注文と完全転送プレーンのサービスを提供するために、データ経路に沿って配置されている方法を説明します。 LFBsの相互接続および順序は、LFBトポロジと呼ばれています。セクション3.3は、LFBトポロジーの問題について説明し、一方、セクション3.2は、LFBs周りに高レベルの概念を説明します。このトポロジ情報は、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は、典型的には、単一のアクションを実行します。分類、シェーパ、およびメーターは、LFBsのすべての例です。このような細かい粒度でLFBsをモデル化することは私たちは今度はより複雑なネットワーク機能とソフトウェアとハードウェアのベンダの実装を記述することができ、正確に（例えばIPv4のフォワーダのような）高次FE機能を発現するためにLFBsの小さな数を使用することを可能にします。これらのきめ細かいLFBsは、このモデルで材料を使用して、個別に出版される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.
またLFBsが特定のパケットまたはデータ・パスの特定の部分への制御を結ぶことなく、CE（制御即ち、軌跡）によってFE動作の制御のためのコンポーネントのセットを提供するために存在することができる場合です。そのようなLFBの例は、全体としてFEに関する情報をCEを提供FEオブジェクトであり、そのようなデータパス自体として、FEは、FEのいくつかの局面を制御することを可能にします。このようなLFBsは、このセクションで説明するパケット指向特性を有していないだろう。
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に示すように、複数LFBsは一つFEに含まれ、そして全てLFBsはのForCESプロトコルロジックを実装し、およびCEから通信チャネルを維持同一のForCESプロトコル（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.
LFBは、図2に示すように、Fpの基準点（[RFC3746] RFC 3746で定義される）、強制的プロトコル終端点を介して照会およびCEによって操作することができる入力、出力、および構成要素を有していてもよいです。横軸は同じFE内LFBsの入力と出力を接続するための転送プレーンです。 （変形例を示すマーク付き）Mは、パケットに関連付けられたメタデータを示している（変形例を示すマーク付き）Pは、データパケットを示しています。 FE-に-CE通信であるのに対し、CE-に-FE通信は、構成、制御、およびパケット注入するためのものである：CEとFEとの間の縦軸は、CEとFEとの間の双方向通信が発生したFPの基準点を表しますパケット制御プレーンへのリダイレクト、モニタリングの報告と会計情報、エラーの報告などに使用するCEとLFBの間の相互作用のみを抽象的かつ間接的なものであることに注意してください。このような相互作用の結果は、LFBインスタンスのコンポーネントを操作するためのCEのためのものです。
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出力ポート定義に応じ。出力上のパケットに取り付けられたメタデータが受信されたメタデータであってもよいし、フェスのパケット処理の後のLFBsによって使用されてもよいパケット処理に関する情報であってもよいです。
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.
名前空間は、各LFBクラスに一意の名前とIDを関連付けるために使用されます。新しい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は、ヘッダの変更（例えば、トンネルヘッダ追記またはストリップ）の種類のFEによって実行される理解する必要があります。さらに、CEは、FE内のデータ経路に沿った様々なLFBsが一緒にリンクする互換性があることを確認するために働きます。互換性のない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の機能を実現する物理デバイスがFEデザインに容易に統合することができるようにLFBクラスの動作が十分に詳細に表現することができる場合、ベンダーに価値があります。しかし、モデル、およびLFBsの関連するライブラリは、大幅な実装を制約するように詳細なので、具体的であってはなりません。したがって、半正式な仕様が必要です。すなわち、LFB動作のテキスト記述（人間が読める）であるが、異なるCEとFEとの間の相互運用性を達成することができるように、適合性試験および効率的な設計を可能にするのに十分に特異的で明白。
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
CEに通知して、LFBによって検出することができるOイベント
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に概念的ポートです。そのポートに送信された情報は空であってもよい一方がパケットと関連したメタデータの組です。 （両方が空だった場合は、何も出力もないでしょう。）
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出力は、唯一のLFB入力に接続することができます。これは、明確なLFBトポロジを介してパケットの流れを作るために必要とされます。
Some LFBs will have a single output, as depicted in Figure 3.a.
いくつかのLFBsは、図3.A.に示されるように、単一の出力を持つことになります
+---------------+ +-----------------+
| | | |
| | | OUT +-->
... OUT +--> ... |
| | | EXCEPTIONOUT +-->
| | | |
+---------------+ +-----------------+
a. One output b. Two distinct outputs
A。一つの出力b。二つの異なる出力
+---------------+ +-----------------+
| | | 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。一つの出力グループD。一つの出力と1つの出力グループ
Figure 3: Examples of LFBs with various output combinations.
図3：種々の出力組み合わせでLFBsの例。
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出力が必要とされています。複数シングルトン出力と出力グループ、同じLFBクラスで組み合わせることができる：2つのメカニズムがフォークのために提供されます。
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（最長プレフィックスマッチング）LFBはLPMルックアップが成功したため、これらのパケットを送信するために一つの出力（OUT）、メタデータとしてMETA_ROUTEIDを渡すを有していてもよいです。そして、LPMルックアップが失敗したときに例外パケットを送信するための別の出力（EXCEPTIONOUT）を持っています。この例を図3.B.に描かれていますパケットは異なる下流の処理を必要とこれら二つの出力によって放出されるだけでなく、それらは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インスタンス間で異なることができます。クラス定義は、下部および/または出力の数に上限を含んでいてもよいです。また、設定のFEため、FE能力情報は、特定LFBsのための特定の出力グループ内のインスタンスの数にさらなる制限を定義することができます。グループ内の出力インスタンスの実際の数は、静的トポロジの読み取り専用され、そして動的トポロジの読み書きLFBインスタンスの構成要素です。グループ内の出力インスタンスは、0からN-1まで、順番に番号を付け、およびLFB内からアドレス可能であるれます。出力ポートグループを使用するには、LFBは、各パケットのためにある特定の出力インスタンスを選択するための組み込みのメカニズムを持っている必要があります。このメカニズムは、クラスのテキスト定義で説明し、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.
例えば、その唯一の目的各到着パケットに関連付けられたメタデータのいずれかに基づいてN下流経路のいずれかにパケットを向けることであるリダイレクタLFBを考えます。このようなLFBは、かなり万能で、トポロジ内の多くの異なる場所で使用することができます。例えば、カラーmetadatumにおけるフレームタイプのmetadatumにおけるパケットの種類、又はパケットレートクラスを記録LFBsを与えられ、1月には、分岐のため、これらのメタデータを使用します。リダイレクタは、フレームタイプのmetadatumに基づいて、IPv4とIPv6の経路へのデータパスを分割するために使用することができる（N = 2）、又はカラーmetadatumを使用して（赤、黄、緑を計量した後、速度固有のパスにフォークする; 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は出力インスタンスにmetadatum値をマッピング設定セレクタテーブルを有していてもよいです。
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
他のLFBsも同様の適応フォーク機能で構築するために、出力グループの概念を使用することができることに注意してください。例えば、1つの入力N出力を有する分類器LFBは、出力グループの概念を使用することによって容易に定義することができます。代替的に、明示的なN出力との組み合わせにおける1つのシングルトン出力と識別器LFBリディレクタ
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モデルと同じ処理動作。特定の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つの出力の種類、OUT、通常のパケット出力のために、とEXCEPTIONOUTを、持っています。通常のOUTは、複数のインスタンスを持っています。したがって、出力グループです。
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クラスが一つの出力、複数シングルトン出力、一つ以上の出力基、またはそれらの組み合わせを定義することができます。 LFBは、データパスと、以下の条件の少なくとも一つの保持をフォークを提供する必要がある場合、複数のシングルトン出力が使用されるべきです。
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は、データパスと、次の条件ホールドの少なくとも一つをフォークを提供しなければならないときに出力基が適切です。
o the number of downstream directions is not known when the LFB class is defined
LFBクラスが定義されているときに下流方向の数は知られていないO
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が他LFBsから情報を受け取ることが可能なLFBに概念的ポートです。情報は、典型的には、パケットの組とそれに関連するメタデータです。パケットまたは一部LFBsのメタデータの月と、いくつかの状況のいずれかが空です。その後、入力がないと彼らは両方とも、空にすることはできません。
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）を使用します。ほとんどのLFBsは一つだけシングルトンの入力を持つことになります。モデルが複数のLFB出力が同じLFB入力に接続することができるので、単一の入力に多重化が可能です。このプロパティは、LFBクラスに特別の規定なしLFB入力に適用されます。上流LFBsからのパケットがフレームタイプおよび付随するメタデータに類似しており、同様の処理を必要とする場合、単一の入力に多重化が適用可能です。このモデルは、複数のパケットが同時に到着したときにどのように扱われるか潜在的な競合に対処しないことに注意してください。競合処理が明示的にモデル化する必要がある場合は、他の二つのモデリングソリューションの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.
ファンインをモデル化する第二の方法は、個別に定義されたシングルトン入力（図4.B）を使用します。このモデルは、LFBがパケットストリームの異なるタイプを処理する必要がある状況では、LFB内部入力固有の処理を必要とし、ここで、LFBクラスが定義されている場合、このような異なる場合の数が既知であるために意味されます。例えば、レイヤ2デカプセル化（3層に）およびレイヤ3カプセル（2層に）の両方を行うことができるLFBは、2つの入力、レイヤ2つのカプセル化解除するためのフレーム、及びレイヤカプセル化のための3つのフレームを受信するための1つを受信するための1つを有していてもよいです。このLFBタイプはその入力、メタデータの異なるセットを持つそれぞれに異なるフレーム（L3対L2）を想定し、したがってこれらの入力に到着するフレームに異なる処理を適用します。このモデルは、明示的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は、単一の入力を介して複数の上流LFBsと接続します。
+--------------+ +------------------------+
| LFB X +---+ | |
+--------------+ +-->|layer2 |
+--------------+ | |
| LFB Y +------>|layer3 LFB |
+--------------+ +------------------------+
(b) An LFB connects with multiple upstream LFBs via two separate singleton inputs.
（b）はアンLFBは、2つの別個のシングルトン入力を介して複数の上流LFBsと接続します。
+--------------+ +------------------------+
| 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）AスケジューラLFBはLFBパケットから来ているキューを区別するために、入力グループを使用します。
Figure 4: Examples of LFBs with various input combinations.
図4：様々な入力の組み合わせとLFBsの例。
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.
ファンインをモデル化する第三の方法は、入力されたグループの概念を使用します。概念は、前のセクションで導入された出力グループに類似しており、図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.
入力グループの例として、スケジューラLFBは、図4.C.に示さ検討そのようなLFBは、入力されたインスタンスの数を介して、キューLFBsの数からパケットを受信し、競合解決およびスケジューリングを制御するために、入力されたインデックス情報を使用します。
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つの入力、複数シングルトン入力、一つ以上の入力基、またはそれらの組み合わせを定義することができます。任意の入力が同じ入力に対して複数の出力を接続を介して同様のパケットストリームの暗黙的な多重化を可能にします。競合処理のいずれかを明示的に扱われなければならない場合、またはLFBクラスがパケットストリームの異なるタイプの既知の数を受信して処理する必要がある場合、明示的な複数シングルトン入力が有用です。競合処理が明示的にモデル化しなければならないときに、入力基が好適であるが、入力の数は、クラスから固有でない（したがって、クラスが定義されているときには知られていない）、または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から渡された状態です。パケットを渡されたメタデータは、そのパケットを処理するために、後続のLFBsを支援します。
The ForCES model defines metadata as precise atomic definitions in the form of label, value pairs.
ForCESモデルは、ラベル、値のペアの形式で正確な原子の定義などのメタデータを定義します。
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).
ForCESモデルは、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.
インターFEメタデータ、即ち、メタデータ交差のFEはこのメタデータに意味的に類似する可能性があるが、この文書の範囲外です。
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).
各metadatum、ラベル情報のタイプを識別する<ラベル、値>対としてモデル化される（例えば、「色」）、その値は、実際の情報（例えば、「赤」）を保持します。ここでラベルは、テキストラベルとして示されているが、プロトコル処理のためには、一意の数値（識別子）に関連付けられます。
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.
LFBs間の相互運用性を確保するために、その入力（S）とどのようなメタデータが、それはその出力（S）の「生成」にLFBクラス「読み込み」または「消費」をメタデータかを定義しなければなりませんLFBクラス仕様。最大の拡張性のために、この定義は、メタデータは、消費者のLFB用から来ることが予想されても、与えられたプロデューサーLFBのためのメタデータを消費することが期待されているLFBs LFBsどのどちらを指定する必要があります。
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.
所与のパケットの経路上の所与metadatumため、そのmetadatumを作成し、そのmetadatumを必要とする少なくとも一つの消費者LFBであるべきである少なくとも一つのプロデューサ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.
ForCESモデルでは、metadatumのプロデューサとコンシューマLFBsが隣接するように要求されません。また、同じmetadatumのために複数の生産者と消費者があるかもしれません。パケットパスは同じmetadatumの複数のプロデューサを伴う場合、その後の生産者は、そのmetadatum値を上書きします。
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は、パケットに関するメタデータのいくつかの部分が生じる可能性があります。最初metadatumは、IPプロトコル（TCP、UDPは、SCTP、...）実行されるかもしれない、と二つの追加のメタデータ項目は、送信元と宛先ポート番号であるかもしれません。これらの追加のメタデータ項目は、それらが唯一のポート番号を使用するプロトコルのために生成されるように、第1 metadatumの値（IPプロトコルを実施）を条件としています。条件付きのメタデータの場合には、「条件」のメタデータが生成されるLFBの定義から決定することが可能であるべきです。 LFBの消費者の行動は、つまり、LFBは、その動作に必要なメタデータは、単位の入力ポートグループに基づいて、LFBクラス定義で定義されています。入力ポート群は、所与metadatum「を必要とする」ことができる、または「任意」の情報として扱うことができます。後者の場合、LFBクラス定義は、明示的に任意のメタデータが提供されない場合に何が起こるかを定義しなければなりません。一つのアプローチは、各オプションmetadatumのデフォルト値を指定し、デフォルト値は、パケットが設けられていない任意のメタデータのために使用されると仮定することです。
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をブラックボックスと見なされる場合は、以下のいずれかの操作は、各アクティブmetadatum上で実行されます。
* IGNORE: ignores and forwards the metadatum
* IGNORE：metadatumを無視して、転送
* READ: reads and forwards the metadatum
* READ：metadatumを読み取り、転送
* READ/RE-WRITE: reads, over-writes, and forwards the metadatum
* READ / RE-WRITE：過剰書き込み、読み込み、metadatumを転送
* WRITE: writes and forwards the metadatum (can also be used to create new metadata)
* WRITE：書き込み、metadatumを転送します（また、新しいメタデータを作成するために使用することができます）
* READ-AND-CONSUME: reads and consumes the metadatum
* CONSUME READ-AND-：metadatumを読み取り、消費
* CONSUME: consumes metadatum without reading
* CONSUME：読書なしmetadatumを消費
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に送信されたときにmetadatumがパケットを転送していないことを意味し、metadatumのライフサイクルを終了します。
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.
ForCESモデルでは、新しいmetadatumはLFBパケットをLFBによって受信されたときに存在しなかったmetadatum型への書き込み動作を適用LFBによって生成されます。このような暗黙の作成は、LFBによって意図しないであってもよく、つまり、LFBは知ら又は所与metadatumが存在するか否かを気にすることなく書き込み動作を適用することができます。それが存在する場合は、metadatumは上書きされます。それは存在しなかった場合、metadatumが作成されます。
For LFBs that insert packets into the model, WRITE is the only meaningful metadata operation.
モデルにパケットを挿入LFBsため、WRITEのみ意味のあるメタデータ操作です。
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.
モデルからパケットを削除LFBsためのパケットに関連付けられた各アクティブmetadatumを、それらが読取り及び消費する可能性のいずれか（読み取り）、又は摂取（無視します）。
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.
動作中に、種々の条件がLFBsによって検出することができる起こり得ます。例としては、リンク障害からの範囲または特殊目的LFBsのタイマ満了に再起動します。 CEは、このような事象の発生を通知することを希望することがあります。どのようなメッセージの説明が送信され、そしてそれらのフォーマットは、転送および制御素子分離（のForCES）プロトコル[RFC5810]ドキュメントの一部です。このような状況は理解しているかを示すことは、このモデルの仕事の一部です。
Events are declared in the LFB class definition. The LFB event declaration constitutes:
イベントは、LFBのクラス定義で宣言されています。 LFBイベント宣言は、構成します：
o a unique 32-bit identifier.
一意の32ビット識別子O。
o An LFB component that is used to trigger the event. This entity is known as the event target.
イベントをトリガするために使用されるLFB成分O。このエンティティは、イベントターゲットとして知られています。
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.
CEへのイベントの発生につながるイベントターゲットに起こる症状O。条件の例としては、等が作成または削除取得何か、設定の変更を含み、
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上のどの条件FEは、このようなイベントをトリガするために検出する必要がありLFBコンポーネントを監視し、どのように報告するLFB成分（S）のどの部分定義しますイベントがトリガされる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クラス定義によって宣言することができるが、ランタイム活性（セクション3.2.6で説明した）LFBコンポーネントのプロパティを使用して、組み込みイベントプロパティを使用して制御されます。 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.
（LFBクラス定義時に宣言された）イベントターゲットに起こって何かの1.検出。処理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.
LFBイベントターゲット上（LFBクラス定義時に宣言された）状態の2.チェック。条件が満たされた場合、次のステップに進みます。
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.チェック（ランタイムセット）イベント・フィルター彼らは、イベントが報告または抑制される必要があるかどうかを確認するために存在する場合。イベントを報告する場合は、次のステップに進みます。
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.
LFBsと構造は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クラスのバージョンは、クラス定義内のバージョン文字列を必要とすることによってサポートされています。 CEは、下位互換性を提供するために、特定のLFBクラスの複数のバージョンをサポートするかもしれないが、FEが特定のクラスの複数のバージョンをサポートしてはなりません。
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ベンダーが標準化されたLFBsにベンダー固有の拡張機能を追加することができます。 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クラスが定義されるべきです。
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
クラス継承に関連する興味深い問題が子孫と先祖クラス間の下位互換性です。標準化されたLFBクラス「L1」が存在する以下の仮定のシナリオを検討してください。ベンダAは、LFB「L1」を実装FEを構築し、そしてベンダーBは認識しLFB「L1」上で動作することができるCEを構築します。新しいLFBクラス、「L2」は、インクリメンタルその機能を拡張することにより、既存の「L1」クラスに基づいて定義されていると。私たちは、ベンダーBベンダーCさんを「L2」を「L1」からそのFEをアップグレードしたらどうなるか考慮することにより、FE下位互換性の問題を調べてみましょう
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".
CEは変更されません。派生LFBクラス「L2」は確かに、基本クラス「L1」との後方互換性があるかどうか、古いL1ベースのCEは、新しい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.
逆のシナリオでは、はるかに少ない問題の場合、すなわち、新たなLFBクラス「L2」が、FEにCEベンダーBのアップグレードがアップグレードされません。限り、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は、異なる力のモデルエンティティの抽象化を示しています。 ForCESプロトコルは、一意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.
説明アドレッシングスキーム用い、メッセージはのForCESプロトコルを利用して、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.
例では、3つの32ビットコンポーネント識別子1を有する成分、31、及び51 LFBのComponentID 51は、その中にLFBのComponentID 89 LFBのComponentID 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成分は、テーブルのような複雑な構造、又はそのような細胞をさらにテーブルであるテーブル、等のForCESモデルXMLスキーマ（第4）のようなさらに複雑な構造とすることが一意にそのような複雑さを持つものを識別することができますことができ、キーから導出される経路のアドレッシングドット注釈付き静的パスとコンテンツの概念を利用します。 LFBのComponentID 51は、構造、LFBのComponentID 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はテーブル（アレイ）を表すかもしれないのComponentID。その場合、テーブルの7項目の中からID 89とLFBのコンポーネントを選択するために、一方がパス51.7.89を使用します。点線のパスのインデックスを含めることによって、明示的な表要素選択をサポートすることに加えて、モデルは、その内容によって表要素を識別するサポート。これを使用して、キー、またはキーインデックスと呼ばれています。だから、のComponentID 51はキーインデックスできたテーブルであれば更なる例としては、コンテンツを記述するキーもテーブルを選択するパス51と共に、CEによって通過することができ、そして選択するために、パス89に続いてFEによって計算際LFBに解決なる表構造要素は、指定されたテーブル・エントリ内の89のComponentID。
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に入ってくるパケットは、一般に、出口ポートから出る前に、一つ以上のLFBs流れます。どのFEは、パケットを処理することはどのパケットに影響を与えることができるなど、パケットの種類（例えば、IPv4の、IPv6の、またはMPLS）、ヘッダ値、到着時刻、LFB処理の結果として、多くの要因に依存します下流LFBsで処理されます。パケット処理のこの区別は、下流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トポロジはLFBインスタンスと次の1つのLFBからパケットフローの方向を示す有向リンクを表すノードと、FE内の論理データパスの有向グラフ表現です。 3.4.1は3.4.2がLFBトポロジの再構成に関連する問題に焦点をあてながら、FEデータパスは、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つの基本的な方法があります。一つは直接グラフ（トポロジーアプローチ）データパスを表し、他方はメタデータ（符号化された状態のアプローチ）を利用します。
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の演算の結果は、下流LFBsにパケットとともに渡されるmetadatumに符号化することができます。下流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内のすべてのデータパスを記述するために単一の純粋なアプローチを使用することを検討できるように、他の代用可能性があります。しかし、それだけでどちらのモデルでは、すべての事実上の関連する例のための最高の表現になります。非常に異なる探しLFBトポロジグラフにつながる二つの異なるモデリング手法を適用する特定の論理データパスを有する所定FEため。のみトポロジカルなアプローチを使用してモデルは、すべての代替データ経路を発現するように多くのリンク又は経路、及びノード（すなわち、LFBインスタンス）を有する非常に大きなグラフを必要とするかもしれません。一方、唯一の符号化された状態のモデルを用いたモデルは、（例えば、MPLSとIPv4など）の異なるデータパスを記述するための直感的な方法ではないLFBsの文字列に制限されることになります。したがって、これら2つのアプローチの組み合わせは、おそらく実用的なモデルに使用されます。我々は以下示すように実際には、2つのアプローチがあっても同じLFB内で混合することができます。
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.
他のLFBs続くN分類出力を有する分類器の単純な例を用いて、図7.AはLFBトポロジが純粋な位相的アプローチを使用するときにどのように見えるかを示しています。分類器からの各出力にはメタデータが必要とされていないNのLFBsのいずれかになります。トポロジカルなアプローチは、シンプル、簡単、かつグラフィカルに直感的です。しかし、Nが大きく、分級（LFB＃1、LFB＃2、...、LFB＃N）のすべてを、次のN個のノードが同じLFBの種類（例えば、メートル）に属しているが、それぞれが独自の独立したコンポーネントを持っている場合図7.b.に示すように、符号化された状態アプローチは、はるかに単純なトポロジの表現を与えます符号化された状態のアプローチは、メーターコンポーネントのN行のテーブルが1メートルインスタンスの属性を表す各列と、メーターノード自体に設けられていることが必要です。 metadatum Mはまた、メータが任意に使用されるべき属性の対応する行を検索するためにルックアップキー（インデックス）としてMを使用できるように、計器へ分類器からのパケットPと一緒に通過するために必要とされます特定のパケット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）は図5（a）にLFBトポロジを表現するために、純粋な符号化された状態のアプローチを使用して、LFB＃1と、LFB＃2、...、およびLFB＃Nは、同じタイプ（例えば、メートル）です。
+-------------+
+-------------+ (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）は、2つの組み合わせを使用して、LFB＃1の場合、LFB＃2、...、およびLFB＃Nは、異なるタイプ（例えば、キュー及びメートル）です。
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インスタンス間で必要とされている次のノードが解釈、したがって異なるパケット処理を呼び出すことができるメタデータ。このような場合のために、より多くの接続で精巧なグラフを構築するために、純粋な位相幾何学的なアプローチを強制的に1としばしば扱いにくいグラフになります。一方、トポロジー的アプローチは、機能的に異なるデータパスを表すための最も直感的です。
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.
複雑なトポロジの場合は、両者の組み合わせが最も柔軟性があります。一般的な設計指針は、最高の特定の状況のために使用されたアプローチを示すために提供されます。ファンアウトは、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).
頻繁に変更する必要があるコンフィギュレーション情報は、一つ以上のLFBsの内部属性を使用して（したがって、符号化された状態のアプローチを使用して）で表されるべきです。
+---------------------------------------------+
| |
+----------+ 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は、一つの単純なFEの例を示しています。この例では、VPN等のIPsecアプリケーションからIPインIPパケットが最初の分類器に移動し、外側のIPヘッダに基づいて行われた分類を有することができます。 IPインIPパケットとして分類されると、パケットは内部IPヘッダに分類を行うために、再び分級機により、外側のIPヘッダを取り除くためにカプセル開放装置に送信続きます。同じ分類器のハードウェアまたはソフトウェアをフィルタリング規則の同じセットとの両方の外側と内側のIPヘッダの分類に使用される場合、論理ループは、図8.A.に示すように、LFBトポロジに天然に存在しますしかし、分類は、異なるフィルタ（すなわち、外側のIPヘッダと内側IPヘッダの別のセットのためのフィルタの一組）は、2つのように、それらをモデル化することがより自然であるとハードウェアまたはソフトウェアの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（例えば、作成/インスタンス化、更新、または削除のデータパスに沿ってLFBsの変更を含む、データ経路を変更することを意味しますLFBs）とセットアップまたは下流LFBsの入力に上流LFBsの出力間の相互接続を削除します。
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上のデータパスは、ネットワーク要素の（NE）の顧客に特定のデータ・プレーン・サービス（例えば、Diffservの、VPN）を提供するようにCEによって設定されています。データパスを再構成する目的は、NEは、実行時に提供されるサービスをカスタマイズするためにCEを有効にすることです。 CEは、サービス要件が変更されたときに、このような新しい顧客を追加するとき、または既存の顧客がサービスを変更して、データパスを変更する必要があります。ただし、すべてのデータパスの変更はLFBトポロジグラフで変化をもたらすことに注意してください。グラフの変化は、LFBトポロジにデータパスをマッピングするために使用されるアプローチに依存しています。セクション3.4.1で説明したように、トポロジー的アプローチと符号化された状態のアプローチは、同じデータ・パスのための非常に異なる探しLFBトポロジーをもたらすことができます。一般に、純粋なトポロジーアプローチに基づいて、LFBトポロジーは、符号化された状態のアプローチに基づくものよりもより頻繁トポロジ再構成を経験する可能性があります。しかし、符号化された状態のアプローチに完全に基づいてもLFBトポロジは、いくつかLFBsをバイパスするか、新しいLFBsを挿入するために、例えば、時間にトポロジーを変更する必要があります。これら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トポロジを許可すると、すべてのFEには、この能力を持つことが必要であることを強制しないことを指摘したいと思います。 FEは、設定LFBトポロジをサポートしている場合であっても、FEは実際に構成することができるものに制限を課すことができます。ネットワークプロセッサ上で実行されているFE実装はより多くの柔軟性と構成可能性を提供することができるが、パフォーマンス最適化ハードウェア実装は、ゼロ又は非常に限られた構成可能性を有していてもよいです。これは、FEが実際に再設定を実装し、そうであれば、どのくらいか否かを決定するために、完全にFEの設計者に任されています。単純なランタイムスイッチ（すなわち、バイパス）特定LFBsを有効または無効にするために使用され、またはより柔軟なソフトウェアの再構成が使用されているかどうか、FEおよびFEモデルの範囲外の内部実装の詳細です。いずれの場合も、CE（複数可）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
作成することができる同じLFBクラスのインスタンスの最大数O
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)
* LFBsに順序付け制約（例えば、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は理解しているマッピングは、特定のLFBトポロジに高レベルのNEサービスではなく、他の方法で回避からです。 CEは、FEでの構成データに任意の高レベルのサービスポリシーを翻訳する究極の知性を持っていることが予想されていません。しかし、与えられたネットワークサービスドメイン内で、知性の一定量がCEに低に高レベルのサービスポリシーからの翻訳を可能にするために関与LFBsの一般的な理解を与えるために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トポロジのいくつかはすでに固定されており、原因のラインカードの物理的なレイアウトに静的なままになっています。例えば、入力ポートのすべてがので、すべてのパケットが、分類エンジンに入力ポートからの流れ分類チップにハードワイヤードされるかもしれません。一方、ネットワークプロセッサ上LFBsとその実行順序がプログラム可能です。しかし、特定の容量の制限と連携制約がこれらLFBs間に存在する可能性があります。容量制限の例としては、次のようになります。
o 8 meters
O 8メートル
o 16 queues in one FE
1 FEで16個のキューO
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.
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にこれらの機能と容量制限を報告したら、それはFEのための望ましい形態へのQoSポリシーを変換するためにCEまでになりました。図10および図11は、CEを設定するためにFEを要求することができる二つの異なるトポロジーを描写しながら、図9は、FEの能力を示しています。インター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.
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モデルの主な目標は、のFEの抽象的、一般的な、モジュラー、実装に依存しない表現を提供することです。これは、LFBクラスからインスタンス化されるLFBs、という概念を用いて促進されます。 LFBクラスと関連する定義は、XML文書のコレクションで提供されます。これらのXML文書のコレクションは、LFBのクラスライブラリと呼ばれ、各ドキュメントは、（略して、またはライブラリのドキュメント）LFBクラスライブラリのドキュメントと呼ばれています。ライブラリ文書のそれぞれは、ここで説明するスキーマに従わなければなりません。スキーマに準拠するため、ここでスキーマとルールは、XMLスキーマのXMLスキーマの定義におけるW3C [SCHEMA1]とXMLスキーマ・データ型[SCHEMA2]で定義されたものです。ライブラリ文書のルート要素は<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.
ライブラリの文書は「オーバーザワイヤ」のFEとCEの間で交換されることが期待されていません。しかし、このモデルはCEの（ソフトウェア）とのFE（主にソフトウェア部品）の設計・開発のための重要な参考となります。 CE-FE通信用のForCESプロトコル要素を指定する場合、それはまた、設計入力となります。
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 <ロード>、
o <frameDefs> for the frame declarations, o <dataTypeDefs> for defining common data types,
O <frameDefs>共通データ型を定義するためのフレーム宣言、O <dataTypeDefs>のために、
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.
各要素はオプションです。メタデータのみの定義を含むことが一つのライブラリの文書は、別のは、唯一の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」ディレクティブに似ています。インポートは、文書内のすべての上記の要素に先行しなければならない<負荷>要素を使用することによって表現されます。ユニークな参照のために、各LFBLibraryインスタンス文書はLFBLibrary要素の属性を「提供」に定義された固有のラベルを持っています。何これは実行すると、強制的に組み込み、ないXMLの包含であることに注意してください。 <ロード>要素で参照されるライブラリの意味内容ではなく、XMLコンテンツが含まれています。また、<ロード>要素の概念的な処理の観点から、ロードされたドキュメントの全セットは、処理のために単一の文書を形成すると考えられます。与えられた文書は、それがさえ、いくつかの異なるファイルから<ロード>要素に数回、によって参照されている場合でも、一度だけこのセットに含まれています。 LFBLibrary情報の処理は順序に依存されていないため、ロードされた要素を処理するためには、実装者に任されている限り、すべてのファイルからすべての情報が必要なときに参照するために利用可能であるかのように、総効果があるとして。このような力のコンピュータ処理モデルライブラリ文書はさまざまな実装のために有用であり得るが、ライブラリを定義するために必要とされない、またはプロトコル自体の実際の動作のためにことに留意されたいです。
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>
</記述>
<!-- Loading external libraries (optional) --> <load library="another_library"/> ...
<！ - ロード外部ライブラリ（オプション） - > <ロード・ライブラリ= "another_library" /> ...
<!-- FRAME TYPE DEFINITIONS (optional) --> <frameDefs> ... </frameDefs>
<！ - FRAMEタイプ定義（オプション） - > <frameDefs> ... </ frameDefs>
<!-- DATA TYPE DEFINITIONS (optional) --> <dataTypeDefs> ... </dataTypeDefs>
<！ - データ型定義（オプション） - > <dataTypeDefs> ... </ dataTypeDefs>
<!-- METADATA DEFINITIONS (optional) --> <metadataDefs> ... </metadataDefs>
<！ - メタデータ定義（オプション） - > <metadataDefs> ... </ metadataDefs>
<!-- - - LFB CLASS DEFINITIONS (optional) --> <LFBCLassDefs>
<！ - - - LFBのクラス定義（オプション） - > <LFBCLassDefs>
</LFBCLassDefs> </LFBLibrary>
</ 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を含むかもしれません。負荷素子は無制限回繰り返すことができます。以下は、<ロード>要素のための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"/>
<ロードライブラリ= "a_library" /> <ロードライブラリ= "another_library" 位置= "another_lib.xml" /> <ロードライブラリ= "yetanother_library" 位置= "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は、その入力ポート（S）で予想し、その出力ポート（単数または複数）で発光するフレームのタイプを定義する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>
<frameDefs> <frameDef> <名前>はIPv4 </名前> <概要> IPv4パケット</概要> <説明>このフレームタイプがIPv4パケットを指します。 </記述> </ frameDef> <frameDef> <名前>のIPv6 </名前> <概要> IPv6パケット</概要> <説明>このフレームタイプがIPv6パケットを指します。 </記述> </ 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>
<dataTypeDefs> <dataTypeDef> <名前> ieeemacaddr </名前> <概要> 48ビットIEEE MACアドレス</あらすじ> ...型定義... </ dataTypeDef> <dataTypeDef> <名前> ipv4addr </名前> <概要> IPv4アドレス</あらすじ> ...型定義... </ 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>と<原子>要素を定義することができます。
<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.
ForCESプロトコルは部品の値を取得および設定されることを考えると、ここで使用されるすべての原子データ型は、のForCESプロトコルに搬送することができなければなりません。さらに、のForCESプロトコルは、化合物のデータ・タイプを伝えるためのメカニズムが必要になります。しかしながら、そのような表現の詳細は、定義に力プロトコル[RFC5810]文書ではなく、モデルドキュメントのためのものです。それらが区切られていないように、文字列とoctetstringsは、その長さのプロトコルによって搬送されている必要があり、値自体は長さが含まれていない、これらの項目は可変長です。
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.
文字列に関しては、このモデルは、それらがどのように構成されるかの制限と定義の小さなセットを定義します。文字列とOctetStringに長さの制限は、LFBクラス定義で指定することができます。文字列とOctetStringにコンポーネントのコンポーネント・プロパティはまた、実際の長さと長さの制限を含みます。限界のこの重複はLFBクラス定義で指定された上限よりも小さい制限の実装を可能にすることです。すべての場合において、これらの長さをオクテットではなく文字で指定されています。プロトコルの動作の観点から、限り指定された長さは、FEのサポート能力の範囲内であるように、FEはCEによって提供されるとおりに文字列の内容を格納し、要求されたときにその内容を返します。いいえ正規化、変換、または等価のFEによって行われていません。文字列型の構成要素（または文字列[n]は）他のLFBs中の成分との相関のための識別子を保持するために使用され得ます。このような場合、オクテット一致の正確なオクテットが使用されます。全く等価性は、マッチングを行うにFEまたはCEによって使用されません。 ForCESプロトコル[RFC5810]はUTF-8文字列の内容の検証を実行するか、または必要としません。ただし、UTF-8文字列は、[UNICODE]に記載の潜在的なセキュリティ問題を回避するために最短の形で符号化されるべきです。そのような文字列を表示する任意のエンティティは、（例えば、正しいマルチバイト文字の場合、文字列は、マルチバイトシーケンスの途中で終了しないことを保証するために）それ自身の検証を実行することが期待されます。特定のLFBのクラス定義は、（例えば、DNS名を保持している部品が保持するのに制限されるだけで、そのような名前に有効なオクテット）特定の使用に適しなどの文字列の有効な内容を制限することができます。 FEは、範囲制限コンポーネントの範囲チェックが行われるのと同様に、セットが行われる時にそのような制限されたコンポーネントのSET要求の内容を検証すべきです。 ForCESプロトコルの動作は、そのプロトコルを使用して要求するための規範的な処理を定義します。
For the definition of the actual type in the <dataTypeDef> element, the following elements are available: <typeRef>, <atomic>, <array>, <struct>, and <union>.
<dataTypeDef>要素の実際のタイプの定義については、以下の要素を使用することができます。<typeRef>、<原子>、<配列>、<構造体>、および<組合>。
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クラスまたはインスタンス内の別のコンポーネントへの間接参照であることができるようにするために使用されます。エイリアスコンポーネントは、特別な行動を持っている一つの成分その構造、のように振る舞います。特別な挙動は構造体の他の部分に接続されていることを考慮すると、化合物の結果は、事前に定義された構築物として扱われます。
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>要素は、その名前によって既存のデータ型を参照します。参照されるデータ型は、同じライブラリ文書に含まれたり、ライブラリのドキュメントの1つのいずれかで定義されなければなりません。参照されるデータ・タイプがアトミックデータ型である場合には、新たに定義されたタイプは、アトミックとみなされます。参照されるデータ型が複合型である場合は、新しいタイプはまた、化合物になります。いくつかの使用例を次に示します。
<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>
<dataTypeDef> <名前>ショート</名前> <概要>エイリアスINT16する</シノプシス> <typeRef> INT16 </ typeRef> </ dataTypeDef> <dataTypeDef> <名前> ieeemacaddr </名前> <概要> 48ビットIEEE MACアドレス</シノプシス> <typeRef>バイト[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>
<dataTypeDef> <名前> DSCP </名前> <概要> Diffservのコードポイント</概要> <baseType> UCHAR <原子> </ baseType> <rangeRestriction> <allowedRange分= "0" 最大= "63" /> </ rangeRestriction> <specialValues> <specialValue値= "0"> <名前> DSCP-BE </名前> <概要>ベストエフォート</概要> </ specialValue> ... </ specialValues> </アトミック> < / 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.
<配列>要素には、化合物またはアトミックデータ型の配列として新しい複合データ型を作成するために使用することができます。文脈に応じて、本文書及びその他はセマンティックまたは構文含意せず、互換的にテーブルまたはアレイのようなアレイを指します。配列エントリのタイプ（<typeRef>要素を使用して）既存の型を参照するか、<原子>、<配列>、<構造体>のいずれかを使用して、<配列>要素内の名前のタイプを定義することによってのいずれかで指定することができます、または<組合>要素。
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.
配列<配列>要素の「タイプ」属性で指定された「固定サイズ」または「可変サイズ」であってもよいです。デフォルトでは、「可変サイズ」です。可変サイズの配列のために、オプションの「MAXLENGTH」属性は、最大許容長さを指定します。この属性は、セマンティックな制限はなく、実装の制限をエンコードするために使用する必要があります。後者（実装上の制約のために支持体）LFBクラスの機能コンポーネントによって処理されるべきであり、無制限のサイズであるとみなされているデータタイプ配列にMAXLENGTHとして含まれてはなりません。
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任意宣言キー（詳細については、のForCESプロトコル[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.
各キーはユニークキーは、1つ以上の指定されたキーフィールドを組み合わせることにより形成されるのForCESプロトコルで使用するための鍵ID [RFC5810]で宣言されています。ユニークな値を持つ原子型の配列は、それらの値によって参照することができる場合をサポートするために、キーフィールド識別子は、「*」（すなわち、配列エントリが鍵である）であってもよいです。配列の値型は、構造または配列の場合、キーは、値型の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>
<dataTypeDef> <名前>を再マップするためにコード空間を使用するDSCPマッピングテーブル</名前> <概要> 64のDSCP値のテーブル、。 </シノプシス> <配列タイプ= "固定サイズ" 長さ= "64"> <typeRef> DSCP </ typeRef> </アレイ> </ 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").
上記の例では、アレイの各エントリは、<構造体>二成分（「ルール」および「opコード」）のです。
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プレフィックス情報のテーブルを示します。これは、この表の任意のインスタンスでは、何の2つのエントリが同じIPアドレス、プレフィックス長、および情報源を持っていないことを意味します。
<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>
<dataTypeDef> <名前> ipPrefixInfo_table </名前> <概要>既知のプレフィクスに関する情報のテーブル</シノプシス> <配列型= "可変サイズ"> <構造体> <コンポーネントのComponentID = "1"> <名前>アドレス-prefix </名前> <概要>接頭辞が記載されている</シノプシス> <typeRef> ipv4Prefix </ typeRef> </コンポーネント> <コンポーネントのComponentID = "2"> <名前>ソース</名前> <概要>プロトコルまたはプロセスの情報を提供する</概要> <typeRef> uint16の</ typeRef> </部品> <コンポーネントCOMPONENTID = "3"> <名前> prefInfo </名前> <概要>私たちは</概要> <気になる情報typeRef>仮説-INFO型</ typeRef> </成分> </構造体> <コンテンツ鍵contentKeyID = "1"> <contentKeyField>アドレスprefix.ipv4addr </ contentKeyField> <contentKeyField>アドレスprefix.prefixlen </ contentKeyField > <contentKeyField>ソース</ contentKeyField> </コンテンツ鍵> </アレイ> </ 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.
keyField要素は、アドレス・プレフィックスのすべてのフィールドが使用されているので、簡単に、そしてソース・プレフィックスに対処されている可能性があることに注意してください。
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).
キー宣言を使用するためには、潜在的に、アレイ内の他の構成要素内にネストされたコンポーネントを参照しなければなりません。ネストされた配列がある場合は、1でもキーとして配列要素を使用する場合があります（ただし、細心の注意を一意性を保証するために必要とされるであろう）。
The key is the combination of the values of each field declared in a keyField element.
キーはkeyField要素で宣言された各フィールドの値の組み合わせです。
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.
したがって、keyField要素の値が「」で区切られたフィールド識別子の連結配列でなければなりません（ピリオド）文字。空白は許され、無視されます。
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.
keyField内の単一フィールド識別子のための有効な文字列は、現在のコンテキストに依存します。最初に、アレイキー宣言に、コンテキストは、アレイのタイプです。徐々に、コンテキストが現在のキーフィールド宣言で、これまでに処理されたフィールド識別子によって選択されているものは何でもタイプです。
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.
参照配列または構造要素において、存在しないkeyFieldsを構築することができます。 keyField参照は、オプションの構造コンポーネントを参照することはありません。配列要素を参照するために、注意が全体的な配列要素を作成または変更するときに必要な配列要素が存在することを保証するために注意しなければなりません。そうしないと、作成の試みにエラーを返すのFEになります。
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において、「構造体」と同様の機能を果たします。 <構造体>要素はオプションで導出表示、<derivedFrom>元素を含んでいてもよいです。構造定義は、1つ以上の<成分>要素の配列を含まなければなりません。
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>要素を使用して）既存のタイプを参照することによって定義することができ、又は局所的に定義された（名前）とすることができる<原子>、<配列>、<構造体>のいずれかによって作成されたタイプ、または<組合>要素。
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を提供します。 <コンポーネント>はコンポーネント名と概要を含まなければなりません。これは、コンポーネントのテキスト記述を与える<description>要素を含むかもしれません。定義は、定義されている構成要素がオプションであることを示し、<オプション>要素を含むことができます。定義は、上記のように、コンポーネントのデータ・タイプを定義するための要素を含まなければなりません。
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.
構造体のdataTypeDefため、構造の定義から継承されてもよく、そして、以前に定義された構造化タイプを増強します。これは、増強又は交換部品の定義の前に構造体宣言内のオプションderivedFrom属性を含めることによって示されています。 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.
COMPONENTID構造における異なるコンポーネントの属性（またはLFBには）別個でなければなりません。彼らは順番にする必要はありません、また彼らは、連続する必要があります。可読性の明瞭さ、および保守を容易にするためには、値の少なくとも連続的なセットを定義するのが一般的です。しかし、これは人間のしやすさではなく、モデルやプロトコル要件のためです。
The result of this construct is always a compound type, even when the <struct> contains only one field.
この構築物の結果は、<構造体>が唯一のフィールドが含まれている場合でも、常に複合型です。
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>
<dataTypeDef> <名前> ipv4prefix </名前> <概要>アドレスとプレフィックス長によって定義されたIPv4プレフィクス</シノプシス> <構造体> <コンポーネントのComponentID = "1"> <名前>アドレス</名前> <概要>アドレス部</シノプシス> <typeRef> ipv4addr </ typeRef> </コンポーネント> <コンポーネントのComponentID = "2"> <名前>のprefixlen </名前> <概要>プレフィックス長部</シノプシス> <原子> <baseType> UCHAR </ baseType> <rangeRestriction> <allowedRange分= "0" 最大= "32" /> </ rangeRestriction> </原子> </成分> </構造体> </ 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.
この構築物の結果は、労働組合が一つだけの要素が含まれている場合でも、常に複合型です。
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.
他のLFBsにLFB又は構造情報を参照し（成分）に成分を有することが必要な場合があります。これは、例えば、ARP LFBは情報を複製することなく、ローカル伝送LFBとIP-> MACアドレステーブルを共有できるようにすることができます。同様に、トラフィック測定LFBは、道路交通法施行のLFBと情報を共有する可能性があります。 <エイリアス>宣言は、このための構造を作成します。この構築物は、定義されたデータのいずれかの操作が実際にいくつかの他のLFBインスタンスの一部指定部分に存在することが定義されたデータの操作であることをCEとFEを伝えます。 <エイリアス>要素の内容は、名前付きの型でなければなりません。どんな成分（後述のように、エイリアス成分の特性によって決定される）別名参照を、そのコンポーネントは、エイリアスの宣言と同じタイプのものでなければなりません。 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.
<エイリアス>要素によって宣言された構成要素の目標は、コンポーネントの特性の情報によって決定されます。すべてのコンポーネントと同様に、プロパティは、エイリアスのサポート/読み込み/書き込み権限が含まれます。また、エイリアスのターゲットを定義するエイリアスのプロパティのいくつかのフィールド（コンポーネント）があります。これらのコンポーネントは、ターゲットの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の一方のみの成分（COMP1）、単に（任意の型の）第二成分を添加することによって行うことができるAからクラスA1を導出するための一つの方法が、単純なベースLFBクラスAを考えます。 AからクラスA2を導出する別の方法は、両方のクラスA1、A2はクラスAとの下位互換性があり、YはXの増加であるタイプYのいずれかで式Xの元成分（COMP1）を置換することによってすることができます
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.
オーグメンテーションのための構文は、拡張されているもの構造タイプを示す構造定義の<derivedFrom>要素を含むことです。コンポーネント名と増強内の新しいコンポーネントのコンポーネント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>要素はmetadatumを定義します。
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.
型定義の二つの形式が許可されています。最初の形式は同じライブラリドキュメントの<dataTypeDefs>要素または含まれるライブラリの文書の1つで定義された既存のアトミックデータ型を参照するために、<typeRef>要素を使用します。 <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の形式は、<原子>要素を使用して、明示的な型定義です。この要素は、<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>
<metadataDefs> <metadataDef> <名前> NEXTHOPID </名前> <概要> NH LFBにおけるネクストホップエントリを参照する</シノプシス> <metadataID> 17 </ metadataID> <typeRef> INT32 </ typeRef> </ metadataDef>分類の<metadataDef> <名前> CLASSID </名前> <概要>結果（0は一致しないことを意味）。 </シノプシス> <metadataID> 21 </ metadataID> <原子> <baseType> INT32 </ baseType> <specialValues> <specialValue値= "0"> <名前> NOMATCH </名前> <概要>分類をもたらしませんでした試合インチ</概要> </ specialValue> </ specialValues> </原子> </ 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 <名前>は、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 <inputPorts>は、入力ポートとその仕様を示します。
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 <イベント>この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 Considerations部に与えられるように、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>
<LFBClassDefs> <LFBClassDef LFBClassID = "12345"> <名前> ipv4lpm </名前> <概要> IPv4の最長プレフィックスマッチ検索LFB </概要> <バージョン> 1.0 </ version>の<derivedFrom>基底クラス</ derivedFrom>
<inputPorts> ... </inputPorts>
<inputPorts> ... </ inputPorts>
<outputPorts> ... </outputPorts>
<outputPorts> ... </ outputPorts>
<components> ... </components>
<コンポーネント> ... </部品>
<capabilities> ... </capabilities>
<機能> ... </機能>
<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最長前方一致検索操作を表します。次のようにモデル化された動作は次のとおりです。何とか-何とか-何とか。 </記述>
</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.
個々のコンポーネントおよび機能は、のForCESプロトコルで使用するためにcomponentIDsを持つことになります。これらは、構造体で使用されるcomponentIDsを平行し、同じように使用されています。コンポーネントと能力componentIDsは、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.
<名前>、<概要>ことに注意してください、そして、<バージョン>要素が必要とされます。他のすべての要素は、<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クラス定義内の異なるアイテムのCOMPONENTID属性が異なるものでなければなりません。彼らは順番にする必要はありません、また彼らは、連続する必要があります。可読性の明瞭さ、および保守を容易にするためには、値の少なくとも連続的なセットを定義するのが一般的です。しかし、これは人間のしやすさではなく、モデルやプロトコル要件のためです。
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クラスの一意の名前（<名前>）でなければなりません。呼ばLFBクラスが同じライブラリ文書に含まれたり、ライブラリのドキュメントの1つで定義しなければなりません。 <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.
オプションの<inputPorts>要素は、入力ポートを定義するために使用されます。 LFBクラスはゼロ、1、または複数の入力を有することができます。 LFBクラスはない入力ポートを有していない場合は、<inputPorts>要素を省略しなければなりません。 <inputPorts>要素は、1つ以上の<inputPort>要素、各ポートまたはポートグループのための1つを含むことができます。私たちは、ほとんどのLFBsが正確に1つの入力を持っていることを前提としています。同じ入力タイプを有する複数の入力は、1つの入力グループとしてモデル化されます。入力グループは、オプションの「グループ」属性によってのみ区別<inputPort>要素によって入力ポートと同じように定義されます。
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項での議論を参照のこと）は避けるべきです。一部の特殊LFBsはまったく入力を持ちません。例えば、パケット生成LFBは、入力を必要としません。
Single input ports and input port groups are both defined by the <inputPort> element; they are differentiated only by an optional "group" attribute.
単一の入力ポートと入力ポートグループは、両方の<inputPort>要素によって定義されます。それらは、オプションの「グループ」属性によって区別されています。
The <inputPort> element MUST contain the following elements:
<inputPort>要素は、以下の要素を含まなければなりません：
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 <名前>は、入力のシンボリック名を提供します。例：「で」。このシンボル名のみLFBクラスの範囲内で一意である必要があることに注意してください。
o <synopsis> contains a brief description of the input. Example: "Normal packet input".
O <あらすじ>は、入力の簡単な説明が含まれています。例：「ノーマルパケット入力」。
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 <期待>はすべて許可されたフレームフォーマットを示しています。例：{ "IPv4の" および "IPv6の"}。このリストは同じライブラリ文書の<frameDefs>要素または任意の含まれるライブラリの文書で指定された名前を参照する必要があることに注意してください。 <期待>要素も必要なメタデータのリストを提供することができます。例：{ "CLASSID"、 "VPNID"}。このリストは、同じライブラリの文書または任意の含まれるライブラリの文書に<metadataDefs>要素で定義されたメタデータの名前を参照する必要があります。各metadatumのためには、metadatumが必須かオプションかを指定する必要があります。各オプションmetadatumため、デフォルト値はmetadatumをパケットに提供されない場合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").
ポート、すなわち、インスタンス化が許可され、ポートグループとして振る舞うことができるかどうかに加えて、<inputPort>要素のオプションの「グループ」属性を指定することができます。これは、「真」の値で示されている（デフォルト値は「偽」です）。
An example <inputPorts> element, defining two input ports, the second one being an input port group is the following:
例<inputPorts>要素は、二つの入力ポートを規定する、入力ポート群である第2の一方は以下の通りです。
<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>
<inputPorts> <inputPort> <名前> </名前> <概要>における通常の入力</シノプシス> <期待> <frameExpected> <参考文献>のIPv4 </ REF> <参考文献> IPv6の</ ref>を</ frameExpected> < metadataExpected> <参考文献> CLASSID </ REF> <参考文献> vifid </ REF> <REF依存= "オプション" はdefaultValue = "0"> vrfid </ ref>を</ metadataExpected> </期待> </ inputPort> <inputPortグループ= "真"> ...別の入力ポート... </ 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".
各<inputPort>のために、フレームタイプの期待は、1つ以上の<参考文献>要素（上記の例を参照）を使用して<frameExpected>要素によって定義されます。複数のフレームタイプがリストされている場合は、フレームタイプ「これらのいずれかが」期待されていることを意味しています。他のフレームタイプのパケットは、LFBクラスのこの入力ポートと互換性がないと見なされます。 「IPv4の」との「IPv6」：上記の例では、期待されるフレームタイプとして2つのフレームを示しています。
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>要素で指定されています。その最も単純な形態では、この要素は、それぞれがmetadatumを参照すると、<参考文献>要素のリストを含むことができます。メタデータの複数のインスタンスが<参考文献>要素によって記載されている場合には、メタデータ「は、これらのすべては、」対応する<参考文献>の「依存性」属性で「オプション」としてマークされているメタデータを除いて（各パケットに受信しなければならないことを意味します素子）。 「オプション」に指定されてmetadatumの場合、デフォルト値は「はdefaultValue」属性を使用して提供されなければなりません。上記の例では、（「vrfid」）オプションである3つの必須（「CLASSID」および「vifid」）であるそのうちの2つが期待メタデータなどのメタデータ、および1つを示しています。
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:
スキーマは、メタデータの期待のより複雑な定義が可能になります。例えば、要素<一の>を使用して、メタデータのリストは、指定されたメタデータのうちの少なくとも一つは、任意のパケットと存在しなければならないことを表現するために指定することができます。例は次のとおりです。
<metadataExpected> <one-of> <ref>prefixmask</ref> <ref>prefixlen</ref> </one-of> </metadataExpected>
<metadataExpected> <一の> <参考文献> prefixmask </ REF> <参考文献>のprefixlen </ ref>を</ metadataExpected> </ワンの>
The above example specifies that either the "prefixmask" or the "prefixlen" metadata must be provided with any packet.
上記の例では、「prefixmask」または「prefixlenの」メタデータのいずれかが任意のパケットで提供されなければならないことを指定します。
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>
<metadataExpected> <参考文献> CLASSID </ REF> <参考文献> vifid </ REF> <REF依存= "オプション" はdefaultValue = "0"> vrfid </ REF> <一の> <参考文献> prefixmask </ REF> <参考文献>のprefixlen </ ref>を</ 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つを含まなければなりません。同じ出力タイプと複数の出力がある場合は、我々は、出力ポートグループとしてそれらをモデル化します。一部の特殊LFBsはすべて（例えば、スポイト）で何の出力を持っていません。
Single output ports and output port groups are both defined by the <outputPort> element; they are differentiated only by an optional "group" attribute.
両方の<出力ポート>要素によって定義される単一の出力ポートと出力ポートグループ。それらは、オプションの「グループ」属性によって区別されています。
The <outputPort> element MUST contain the following elements:
<出力ポート>要素は、以下の要素を含まなければなりません：
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 <名前>は、出力のシンボル名を提供します。例：「アウト」。シンボリック名のみLFBクラスの範囲内で一意である必要があることに注意してください。
o <synopsis> contains a brief description of the output port. Example: "Normal packet output".
O <あらすじ>は、出力ポートの簡単な説明が含まれています。例：「通常パケット出力」。
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 <製品>は許さフレームフォーマットを示しています。例：{ "IPv4の"、 "IPv6の"}。このリストは、同じライブラリの文書または任意の含まれるライブラリの文書に<frameDefs>要素で指定されたシンボルを参照する必要があることに注意してください。 <製品>要素はまた、放出された（生成された）メタデータのリストを含むことができます。例：{ "CLASSID"、 "色"}。このリストは、同じライブラリの文書または任意の含まれるライブラリの文書に<metadataDefs>要素で指定されたメタデータの名前を参照する必要があります。各生成metadatumため、metadatumが常に生成されるか、または特定の条件下でのみ発生しているか否かを指定しなければなりません。 LFBs間の互換性を評価する際に、この情報は重要です。
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").
ポート、すなわち、インスタンス化が許可され、ポートグループとして振る舞うことができるかどうかに加えて、<出力ポート>要素のオプションの「グループ」属性を指定することができます。これは、「真」の値で示されている（デフォルト値は「偽」です）。
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>
<outputPorts> <出力ポート> <名前>アウト</名前> <概要>通常出力</概要> <製品> <frameProduced> <ref>をIPv4の</ ref>を<ref>をipv4bis </ ref>を</ frameProduced> < metadataProduced> <ref>をnhid </ ref>を<ref>をnhtabid </ ref>を</ metadataProduced> </製品> </出力ポート> <出力ポートグループ= "真"> <名前> EXC </名前> <概要>例外出力ポートグループ</シノプシス> <製品> <frameProduced> <参考文献>のIPv4 </ REF> <参考文献> ipv4bis </ ref>を</ frameProduced> <metadataProduced> <REF可用性= "条件"> errorIDの</ REF> < / metadataProduced> </製品> </出力ポート> </ 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.
フレームとメタデータポートのタイプは、それぞれ<出力ポート>に<製品>要素内に定義されて生成します。 <製品>要素内に、ポートが生成するフレームタイプのリストは、<frameProduced>要素に記載されています。複数のフレームが表示されている場合には、これらのフレーム「の一つは、」生成されることを意味します。
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.
各パケットに生成されるメタデータのリストは、<製品>のオプション<metadataProduced>要素に記載されています。その最も単純な形態では、この要素は、各々がmetadatumタイプを参照し、<参考文献>要素のリストを含むことができます。そのようなリストの意味は、これらのメタデータ「の全てが」「条件付き」に設定し、オプションの「可用性」属性でリストされているものを除いて、各パケットに提供されることです。 <inputPort>の<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.
CEに見えなければならないLFBsの動作パラメータは、LFB成分としてモデルに概念化されています。これらは、例えば、旗、単一のパラメータの引数、複素数引数、およびテーブルを含んでいます。コンポーネントは、ここでCEに表示されている必要がありLFBsのもののみ動作パラメータを参照していることに注意してください。 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.
インターフェース・テーブル、プレフィックステーブル、分類テーブル、DSCPマッピングテーブル、MACアドレステーブル、等を含む様々な構成のルックアップテーブル、O
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:
ForCESモデルは、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から直接参照可能ではないし。これは、定義された特定の、そして一般的にアクセス可能なコンポーネントが報告FEにより、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ライト・コンポーネントのみ。これは、機能はCEの（例えば、セキュリティキー情報）に提供されていない読み取られる任意の構成可能なデータであってもよいです。
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クラスは、特定のコンポーネントのための唯一の可能なアクセスモードを定義しなければなりません。
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クラスの構成要素は、<成分>要素に記載されています。各コンポーネントは、<component>要素によって定義されます。 <成分>要素は必須であるいくつかは、以下の要素のいくつかまたはすべてを含みます。
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 <名前>発生し、コンポーネントの名前を定義しなければなりません。この名前は、LFBクラスのコンポーネントの中で一意でなければなりません。例：「バージョン」。
o <synopsis> is also mandatory, and provides a brief description of the purpose of the component.
O <概要>も必須であり、そして成分の目的の簡単な説明を提供します。
o <optional/> is an optional element, and if present indicates that this component is optional.
O <オプション/>オプションの要素であり、本このコンポーネントはオプションであることを示している場合。
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>要素で定義されている既存のデータ型の一意の名前を参照する必要があり、<typeRef>要素を使用して提供されます。データ・タイプがローカル（名前タイプ）が定義されている場合、次の要素のいずれかを使用することができます。<原子>、<配列>、<構造体>、または<組合>。その使用は、それらが<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 <description>要素も表示されることがあります。含まれている場合、それは定義されている特定の構成要素の意味または用法のより長い記述を提供します。
The <component> element also MUST have a componentID attribute, which is a numeric value used by the ForCES protocol.
<成分>要素ものForCESプロトコルによって使用される数値であるのComponentID属性を有していなければなりません。
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>要素は、次のいずれかの値をとることができるオプションの「アクセス」属性を含む：「読み取り専用」、「読み書き」、「書き込み専用」、「読み取りリセット」、および 『トリガーのみ』。デフォルトのアクセス・モードは、「読み書き」です。
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.
オプションのコンポーネントがサポートされているかどうか、および読み書きように定義されたコンポーネントを実際に書き込むことができるかどうかを、そのコンポーネントのプロパティ情報を読み取ることにより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>
<成分> <成分アクセス= "読み取り専用" のComponentID = "1"> <名前> FOO </名前> <概要>物事の数</概要> <typeRef> UINT32 </ typeRef> </コンポーネント> <成分アクセス= "読み書き" COMPONENTID = "2"> <名前>バー</名前> <概要>この他の事の数</概要> <原子> <baseType> UINT32 </ baseType> <rangeRestriction> <allowedRange分= "10" 最大= "2000" /> </ rangeRestriction> </原子> <はdefaultValue> 10 </はdefaultValue> </成分> </部品>
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ビットの符号なし整数です。第二の成分（「バー」）も整数であるが、付加的な範囲の制限を提供するために、<原子>要素を使用します。このコンポーネントは、それが両方の読み取りと書き込みができるように読み書きのアクセスモードがあります。 10のデフォルト値は、バーのために提供されます。バーのためのアクセスが書き込みを読んでいるが、いくつかの実装はより制限のアクセスを提供することがあり、これはコンポーネントのプロパティで報告されるだろう。
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.
すべてのコンポーネントは、特定の実装に常に存在する可能性があるではないことに注意してください。機能は頻繁にこの非存在を示すだろうが、CEはとにかく存在しないか、不許可のコンポーネントを参照するように試みることができます。 ForCESプロトコルメカニズムは、この場合の適切なエラーインジケータを含むべきです。
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つの力成分を含みます。 <機能>要素の形式は、ほぼ<成分>要素と同じです。それは2つの面で異なります。（それは常に読み取り専用であるため）には、アクセスモード属性を欠いて、（デフォルトの値は読み取り専用属性は適用されないので）それは、<はdefaultValue>要素を欠いています。
Some examples of capability components follow:
機能部品のいくつかの例を次に示します。
o The version of the LFB class with which this LFB instance complies
このLFBインスタンス準拠LFBクラスのバージョンO
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
運用上のコンポーネントOの追加範囲制限
The following example lists two capability attributes:
次の例は、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>
<機能> <機能COMPONENTID = "3"> <名前>バージョンこのインスタンスが準拠している</名前> <概要> LFBクラスバージョン。 </概要> <typeRef>バージョン</ typeRef> </機能> <機能COMPONENTID = "4"> <名前> limitBar </名前> <概要> "バー" 属性の最大値。 </概要> <typeRef> uint16の</ typeRef> </機能> </機能>
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.
<イベント>要素は、この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:
<イベント>要素は、単一のイベントを宣言それぞれが0以上の<イベント>要素を含んでいます。 <イベント>要素は、イベントのユニークな（LFBクラスあたり）IDを与えるのeventID属性を持っています。要素が含まれます：
o <eventTarget> element indicating which LFB field (component) is tested to generate the event.
イベントを生成するために試験されたLFBフィールド（成分）を示す0 <のEventTarget>要素。
o <condition> element indicating what condition on the field will generate the event from a list of defined conditions.
O <条件>定義された条件のリストからイベントを生成しますフィールド上のどのような条件を示す要素。
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.
<イベント>要素は、通常、<イベントbaseID =「番号」>であるbaseID属性値を有しています。 baseIDの値は、イベントを識別し、パスの開始のComponentIDあります。これは、LFBクラスの（機能を含む）任意のトップレベルのコンポーネントのCOMPONENTIDと同じであってはなりません。派生LFBsにおいて（すなわち、<derivedFrom>要素を持つもの）親LFBクラスは、イベント宣言を有し、baseIDが導出LFB <イベント>要素中に存在してはなりません。代わりに、親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>
<イベントbaseID = "7"> <イベントのeventID = "7"> <名前> Foochanged </名前> <概要>スカラーための例示的なイベント</シノプシス> <のEventTarget> <eventField> FOO </ eventField> </ EventTarget> <eventChanged /> <eventReports> <！ - 新しい状態を報告 - > <eventReport> <eventField> FOO </ eventField> </ eventReport> </ eventReports> </イベント>
<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>
<イベントのeventID = "8"> <名前> Goof1changed </名前> <概要>複雑な構造のための例のイベント</概要> <のEventTarget> <！ - ターゲットがあるgoo.f1 - > <eventField>グー< / eventField> <eventField> F1 </ eventField> </のEventTarget> <eventChanged /> <eventReports> <！ - goo.f1の新しい状態を報告 - > <eventReport> <eventField>グー</ eventField> <eventField > F1 </ eventField> </ eventReport> </ eventReports> </イベント>
<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>
<イベントのeventID = "9"> <名前> NewbarEntry </名前> <概要> </概要> <のEventTarget> <eventField>バー</ eventField> <eventSubscript> _barIndex _ </ eventSubscriptテーブルバーの上に作成された新しいエントリのイベント> </のEventTarget> <eventCreated /> <eventReports> <eventReport> <eventField>バー</ eventField> <eventSubscript> _barIndex _ </ eventSubscript> </ eventReport> <eventReport> <eventField> FOO </ eventField> </ eventReport> </ eventReports> </イベント>
<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>
<イベントのeventID = "10"> <名前> Gah11changed </名前> <概要>表GAH、エントリインデックス11のイベントが変更</シノプシス> <のEventTarget> <eventField> GAH </ eventField> <eventSubscript> 11 </ eventSubscript > </のEventTarget> <eventChanged /> <eventReports> <eventReport> <eventField> GAH </ eventField> <eventSubscript> 11 </ eventSubscript> </ eventReport> </ eventReports> </イベント>
<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>
<イベントのeventID = "11"> <名前> Gah10field1 </名前> <概要>表GAH、エントリインデックス10、カラムFIELD1のイベントが変更</シノプシス> <のEventTarget> <eventField> GAH </ eventField> <eventSubscript> 10 </ eventSubscript> <eventField> FIELD1 </ eventField> </のEventTarget> <eventChanged /> <eventReports> <eventReport> <eventField> GAH </ eventField> <eventSubscript> 10 </ eventSubscript> </ eventReport> </ eventReports> </イベント> </イベント>
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つ以上の<eventSubscript>要素が続いてもよいそれぞれが1つ以上の<eventField> Sを含有します。これら二つの要素の各々は、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、グー、バー、及び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は、複雑な構造のグーのメンバーがイベントをトリガするために監視することができる方法を示しています。
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は、第二は、<eventField>構造グーのメンバー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.
<eventField>アレイコンポーネントを識別した後、O <eventSubscript>要素は、次の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>の値は、名前ではなく、数値でなければなりません。同じ名前は、その後、以下に記載されるように<eventReport>要素内の<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>は、さらに、ターゲット要素へのパスを絞り込むことが続いてもよいです。 （注：これは<eventFieldが>さらにGoof1changedの複雑な構造の例の以前の例では、<eventField>を精緻化するために使用される場合と同じ精神である。）例えばイベントGah10field1は、テーブルGAHのカラムFIELD1がある方法を示し変化をモニターしました。
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定義の（セクション4.7.6.3を参照）<eventReport>要素に使用する変数名です。この名前は、正当<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>要素は、イベントの発生の通知とともに、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>要素のコレクションかのようなデータ構造で定義されていたことを運びます。構文は、<eventField>と<eventSubscript>要素を使用して、<のEventTarget>要素で使用され、したがって、同じ規則が適用さと全く同じです。各<eventReport>要素は、このようにLFBクラスのコンポーネントを識別しなければなりません。 <eventSubcript>整数を含むかもしれません。彼らは名前が含まれている場合は、イベント中に<のEventTarget>の<eventSubscript>要素から名前でなければなりません。レポートの選択は、特定の要素がイベントをトリガすることを識別する添字の値を使用します。これは、イベントを発生させる構成要素を参照するために、または並列テーブルの関連情報を参照するために使用することができます。
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:
図示の例では、イベントFoochangedの場合、レポートは、fooの値を伝送します。 NewbarEntryが配列LFBコンポーネントバーに作用する定義されたイベントの場合には、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.
テーブルバーに追加された新しいものをエントリ最初の<eventReport>詳細O。 _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.
第0 <eventReport>新しいエントリがバーに作成された時点での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>は、イベントを参照するパスで使用される追加の構成要素を提供します。それは<のEventTarget>に存在する場合のパスは、それぞれ<eventSubscript>要素の値は、続いて特定のイベントのためのIDが続くイベントのbaseIDを構成します。
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項で述べたように、イベント要素は、それらに関連した特性を有しています。これらの特性は、FEによって生成されたイベント通知のセットを低減することができるレベルの交差に関連するイベント、およびフィルタリング条件に対するサブスクリプションCEが全くイベントのイベント・レポートを生成するFEを望むか否かを示す情報、しきい値を含みます。適用することができるフィルタ条件の詳細は、そのセクションに記載されています。フィルタリング条件は、FEは、条件値の周りの振動に起因する可能性のあるイベントの洪水を抑制することができます。フィルタリングをサポートしたくないのFEの場合は、フィルタの特性は、いずれかになります読み取り専用またはサポートされていません。
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ものForCESプロトコル[RFC5810]の操作で定義されるようにSET-PROPを利用する（セクション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上のイベントの生成を有効にするには、イベントのイベントや登録プロパティを参照SET-PROPメッセージは、イベントのパスのいずれかの接頭辞を持つCEによってFEに発行されます。そのため、例えばテーブルバーの上に定義されたイベントのために、7.9のパスを持つSET-PROPは、テーブルのどのエントリにそのイベントのすべての出現にCEをサブスクライブします。これは、テーブル上の<eventCreated />と<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>の<description>要素は、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.
LFBsのコンポーネントは、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.
モデルは、プロパティ情報の構造体の定義を提供します。プロパティ情報の基本クラスがあります。配列、エイリアス、およびイベント・コンポーネントの場合、追加のフィールドを提供する属性情報のサブクラスがあります。この情報は、CEによってアクセス（及び適用可能な場合、更新）のForCESプロトコルを介しています。一部の属性情報が書き込み可能であるが、現在プロパティ要素の特性を確認するために設けられメカニズムはありません。書き込み可能性は唯一の値を変更しようとすることで確認することができます。
The basic property definition, along with the scalar dataTypeDef for accessibility, is below. Note that this access permission information is generally read-only.
基本的なプロパティ定義は、アクセシビリティのためのスカラー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.
FE実装はLFBクラスの定義よりも短くOctetStringにを制限することができるので、OctetStringに特性は、実際の長さと最大長さを指定します。
<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（通常）書き込み可能なフィールドを追加します。一つは、サブスクリプションフィールドです。 0は、通知が生成されないことを意味します。ゼロ以外の値は、（典型的には1が使用される）通知が生成されることを意味します。ヒステリシスフィールドは、条件値の周りの振動の通知の発生を抑制するために使用され、そして（セクション4.8.5.2）について説明します。閾値フィールドは<eventGreaterThan />と<eventLessThan />条件のために使用されます。それはに対してイベントターゲットを比較するための値を示しています。プロパティを使用すると、CEは、関心のレベルを設定することができます。イベントのしきい値を設定することをサポートしていないのFEは、このフィールドは読み取り専用になります。
<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.
現在、三つの異なるフィルタ条件変数が定義されています。これらは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に設定EVENTCOUNT性と500ミリ秒に設定eventInterval性のイベントです。このイベントの発生のバーストがFEによって検出されたとします。最初の発生は通知がCEに送信されることになります。 4つの以上の発生を迅速に検出された場合次に、（0.5秒未満）が、彼らは、通知にはなりません。 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は、ヒステリシスを変更できるようにすることができます。これは、数値フィールドのため、および<eventGreaterThan />と<eventLessThan />に<eventChanged />に適用されます。の内容
<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.
値がXに達するまで最後の通知が値Xのためであった場合、O <eventChanged />条件については、その後<変更/>通知が発生してはいけません+/- 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：キー名= "LFBClassDef"> <XSD：セレクタのXPath = "LFB：LFBClassDefs / LFB：LFBClassDef" /> <XSD：フィールドのXPath = "LFB：名" /> </ XSD：キー> </ XSD：要素> <XSD：complexTypeの名前= "LOADTYPE"> <XSD：属性名= "ライブラリ" タイプ= "のxsd：名前" 使用= "必要" /> <XSD：属性名= "場所" タイプ= "のxsd：anyURIタイプオプション "=使う" "/> </のxsd：complexTypeの> <XSD：complexTypeの名=" frameDefsType "> <XSD：配列> <XSD：要素名=" frameDef」のmaxOccurs = "無制限"> <のxsd：complexTypeの> < XSD：配列> <XSD：要素名= "名前" タイプ= "のxsd：NMTOKEN" /> <XSD：要素REF = "概要" /> <XSD：要素REF = "説明" のminOccurs = "0" /> < / XSD：配列> </のxsd：complexTypeの> </ XSD：要素> </ XSD：配列> </のxsd：complexTypeの> <XSD：complexTypeの名= "dataTypeDefsType"> <XSD：配列> <XSD：要素名= "dataTypeDef" のmaxOccurs = "無制限"> <のxsd：complexTypeの> <XSD：配列> <XSD：要素名= "名前" タイプ= "のxsd：NMTOKEN" /> <XSD：要素REF = "概要" /> <XSD ：要素REF = "説明" のminOccurs = "0" /> <XSD：グループREF = "typeDeclarationGroup" /> </ XSD：配列> </ XSD ：のcomplexType> </ XSD：要素> </ XSD：配列> </のxsd：complexTypeの> < - 定義済みの（ビルトイン）アトミックデータ型である：！チャー、UCHAR、INT16、uint16の、INT32、UINT32、int64モード、uint64型、文字列[N]、文字列、バイト[N]、ブール、[N]をOCTETSTRING、のfloat32、float64型 - > <XSD：グループ名= "typeDeclarationGroup"> <のxsd：選択>ます。<xsd：要素名=」 typeRef」TYPE = "typeRefNMTOKEN" /> <XSD：要素名= "アトミック" タイプ= "atomicType" /> <XSD：要素名= "アレイ" タイプ= "のarrayType" /> <XSD：要素名= "構造体"タイプ= "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：要素名= "ユニオン" タイプ= "structType" /> <XSD：要素名= "エイリアス" タイプ= "typeRefNMTOKEN" /> </のxsd：選択> </のxsd：グループ> <XSD：単純型名= "typeRefNMTOKEN"> <XSD：制限ベース= "XSD：トークン"> <XSD：パターン値= "\ C +" /> <XSD：パターン値= "文字列\ [\ D + \]" /> <XSD：パターン値= "バイト\ [\ D + \]" /> <XSD：パターン値= "OctetStringには\ [\ D + \]" /> </ XSD：制限> </のxsd：simpleTypeの> <のxsd：complexTypeの名前= "atomicType" > <XSD：配列> <XSD：要素名= "baseType" タイプ= "typeRefNMTOKEN" /> <XSD：要素名= "rangeRestriction" タイプ= "rangeRestrictionType" のminOccurs = "0" /> <XSD：要素名=」 specialValues」TYPE = "specialValuesType" のminOccurs = "0" /> </ XSD：配列> </のxsd：complexTypeの> <XSD：complexTypeの名= "rangeRestrictionType"> <XSD：配列> <XSD：要素名= "allowedRange" maxOccurs = "無制限"> <のxsd：complexTypeの> <XSD：属性名= "分" タイプ= "のxsd：整数"：属性名= "最大" タイプ= "のxsd：整数" 使用は= /> <XSD "必要"使用= "必要" /> </のxsd：complexTypeの> </ XSD：要素> </ XSD：配列> </のxsd：complexTypeの> <X SD：complexTypeの名前= "specialValuesType"> <のxsd：sequence>を<のxsd：要素名= "specialValue" のmaxOccurs = "無制限"> <のxsd：complexTypeの> <のxsd：sequence>を<のxsd：要素名= "名前" タイプ= "XSD：NMTOKEN" /> <XSD：要素REF = "あらすじ" /> </のxsd：sequence>を<XSD：属性名= "値" タイプ= "のxsd：トークン" /> </のxsd：complexTypeの> </ xsd：element>の</のxsd：sequence>を</のxsd：complexTypeの> <XSD：complexTypeの名= "のarrayType"> <のxsd：シーケンス>
<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：グループREF = "typeDeclarationGroup" /> <XSD：要素名= "コンテンツ鍵" のminOccurs = "0" のmaxOccurs = "無制限"> <のxsd：complexTypeの> <XSD：配列> <XSD：要素名= "contentKeyField" maxOccurs = "無制限" タイプ= "のxsd：文字列" /> </のxsd：sequence>を<XSD：属性名= "contentKeyID" 使用= "必須" タイプ= "のxsd：整数" /> </のxsd：complexTypeの> < ！ - ユニークなIDを持つようにキーを宣言 - > <XSD：キー名= "contentKeyID"> <のxsd：セレクタのxpath = "LFB：コンテンツ鍵" /> <XSD：フィールドのxpath = "contentKeyID @" /> </ XSD ：キー> </ XSD：要素> </ XSD：配列> <XSD：属性名= "タイプ" 使用= "任意" デフォルト= "可変サイズ"> <のxsd：simpleTypeの> <XSD：制限ベース= "XSD ：文字列 "> <XSD：列挙値=" 固定サイズ "/> <XSD：列挙値=" 可変サイズ "/> </ XSD：制限> </のxsd：simpleTypeの> </ XSD：属性> <XSD ：属性名= "長さ" タイプ= "XSD：整数" 使用= "オプション" /> <XSD：属性名= "maxLengthの" タイプ= "XSD：整数" 使用= "オプション" /> </のxsd：complexTypeの> <XSD：complexTypeの名前= "structType"> <のxsd：sequence>を<XSD：要素名= "derivedFrom" トンYPE = "typeRefNMTOKEN" のminOccurs = "0" /> <XSD：要素名= "コンポーネント" のmaxOccurs = "無制限"> <のxsd：complexTypeの> <XSD：配列> <XSD：要素名= "名前" タイプ= "XSD ：NMTOKEN "/> <XSD：要素REF =" 概要 "/> <XSD：要素REF =" 説明」のminOccurs = "0" /> <XSD：要素名= "任意" のminOccurs = "0" /> <XSD ：グループREF = "typeDeclarationGroup" /> </のxsd：sequence>を<XSD：属性名= "COMPONENTID" 使用= "必要" タイプ= "のxsd：unsignedInt型" /> </のxsd：！complexTypeの> < - キーを宣言構造体のユニークなcomponentIDsを作ります
--> <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：キー名= "structComponentID"> <XSD：セレクタのXPath = "LFB：成分" /> <XSD：フィールドのXPath = "@ COMPONENTID" /> </ XSD：キー> </ XSD：要素> </ XSD：配列> </のxsd：complexTypeの> <のxsd：complexTypeの名前= "metadataDefsType"> <XSD：配列> <XSD：要素名= "metadataDef" のmaxOccurs = "無制限"> <のxsd：complexTypeの> <XSD。配列> <XSD：要素名= "名前" タイプ= "のxsd：NMTOKEN" /> <XSD：要素REF = "概要" /> <XSD：要素名= "metadataID" タイプ= "XSD：整数" /> < XSD：要素refは= "説明" のminOccurs = "0" /> <XSD：選択>ます。<xsd：要素名= "typeRef" タイプ= "typeRefNMTOKEN" /> <XSD：要素名= "アトミック" タイプ= "atomicType" /> </のxsd：選択> </のxsd：sequence>を</のxsd：complexTypeの> </のxsd：element>の</のxsd：sequence>を</のxsd：complexTypeの> <XSD：complexTypeの名= "LFBClassDefsType"> <XSD ：配列> <XSD：要素名= "LFBClassDef" のmaxOccurs = "無制限"> <のxsd：complexTypeの> <XSD：配列> <XSD：要素名= "名前" タイプ= "のxsd：NMTOKEN" /> <XSD：要素REF = "あらすじ" /> <XSD：要素名= "バージョン" タイプ= "versionType" /> <XSD：要素名= "derivedF ROM "タイプ= "のxsd：NMTOKEN" のminOccurs = "0"/> <XSD：要素名= "inputPorts" タイプ= "inputPortsType" のminOccurs = "0"/> <XSD：要素名= "outputPorts" タイプ=" outputPortsType "のminOccurs =" 0 "/> <XSD：要素名=" コンポーネント」タイプ= "LFBComponentsType" のminOccurs = "0" /> <XSD：要素名= "機能" タイプ= "LFBCapabilitiesType" のminOccurs = "0" /> <XSD：要素名= "イベント" タイプ= "eventsType" のminOccurs = "0" /> <XSD：要素REF = "説明" のminOccurs = "0" /> </ XSD：配列>
<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：属性名= "LFBClassID" 使用=タイプ= "のxsd：unsignedInt型" "必要" /> </のxsd：complexTypeの> <！ - クラス内で一意の属性名を確保するためにキー制約を： - > <XSD：キー名= "コンポーネント"> <XSD：セレクタのXPath = "LFB：コンポーネント/ LFB：成分" /> <XSD：フィールドのXPath = "LFB：名" /> </ XSD：キー> <XSD：キー名=」能力 "> <のxsd：セレクタのxpath =" LFB：機能/ LFB：機能 "/> <XSD：フィールドのxpath =" LFB：名 "/> </のxsd：キー>ます。<xsd：キー名=" componentIDs "> < XSD：セレクタのXPath = "LFB：コンポーネント/ LFB：成分" /> <XSD：フィールドのXPath = "@ COMPONENTID" /> </ XSD：キー> <XSD：キー名= "capabilityIDs"> <XSD：セレクタのXPath = "LFB：機能/ LFB：機能" /> <XSD：フィールドのxpath = "@のCOMPONENTID" /> </のxsd：キー> </のxsd：element>の</のxsd：sequence>を</のxsd：complexTypeの> <のxsd：単純名= "versionType"> <XSD：制限基地= "のxsd：NMTOKEN"> <XSD：パターン値= "[1-9] [0-9] * \（[1-9] [0-9]。 * | 0） "/> </のxsd：制限> </のxsd：simpleTypeの> <のxsd：complexTypeの名前=" inputPortsType "> <のxsd：sequence>を<のxsd：要素名=" inputPort」タイプ= "inputPortType" maxOccur S = "無限" /> </ XSD：配列> </のxsd：complexTypeの> <XSD：complexTypeの名= "inputPortType"> <XSD：配列> <XSD：要素名= "名前" タイプ= "のxsd：NMTOKEN" /> <XSD：要素REF = "概要" /> <XSD：要素名= "期待" タイプ= "portExpectationType" /> <XSD：要素REF = "説明" のminOccurs = "0" /> </ XSD：配列> <XSD：属性名= "グループ" タイプ= "のxsd：boolean型" 使用= "オプションの" デフォルト= "0" /> </のxsd：complexTypeの> <XSD：complexTypeの名= "portExpectationType"> <のxsd：シーケンス>
<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：要素名= "参照" タイプ= "metadataInputRefType" /> <XSD：要素名= "1-の" タイプ= "metadataInputChoiceType" /> </のxsd：選択> </のxsd：complexTypeの> </のxsd：要素> </のxsd：sequence>を</のxsd：complexTypeの> <XSD：complexTypeの名= "metadataInputChoiceType"> <のxsd：選択肢のminOccurs = "2" のmaxOccurs = "無制限"> < - refはの名前を参照する必要があります！定義されたメタデータ - > <XSD：要素名= "REF" タイプ= "のxsd：NMTOKEN" /> <XSD：要素名= "一の" タイプ= "metadataInputChoiceType" /> <XSD：要素名= "metadataSet "タイプ=" metadataInputSetType "/> </のxsd：選択> </のxsd：complexTypeの> <XSD：complexTypeの名=" metadataInputSetType "> <のxsd：選択肢のminOccurs =" 2" のmaxOccurs = "無制限"> < - REF！定義されたメタデータの名前を参照しなければならない - > <XSD：要素名= "REF" タイプ= "metadataInputRefType" /> <XSD：要素名= "一の" タイプ= "metadataInputChoiceType" /> </ XSD：選択肢> </のxsd：complexTypeの> <のxsd：complexTypeの名前= "metadataInputRefType"> <のxsd：simpleContentを> <XSD：増設ベース= "のxsd：NMTOKEN"> <XSD：属性名= "依存" の使用は= "オプション" デ単純> <XSD：制限基地= => <XSD "必要" 障害 "のxsd：string" は> <XSD：列挙値= "必須" /> <XSD：列挙値= "オプション" /> </ XSD：制限> </の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：属性> <XSD：属性名= "はdefaultValue" タイプ= "のxsd：トークン" 使用= "オプション" /> </ XSD：拡張> </のxsd：simpleContentを> </のxsd：complexTypeの> <のxsd： complexTypeの名= "outputPortsType"> <のxsd：sequence>を<のxsd：要素名= "出力ポート" タイプ= "outputPortType" のmaxOccurs = "無制限" /> </のxsd：sequence>を</のxsd：complexTypeの> <XSD：complexTypeの名前= "outputPortType"> <XSD：配列> <XSD：要素名= "名前" タイプ= "のxsd：NMTOKEN" /> <XSD：要素REF = "概要" /> <XSD：要素名= "製品" タイプ= "portProductType" /> <のxsd：要素REF = "説明" のminOccurs = "0" /> </のxsd：sequence>を<のxsd：属性名= "グループ" タイプ= "のxsd：boolean型" 使用= "オプションの" デフォルト= "0" /> </のxsd：complexTypeの> <XSD：complexTypeの名= "portProductType"> <のxsd：sequence>を<XSD：要素名= "frameProduced"> <のxsd：complexTypeの> <のxsd：sequence>を<！ - REFは、定義されたフレームタイプの名前を参照しなければならない - > <XSD：要素名= "REF" タイプ= "のxsd：NMTOKEN" のmaxOccurs = "無制限" /> </ XSD：配列> </のxsd：complexTypeの> < /のxsd：element>の<のxsd：要素名= "metadataProduced" のminOccurs =」 0 "> <のxsd：complexTypeの> <のxsd：選択肢のmaxOccurs =" 無制限 "> <！ - refは定義されたメタデータの名前を参照する必要があります - > <XSD：要素名=" 参照」タイプ= "metadataOutputRefType" / > <XSD：要素名= "1-の" タイプ= "metadataOutputChoiceType" /> </のxsd：選択> </のxsd：complexTypeの> </のxsd：element>の</のxsd：sequence>を</のxsd：complexTypeの> < xsd：complexTypeの名前= "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：選択肢のminOccurs = "2" のmaxOccurs = "無制限"> < - refは定義されたメタデータの名前を参照する必要があります - > <！のxsd：要素名= "参照" タイプ= "のxsd：NMTOKEN" />ます。<xsd：要素名= "1-の" タイプ= "metadataOutputChoiceType" /> <XSD：要素名= "metadataSet" タイプ= "metadataOutputSetType" /> </のxsd：選択> </のxsd：complexTypeの> <のxsd：complexTypeの名前= "metadataOutputSetType"> <XSD：！「=要素名= "参照" タイプ：選択のminOccurs = "2" のmaxOccurs = "無制限"> < - > <XSD - refは定義されたメタデータの名前を参照する必要がありますmetadataOutputRefType： "：選択> </のxsd：complexTypeの> <のxsd：complexTypeの名前= /> </ XSD "metadataOutputRefType"> <のxsd：simpleContentを> < "/> <XSD要素名="「タイプ=" metadataOutputChoiceTypeワンのXSD：増設ベース= "のxsd：NMTOKEN"> <XSD：属性名= "可用性" 使用= "オプションの" デフォルト= "無条件"> <のxsd：simpleTypeの> <XSD：制限ベース= "のxsd：文字列"> <XSD ：列挙値= "無条件" /> <XSD：列挙値= "条件" /> </ XSD：制限> </のxsd：simpleTypeの> </ XSD：属性> </ XSD：拡張> </ XSD：SIMPL e-コンテンツ> </のxsd：complexTypeの> <XSD：complexTypeの名= "LFBComponentsType"> <XSD：配列> <XSD：要素名= "コンポーネント" のmaxOccurs = "無制限"> <のxsd：complexTypeの> <XSD：配列> <XSD ：要素名= "名前" タイプ= "のxsd：NMTOKEN" /> <XSD：要素REF = "概要" /> <XSD：要素REF = "説明" のminOccurs = "0" /> <XSD：要素名=」オプション」のminOccurs = "0" /> <XSD：グループREF = "typeDeclarationGroup" /> <XSD：要素名= "はdefaultValue" タイプ= "XSD：トークン" のminOccurs = "0" /> </ XSD：配列> < XSD：属性名= "アクセス" 使用= "オプションの" デフォルト= "読み書き"> <のxsd：simpleTypeの> <XSD：リストitemTypeに= "accessModeType" /> </のxsd：simpleTypeの> </のxsd：属性>
<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：属性名= "COMPONENTID" 使用= "必須" タイプ= "のxsd：unsignedInt型" /> </のxsd：complexTypeの> </のxsd：element>の</のxsd：sequence>を</のxsd：complexTypeの> <のxsd：単純名= "accessModeType"> <XSD：制限基地= "のxsd：NMTOKEN"> <XSD：列挙値= "読み取り専用" /> <XSD：列挙値= "読み書き" /> <XSD：列挙値= "書き込み専用" /> <XSD：列挙値= "読み取りリセット" /> <XSD：列挙値= "トリガーのみ" /> </ XSD：制限> </のxsd：simpleTypeの> <のxsd：complexTypeの名前= "LFBCapabilitiesType"> <のxsd：sequence>を<のxsd：要素名= "機能" のmaxOccurs = "無制限"> <のxsd：complexTypeの> <のxsd：sequence>を<XSD：要素名= "名前" タイプ= "のxsd： NMTOKEN "/> <XSD：要素REF =" 概要 "/> <XSD：要素REF =" 説明」のminOccurs = "0" /> <XSD：要素名= "任意" のminOccurs = "0" /> <XSD。グループREF = "typeDeclarationGroup" /> </ XSD：配列> <XSD：属性名= "COMPONENTID" 使用は= "必要" タイプ= "XSD：整数" /> </のxsd：complexTypeの> </ XSD：要素> < / XSD：シーケンス> </のxsd：complexTypeの> <のxsd：complexTypeの名前= "eventsType"> <XSD：SE quence> <のxsd：要素名= "イベント" のmaxOccurs = "無制限"> <のxsd：complexTypeの> <のxsd：sequence>を<のxsd：要素名= "名前" タイプ= "のxsd：NMTOKEN" /> <XSD：要素の参照= "概要" /> <XSD：要素名= "のEventTarget" タイプ= "eventPathType" /> <XSD：要素REF = "eventCondition" /> <XSD：要素名= "eventReports" タイプ= "eventReportsType" のminOccurs =」 0 "/> <XSD：要素refは=" 説明」のminOccurs = "0" /> </ XSD：配列> <XSD：属性名= "のeventID" 使用= "必要" タイプ= "XSD：整数" /> < / 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>
</ XSD：要素> </のxsd：sequence>を<のxsd：属性名= "baseID" タイプ= "のxsd：整数" 使用= "オプション" /> </のxsd：complexTypeの> <！ - 置換グループのためにイベント条件 - > <XSD：要素名= "eventCondition" 抽象= "真" /> <XSD：要素名= "eventCreated" のsubstitutionGroup = "eventCondition" /> <XSD：要素名= "eventDeleted" のsubstitutionGroup = "eventCondition "/> <XSD：要素名=" eventChanged」のsubstitutionGroup = "eventCondition" /> <XSD：要素名= "eventGreaterThan" のsubstitutionGroup = "eventCondition" /> <XSD：要素名= "eventLessThan" のsubstitutionGroup = "eventCondition" / > <XSD：complexTypeの名前= "eventPathType"> <のxsd：sequence>を<XSD：要素refは= "eventPathPart" のmaxOccurs = "無制限" /> </のxsd：sequence>を</のxsd：！complexTypeの> < - 置換イベントパス部品のためのグループ - > <XSD：要素名= "eventPathPart" タイプ= "のxsd：文字列" 抽象= "真" /> <XSD：要素名= "eventField" タイプ= "のxsd：文字列" のsubstitutionGroup = "eventPathPart" /> <XSD：要素名= "eventSubscript" タイプ= "のxsd：string" はsubstitut ionGroup = "eventPathPart" /> <XSD：complexTypeの名= "eventReportsType"> <のxsd：sequence>を<XSD：要素名= "eventReport" タイプ= "eventPathType" のmaxOccurs = "無制限" /> </のxsd：sequence>を< / XSD：のcomplexType> <XSD：単純型名= "booleanType"> <XSD：制限基地= "XSD：文字列"> <XSD：列挙値= "0" /> <XSD：列挙値= "1" /> < / XSD：制限> </のxsd：simpleTypeの> </ XSD：スキーマ>
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.
要素を転送する力はのForCES制御素子に代わってトラフィックを処理します。基準は、この制御のためのプロトコルとメカニズムを説明しますが、異なる実装と異なるインスタンスは異なる能力を持つことになります。 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、クラスを持っています。 1、インスタンス：1 AこのクラスのLFBClassIDこのクラスの1つだけのインスタンスがこれまでFE中に存在する、プロトコル内のそのインスタンスのインスタンスIDは、クラスの構成要素を参照することにより、このように1です。 CEは、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つだけになります。そのクラスの詳細は、のForCESプロトコル[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> UINT32 </ typeRef> </コンポーネント> <コンポーネントのComponentID = "3"> <名前> LFBVersion </名前> <概要>本FEで使用LFBクラスのバージョン。 </シノプシス> <typeRef>列</ typeRef> </コンポーネント> <コンポーネントのComponentID = "4"> <名前> LFBOccurrenceLimit </名前> <概要>このクラスのLFBsのインスタンスの上限</概要> <オプション/> <typeRef> UINT32 </ typeRef> </部品> <！ - 各ポートグループのために、多くのポートが存在できるか - > <コンポーネントCOMPONENTID = "5"> <名前> PortGroupLimits </名前> <概要>ポートグループの制限の表</概要> <オプション/> <配列型= "可変サイズ"> <typeRef> PortGroupLimitType </ typeRef> </配列> </部品> <！ - という名前LFBクラスのために、 LFBクラスは、それが続くことができる - > <コンポーネントのComponentID = "6"> <名前> CanOccurAfters </名前> <概要>このLFBクラスが</概要> <オプション/> <配列型に従うことができるLFBクラスの一覧= "可変サイズ"> <typeRef> LFBAdjacencyLimitType </ typeRef> </配列> </部品> <！ - という名前LFBクラス、それに従うことができるLFBクラスの - > <コンポーネントCOMPONENTID = "7"> <名前> CanOccurBefores </名前> <概要>このLFBクラスに従うことができLFBクラスの一覧</概要> <OPTI onal /> <配列型= "可変サイズ">
<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>
この隣人に接続</コンポーネント> <コンポーネントのComponentID = "2"> <名前> InterfaceToNeighbor </名前> <概要> FEのインターフェイス</シノプシス> <オプション/> <typeRef>列</ typeRef> </成分> <成分COMPONENTID =「3」> <名前> NeighborInterface </名前> <概要>このFEが隣接している隣接するインターフェイスの名前。これは、2つのFEは、複数のインターフェイス上で隣接している場合に必要とされます。 LFBクラスインスタンスの</概要> <オプション/> <typeRef>列</ typeRef> </成分> </構造体> </ dataTypeDef> <dataTypeDef> <名前> LFBSelectorType </名前> <概要>固有の識別</シノプシス> <構造体> <コンポーネントのComponentID = "1"> <名前> LFBClassID </名前> <概要> LFBクラス識別子</シノプシス> <typeRef> UINT32 </ typeRef> </コンポーネント> <コンポーネントのComponentID =」 2" > <名前> LFBInstanceID </名前> <概要> LFBインスタンスID </シノプシス> <typeRef> UINT32 </ typeRef> </成分> </構造体> </ dataTypeDef> <dataTypeDef> <名前> LFBLinkType </名前> <概要>トポロジー二LFBインスタンスとの間のリンク</シノプシス> <構造体> <コンポーネントのComponentID = "1"> <名前> FromLFBID </名前>
<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>
<概要> LFB SRC </シノプシス> <typeRef> LFBSelectorType </ typeRef> </コンポーネント> <コンポーネントのComponentID = "2"> <名前> FromPortGroup </名前> <概要> SRCポートグループ</シノプシス> <typeRef>文字列</ typeRef> </コンポーネント> <コンポーネントのComponentID = "3"> <名前> FromPortIndex </名前> <概要> SRCポートインデックス</シノプシス> <typeRef> UINT32 </ typeRef> </コンポーネント> <コンポーネントのComponentID = "4"> <名前> ToLFBID </名前> <概要> DST LFBID </シノプシス> <typeRef> LFBSelectorType </ typeRef> </コンポーネント> <コンポーネントのComponentID = "5"> <名前> ToPortGroup </名前> <概要> DSTポートグループ</シノプシス> <typeRef>列</ typeRef> </コンポーネント> <コンポーネントのComponentID = "6"> <名前> ToPortIndex </名前> <概要> DSTポートインデックス</シノプシス> <typeRef > UINT32 </ typeRef> </成分> </構造体> </ dataTypeDef> </ dataTypeDefs> <LFBClassDefs> <LFBClassDef LFBClassID = "1"> <名前> FEObject </名前> <概要>コアLFB：FEオブジェクト< /シノプシス>の<version> 1.0 </バージョン> <成分> <成分アクセス= "読み書き" COMPONENTID = "1"> <名前> LFBTopology </名前> <概要>の表既知のトポロジ</シノプシス> <配列型= "可変サイズ"> <typeRef> LFBLinkType </ typeRef> </アレイ> </コンポーネント> <成分アクセス= "読み書き" COMPONENTID = "2"> <名前> LFBSelectors </名前> <概要>公知の活性LFBクラスおよびインスタンス</シノプシス> <配列型= "可変サイズ"> <typeRef> LFBSelectorType </ typeRef> </アレイ> </コンポーネント> <成分アクセスのテーブル= "読み書き" COMPONENTID = "3"> <名前> FEName </名前> <概要>このFE </シノプシス> <typeRef>文字列の名前[40] </ typeRef> </コンポーネント> <成分アクセス=」読み書き」COMPONENTID = "4"> <名前> FEID </名前> <概要>このFE </シノプシスのID> <typeRef> UINT32 </ typeRef> </コンポーネント> <成分アクセス= "読み取り専用" COMPONENTID = "5"> <名前> FEVendor </名前> <概要>このFE </シノプシス> <typeRef>ストリングのベンダー[40] </ typeRef> </コンポーネント> <成分アクセス= "読み取り専用" のComponentID = "6"> <名前> FEModel </名前> <概要>このFE </シノプシス> <typeRef>列のモデル[40] </ typeRef> </コンポーネント> <成分アクセス= "読み取り専用" のComponentID = "7"> <名前> FEState </名前> <Sのynopsis>このFEの状態</シノプシス> <typeRef> FEStateValues </ typeRef> </コンポーネント> <成分アクセス= "読み書き" COMPONENTID = "8"> <名前> FENeighbors </名前> <概要>表既知のネイバー</シノプシス> <オプション/> <配列型= "可変サイズ"> <typeRef> FEConfiguredNeighborType </ typeRef> </アレイ> </成分> </部品> <機能> <能力COMPONENTID = "30" > <名前> ModifiableLFBTopology変更可能LFBがサポートされているかどうか</名前> <概要> </概要> <オプション/> <typeRef>ブール</ 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>
</機能> <能力COMPONENTID = "31"> <名前> SupportedLFBs </名前> <概要>サポートされているすべてのLFBsの一覧</シノプシス> <オプション/> <配列型= "可変サイズ"> <typeRef> SupportedLFBType </ typeRef> </アレイ> </機能> </機能> </ 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トポロジが変更されてもよいことが想定されます。値がfalseに存在し、設定されている場合は、FEのLFBトポロジが固定されています。トポロジが固定されている場合、SupportedLFBs要素が省略されてもよい、およびサポートされているLFBsのリストは、LFBトポロジー情報からCEによって推定されます。 ModifiableLFBTopologyがfalseの場合にサポートLFBsのリストが提供されている場合、CanOccurBeforeと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が含まれるべきである一つの機能はサポート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トポロジフェスは、指定されたクラスのLFBsが他LFBsに接続することができる方法についての情報を含むべきです。この情報は、指定されたLFBクラスが成功するかLFBトポロジで先行しているLFBクラス記述する必要があります。 FEは、ポートグループが与えられ、隣接するLFBクラスに接続することができるためにどのような情報を含むべきです。ポートグループ情報が省略された場合、すべてのポートグループが使用されてもよいことが想定されます。実装者は、実際の制約情報がCEのために誤解を招くだろうというようなものであると結論づけた場合に許容可能な発注とLFBsの接続にこの能力情報を省略してもよいです。
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のインスタンスを作成したり、破壊する能力を持っていないのFEについては、これは省略または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成分について説明クラスが後に起こり得るLFBsのリストを含む配列です。アレイエントリは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の出力ポートに接続された入力ポートを有することが可能です。 SupportedLFBに従うことができるLFBクラスはCanOccurAftersアレイエントリの（LFBAdjacencyLimitType dataTypeDefの）NeighborLFBコンポーネントによって識別されます。このネイバーのみ入力ポートグループの特定のセットに接続することができる場合、viaPort成分が含まれています。このコンポーネントはNeighborLFBの出力ポートに接続することができるSupportedLFBの各入力ポートグループのための1つのエントリと、アレイです。
(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アレイの各アレイ・エントリは一意NeighborLFBを持つ必要があり、このような各アレイ・エントリ内の各viaPortはSupportedLFBのはっきりと有効な入力ポート基を表す必要があります。LFBクラス定義スキーマがありませんこれらの一意性制約を含めます。）
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.
配列エントリはSupportedLFBは、トポロジに先行して、それらのLFBクラスを一覧表示します。このコンポーネントでは、配列値のviaPort成分のエントリはNeighborLFBに接続されてもよいSupportedLFBの出力ポートグループを表します。複数の出力ポートが正当所与NeighborLFBクラスに接続することができる場合CanOccurAftersと同様に、viaPortは複数のエントリを有していてもよいです。
(And a similar set of uniqueness constraints applies to the CanOccurBefore clauses, even though an LFB may occur both in CanOccurAfter and CanOccurBefore.)
（そして一意性制約の同様のセットは、LFBがCanOccurAfterとCanOccurBeforeの両方で起こり得るにもかかわらず、CanOccurBefore句に適用されます。）
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.
UseableParentLFBClasses配列は、存在する場合、親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.
これを可能にするために、FEは、LFBのインスタンスIDを割り当てることで、より拘束されなければなりません。通常、インスタンスIDは、LFBクラスで修飾されています。しかし、その親が特定LFBクラスは、すべての両方のインスタンスの両方にUseableParentLFBClassesに記載されている場合（または任意の複数のクラスは、共通の親をリストしている場合、）は、2つのLFBクラスが親を共有し、そして場合は別個のインスタンスを使用しなければなりません。これは、親クラスを用いた場合でもCE操作の操作により意図されるLFBインスタンスを決定するためにFEを可能にします。
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との間で情報を転送するための現在の予測符号化構造は、完全に不特定の情報を可能にする解析エラーを誘発する可能性が高いであろうようなものです。私たちは、情報がOctetStringにでエンコードされるように指定することもできますが、我々はそのオクテット文字列の内部フォーマットを定義する必要があります。
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の全体的な状態を運びます。可能な値は、文字列AdminDisable、OperDisable、およびOperEnableです。開始状態はOperDisableであり、そしてOperEnableへの移行は、FEによって制御されます。 CEはAdminDisableへ/からOperEnableからの移行を制御します。詳細については、のForCESプロトコル文書[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の力を介して現在アクセスLFBsに関する情報の配列です。 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コンポーネントは、各リンクがLFBLinkType dataTypeDefに記載されているFE、内部の各間LFBリンクについての情報を含みます。 LFBLinkType成分は正確リンクのエンドポイントを識別するために十分な情報を含みます。 FromLFBIDとToLFBIDコンポーネントは、リンクの各端にLFBインスタンスを指定し、LFBインスタンステーブルにLFBsを参照しなければなりません。 FromPortGroupとToPortGroupはFromLFBIDと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と他のFE間で手動で設定隣接関係に関する情報の配列です。アレイの内容は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に構成することができ、1つの配列エントリは、各構成隣人に対応CEによって必要とされる情報をキャプチャすることを意図しています。それらが自分のLFBsを持つことになりますように、この配列は、任意のディスカバリプロトコルの結果を表すものではないことに注意してください。このコンポーネントはオプションです。
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.
隣人を構成する多くの方法があるかもしれませんが、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で概説要件を満たす方法について説明します。そしてFEモデルがサポートしなければならない論理機能（セクション5.5）の最小セットの仕様 - 要件は、一般的な要件（5.4節5、5.1）に分離することができます。
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によって構成されているかどうかを示します。設定可能なコンポーネントは、CEにLFBの動作を指定する際にある程度の柔軟性を提供します。同じLFBクラスに属する複数LFBsをFEにインスタンス化される場合、それらLFBsの各々は、異なるコンポーネントの設定を構成することができます。インスタンス化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).
インスタンス化LFBsは、FE内の機能の順序を記述した有向グラフで相互接続されています。この有向グラフは、トポロジ・モデルによって記述されます。インスタンス化LFBsとトポロジーの構成要素の組み合わせは、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モデルのもう一つの重要な要素は、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自体の定義のみを含んでいます。ワーキンググループの要件の完全なセットを満たすことは、他のLFBsが必要です。これらLFBsのためのクラス定義は、他の文書で提供されます。
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に転送プレーンの実際のモデルでは、CEは複数のFE（又は他の手段によって）と通信することにより学習し、制御しなければならないものです。この通信のほとんどはのForCESプロトコルを使用して、ポスト関連のフェーズで発生します。以下のタイプの情報は、のForCESプロトコル[RFC5810]を介してCEとFEとの間で交換されなければなりません。
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の情報の主な流れはCEにのFEからなるクエリ交換です。彼らは繰り返しPA相中の任意の時点で照会することができるものの項目1〜4は、典型的には、後のアソシエーション（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は、情報の主な流れはのFEへのCEである交流の「コマンド」の種類です。項目6のメッセージ（LFB再設定コマンド）が頻繁に使用されることが期待されます。アイテム7（LFBトポロジの再構成）が動的LFBトポロジがのFEによって支持され、まれに使用されることが期待されている場合にのみ必要とされています。
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によって決定することができます。この文書ものForCESプロトコル[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）のForCESベースプロトコルの一部であり、残りは、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:
これらのメッセージの実際の符号化は、のForCESプロトコル[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クラスで定義しなければならない場合にLFBsの成分、として表すことができます。
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).
適切なプロトコルフォーマットと（XMLなど、のTLV）実際の符号化方法を選択するのを助けることができるのFEとCEとの間で交換されなければならない情報のタイプを理解O。
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つのカスケードのFEを示しています。 FE＃2は、一つの外部出力インターフェイスが、無入力インターフェイスを含むがFE＃1は、一つの外部入力インターフェースなくない外部出力インターフェイスを含んでいます。完全な入力対出力パケット処理機能を達成するために、それらの内部インターフェースを介して一緒にこれら二つのFEを接続することが可能です。これは、複数のFEを横切って機能を広げ、特定の用途のために、後でそれらを一緒に相互接続するための柔軟性を提供します。
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.
間FE通信プロトコルは、力を範囲外であるが、それは、図13に記載されるように、完全な入力 - 出力パケット処理機能を実行するために相互接続されているどのように複数のFE照会と理解するCEまでですインターFEトポロジ情報は、複数のFEによって提供されているCEにハードコードされてもよいし、複数のFEから独立他のエンティティ（例えば、バスマネージャ）によって提供されてもよいです。 CEはそれを使用するのでのForCESプロトコル[RFC5810]はのFEからFEトポロジクエリをサポートしながら、それは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：一緒に接続された二つのFEの例。
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.
間FEトポロジは、このクエリの後にCEによって発見されると、間FEトポロジが静的なままであることを想定しています。しかし、FEはNEの操作中にダウンしたり、ボードが挿入され、新しいFEが有効なので、間FEトポロジが影響される可能性があります。それは、このようなイベントを検出し、FEトポロジの変化に対処するためのCEのためのメカニズムを提供することを強制プロトコル次第です。 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:
FEは、制限の多くの種類があります。制限のいくつかは、能力モデルの一部としてCEに表現しなければなりません。 CEはあたり-FEベースでこれらの機能を照会することができなければなりません。例としては、次のとおりです。
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).
（FEのすべてLFBsに適用）Oグローバルリソースクエリの制限。
o LFB supported by the FE.
OのLFBはFEでサポートされています。
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.
CEがFEにLFBインスタンスの現在のセットとFE内LFBs間の相互接続を発見するためのForCESプロトコル手段を提供しなければなりません。加えて、十分な情報が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クラス仕様は、機能の一般的なセットを定義します。 LFBインスタンスはベンダーのFE上に実装（インスタンス化）されたときに、いくつかの追加の制約を導入してもよいです。我々は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によって検出されたときに、この機能の問い合わせは通常起こります。機能は、静的な制限がある場合には、再照会する必要はありません。いくつかのケースでは、しかし、いくつかの機能は、追加のメカニズムがするように実装しなければならない場合には、（他のLFBsを追加/削除、またはLFBsが物理リソースを共有する場合、いくつかの他の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:
この機能は、すべてのFEによって提供されなければなりません。プロトコルによって搬送のForCESプロトコルとデータスキーマ/符号化は、一緒に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を参照するために主であるが、グループ（またはすべて）を参照のFEは、必要に応じてサポートしてもよいです。
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インスタンスを参照するために主であるが、必要に応じてのグループのアドレス（またはすべて）LFBsが支持されていてもよいです。
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 yの所定の入力にLFB xの所定の出力を接続します。
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の定義が含まれています。 LFBsのいくつかのプロパティは、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.
この例の後部分はプロトコル動作への参照を含みます。記載された動作は、プロトコルがサポートする必要がある操作です。 ForCESプロトコル[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">
<？xml version = "1.0" エンコード= "UTF-8"？> <LFBLibrary =のxmlns "壷：IETF：のparams：XML：NS：力：lfbmodel：1.0" のxmlns：XSI = "のhttp：//www.w3スタッフィング無し/ 2001 / XMLスキーマ・インスタンス.ORG」を提供= "LaserFrameLFB"> <frameDefs> <frameDef> <名前> FRFrame </名前> <概要> DLCIのフレーム・リレー・フレーム、）</概要> </ frameDef> <frameDef> <名前> IPFrame </名前> <概要> IPパケット</概要> </ frameDef> </ frameDefs> <dataTypeDefs> <dataTypeDef> <名前> frequencyInformationType </名前> <概要>シングルに関する情報CWDM周波数</シノプシス> <構造体> <コンポーネントのComponentID = "1"> <名前> LaserFrequency </名前> <概要>符号化された周波数（チャネル）</シノプシス> <typeRef> UINT32 </ typeRef> </成分> <コンポーネントの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>
</成分> </構造体> </ dataTypeDef> <dataTypeDef> <名前> PortStatusValues </名前> <概要>ステータスの可能な値。両方の管理ステータスおよび動作ステータスのために使用される</概要> <原子> <baseType> UCHAR </ baseType> <specialValues> <specialValue値= "0"> <名前>無効</名前> <概要>コンポーネントが無効になっています</概要> </ specialValue> <specialValue値= "1"> <名前>有効</名前> <概要> FEが作動有効になっている</概要> </ specialValue> </ specialValues> </アトミック> </ dataTypeDef> < / dataTypeDefs> <metadataDefs> <metadataDef> <名前> DLCI </名前> <概要>フレームに到着DLCI </シノプシス> <metadataID> 12 </ metadataID> <typeRef> UINT32 </ typeRef> </ metadataDef> <metadataDef> <名前> LaserChannel </名前> <概要>レーザチャンネルのインデックス</シノプシス> <metadataID> 34 </ metadataID> <typeRef> UINT32 </ typeRef> </ metadataDef> </ metadataDefs> <LFBClassDefs > <！ - ダミーのclassidが、有効な値にする必要がある - デモンストレーション</概要> <バージョンの> <LFBClassDef LFBClassID = "255"> <名前> FrameLaserLFB </名前> <概要>架空のLFB> 1.0 < /バージョン> <inputPorts> <inputPortグループ= "真"> <名前> LMIfromFE </ナムE> <概要>
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
</シノプシス> <製品> <frameProduced> <参考文献> IPFrame </ ref>を</ frameProduced> <metadataProduced> <参考文献> DLCI </ REF> <参考文献> LaserChannel </ ref>を</ metadataProduced> </製品> < /出力ポート> </ outputPorts> <成分> <成分アクセス= "読み書き" COMPONENTID = "1"> <名前> AdminPortState </名前> <概要>このポートを機能させることができる</シノプシス> <typeRef> PortStatusValues CWDM周波数あたりの情報の</ typeRef> </コンポーネント> <成分アクセス= "読み書き" COMPONENTID = "2"> <名前> FrequencyInformation </名前> <概要>テーブル</シノプシス> <配列型= "変数-size "> <typeRef> frequencyInformationType </ typeRef> </アレイ> </成分> </部品> <機能> <能力COMPONENTID =" 31" > <名前> OperationalState </名前> <概要>上ポートかすべてが正常に動作している</概要> <typeRef> PortStatusValues </ typeRef> </機能> <機能COMPONENTID = "32"> <名前> MaximumFrequencies </名前> <概要>レーザー周波数がどのくらいあるかが</概要> <typeRef > uint16の</ typeRef> </機能> <capabilit Y COMPONENTID = "33"> <名前> MaxTotalCircuits </名前> <概要>トータルサポート可能なフレームリレー回線、全体のすべてのレーザーの周波数
</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>
</シノプシス> <オプション/> <typeRef> UINT32 </ typeRef> </機能> </機能> <イベントbaseID = "61"> <イベントのeventID = "1"> <名前> FrequencyState </名前> <概要>周波数の状態が変更された</シノプシス> <のEventTarget> <eventField> FrequencyInformation </ eventField> <eventSubscript> _FrequencyIndex _ </ eventSubscript> <eventField> FrequencyState </ eventField> </のEventTarget> <eventChanged /> <eventReports> <！ - 新しい状態を報告 - > <eventReport> <eventField> FrequencyInformation </ eventField> <eventSubscript> _FrequencyIndex _ </ eventSubscript> <eventField> FrequencyState </ eventField> </ eventReport> </ eventReports> </イベント> <イベントのeventID = "2"> <名前> CreatedFrequency </名前> <概要>新しい周波数が登場している</概要> <のEventTarget> <eventField> FrequencyInformation> </ eventField> <eventSubscript> _FrequencyIndex _ </ eventSubscript> </ EventTarget> <eventCreated /> <eventReports> <eventReport> <eventField> FrequencyInformation </ eventField> <eventSubscript> _FrequencyIndex _ </ eventSubscript> <eventFi ELD> LaserFrequency </ eventField> </ eventReport> </ eventReports> </イベント> <イベントのeventID = "3"> <名前> DeletedFrequency </名前> <概要>周波数テーブルエントリが削除された</概要> < 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>
<eventField> FrequencyInformation </ eventField> <eventSubscript> _FrequencyIndex _ </ eventSubscript> </のEventTarget> <eventDeleted /> </イベント> <イベントのeventID = "4"> <名前> PowerProblem </名前> <概要>問題がありますレーザパワーレベル</シノプシス> <のEventTarget> <eventField> FrequencyInformation </ eventField> <eventSubscript> _FrequencyIndex _ </ eventSubscript> <eventField>レーザパワー</ eventField> </のEventTarget> <eventLessThan /> <eventReports> <eventReport>と<eventField> FrequencyInformation </ eventField> <eventSubscript> _FrequencyIndex _ </ eventSubscript> <eventField>レーザパワー</ eventField> </ eventReport> <eventReport> <eventField> FrequencyInformation </ eventField> <eventSubscript> _FrequencyIndex _ </ eventSubscript> <eventField> LaserFrequency </ eventField> </ eventReport> </ eventReports> </イベント> <イベントのeventID = "5"> <名前> FrameCircuitChanged </名前> <概要>周波数でのFR回路の状態が変化した</シノプシス> <の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>
<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> </イベント> </イベント> </ 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に向けSET要求を送信します。要求は、次のようになります
T = SET T = PATH-DATA Path: flags = none, length = 4, path = 2, channel, 4, entryIdx DataRaw: DLCI, Enabled(1), false, out-idx
T = T SET = PATHデータパス：フラグ=なし、長さ= 4、パス= 2、チャネル4、entryIdx DataRaw：DLCIは、（1）、偽、アウト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.)
これは有効として、トラフィックは、出力ポートグループDatatoFEの特定のエントリに行くと、DLCIを確立します。 （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.
一つの方法は、エラーをカウントする特定のコンポーネント、およびパケットの必要な部分を保持するための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情報を運ぶものとして扱われるべきであるかどうか、DLCI、演算回路の状態を含み、LFBトラフィックの出力ポートグループ内のどのポートに送信されます。上述したように、回路インデックスは、いくつかの設計では、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
このLFBのための能力情報は、基礎となるインタフェースがサポートされ、そしてどのように多くの合計回路いるどのように多くの周波数、動作可能であるかどうかを含み、すべてのチャネル間で、許可されています。所定のレーザチャネルの最大数はFrameRelayCircuitsテーブルの特性から決定することができます。パス2.channel.4にGET-PROPは、CEにその性質を与えます
FrameRelayCircuits array which include the number of entries used, the first available entry, and the maximum number of entries permitted.
使用されるエントリの数、使用可能な最初の項目、および許可エントリの最大数を含むFrameRelayCircuitsアレイ。
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は、冗長です。イベントレポートにおける二つの情報を含む表示するためにここに含まれています。
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.)
これは、テーブル内のすべてのエントリでイベントの登録を設定します。また、パワーが15を下回る場合、報告を引き起こし、イベントのためのしきい値を設定することになる（おそらく、CEは、スケールが電源用であり、意味のある問題レベルとして15を選択したものを知っています。）
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のマークに近いパワーで発振する場合、1は、通知の多くを得ることができます。 （それは、前後に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未満にフォールバックする必要があります。実際の値が右の境界付近にあるときの振動のこの形式の一つの共通の原因です。それは本当に9.5であれば、小さな変更が1のヒステリシスレベルが、状態のこの種のを抑制します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.
ForCESモデルはのForCESライブラリ定義を使用するためのユニークな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
URI：この名前空間のURIはURNです：IETF：のparams：XML：NS：力：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.
明確に定義されたのForCES LFBクラス、およびそれらのクラスのために明確に定義された識別子を持つために、IANAは、LFBのクラス名、対応するクラス識別子、およびLFBクラスを定義するドキュメントのレジストリを作成しました。レジストリポリシーは、単純に、まず、第1、来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割り当てを提供するので、そのスペースを使用しているクラスの命名規則を定義する必要があります。これらは誰でも定義することができるので、必要なルールは、IETF定義のクラス名と衝突からFCFSクラス名を維持することです。したがって、すべての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クラスの定義の位置と、のForCES LFBクラス名および対応のForCES 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
エレンDelganes、インテル社リリーヤン、インテル社ラムゴパル、ノキア・リサーチセンターアランDeKok、Infobloxの社ズソルト・ハラスズティ、クロービスソリューション
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モデルは、表現とフェスデータセットとコンポーネントの構成を記載しています。 ForCESフレームワークドキュメント[RFC3746]は全体のForCESアーキテクチャの総合的なセキュリティ分析を提供します。彼らは力により、この文書に記載された情報要素にアクセスする前に、例えば、のForCESプロトコルエンティティはのForCESの要件ごとに認証される必要があります。 FEモデルに含まれる情報へのアクセスは、別の文書で定義されているのForCESプロトコルを介して達成され、従って、セキュリティの問題が対処されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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]ドリア、A.編、ハディサリム、J.、編、ハース、R.、編、Khosravi、H.編、王、W.、編、ドン、L.、ゴパル、R.、およびJ.ハルパーン、 "転送と制御素子分離（のForCES）プロトコル仕様"、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]トンプソン、H.、ブナ、D.、マロニー、M.、およびN.メンデルゾーン、 "XMLスキーマパート1：構造"、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]ビロン、P.およびA.マルホトラ、 "XMLスキーマパート2：データ型"、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.アンダーソン、 "IP制御とフォワーディングの分離のための要件"、RFC 3654、2003年11月。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004.
[RFC3746]ヤン、L.、Dantu、R.、アンダーソン、T.、およびR.ゴパル、 "転送および制御素子分離（のForCES）フレームワーク"、RFC 3746、2004年4月。
[RFC3317] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie, "Differentiated Services Quality of Service Policy Information Base", RFC 3317, March 2003.
[RFC3317]チャン、K.、Sahita、R.、ハーン、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.、ハーン、S.、チャン、K.、およびK. McCloghrie、 "フレームワーク方針情報ベース"、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]ホレンベック、S.、ローズ、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]デイビス、M.と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
ジョエルハルパーン自己私書箱ボックス6049リーズバーグ、VA 20178 USA
Phone: +1 703 371 3043 EMail: jmh@joelhalpern.com
電話：+1 703 371 3043 Eメール：jmh@joelhalpern.com
Jamal Hadi Salim Znyx Networks Ottawa, Ontario Canada
ジャマル・ハディサリムZNYXネットワークオタワ、オンタリオ州カナダ
EMail: hadi@mojatatu.com
メールアドレス：hadi@mojatatu.com