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
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
转发和控制元素分离（ForCES）转发元素模型
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）模型。该模型表示ForCES协议上下文中转发元素的能力、状态和配置，以便控制元素（ce）可以相应地控制FEs。更具体地说，该模型描述了FE中存在的逻辑功能、这些功能支持的功能以及这些功能是如何互连的。该FE模型旨在满足RFC 3654中规定的模型要求。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5812.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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
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]指定了一个框架，通过该框架，控制元件（CE）可以使用ForCES协议配置和管理网元（NE）内的一个或多个独立转发元件（FEs）。ForCES体系结构允许具有不同功能的转发元素参与ForCES网元。这种不同功能的含义是，CEs只能对网元中FEs提供的功能进行最低限度的假设。在CEs能够配置和控制FEs的转发行为之前，CEs需要查询和发现其FEs的功能和状态。RFC 3654[RFC3654]要求以FE模型的形式表示能力、状态和配置信息。
RFC 3444 [RFC3444] observed that information models (IMs) and data models (DMs) are different because they serve different purposes. "The main purpose of an IM is to model managed objects at a conceptual level, independent of any specific implementations or protocols used". "DMs, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs". Sometimes it is difficult to draw a clear line between the two. The FE model described in this document is primarily an information model, but also includes some aspects of a data model, such as explicit definitions of the LFB (Logical Functional Block) class schema and FE schema. It is expected that this FE model will be used as the basis to define the payload for information exchange between the CE and FE in the ForCES protocol.
RFC 3444[RFC3444]观察到，信息模型（IMs）和数据模型（DMs）是不同的，因为它们服务于不同的目的。“IM的主要目的是在概念级别对托管对象进行建模，独立于使用的任何特定实现或协议”。“相反，DMs是在较低的抽象级别上定义的，包含许多细节。它们面向实现者，并包含特定于协议的构造”。有时很难在两者之间划清界限。本文档中描述的FE模型主要是一个信息模型，但也包括数据模型的一些方面，例如LFB（逻辑功能块）类模式和FE模式的显式定义。预计该FE模型将用作定义CE和FE之间在ForCES协议中进行信息交换的有效载荷的基础。
RFC 3654 [RFC3654] defines requirements that must be satisfied by a ForCES FE model. To summarize, an FE model must define:
RFC 3654[RFC3654]定义了部队有限元模型必须满足的要求。总之，FE模型必须定义：
o Logically separable and distinct packet forwarding operations in an FE data path (Logical Functional Blocks or LFBs);
o FE数据路径（逻辑功能块或LFB）中逻辑上可分离和不同的分组转发操作；
o The possible topological relationships (and hence the sequence of packet forwarding operations) between the various LFBs;
o 各种lfb之间可能的拓扑关系（以及包转发操作的序列）；
o The possible operational capabilities (e.g., capacity limits, constraints, optional features, granularity of configuration) of each type of LFB;
o 每种LFB的可能操作能力（例如，容量限制、约束、可选功能、配置粒度）；
o The possible configurable parameters (e.g., components) of each type of LFB; and
o 每种类型LFB的可能可配置参数（例如组件）；和
o Metadata that may be exchanged between LFBs.
o 可在LFB之间交换的元数据。
The FE model proposed here is based on an abstraction using distinct Logical Functional Blocks (LFBs), which are interconnected in a directed graph, and receive, process, modify, and transmit packets along with metadata. The FE model is designed, and any defined LFB classes should be designed, such that different implementations of the forwarding data path can be logically mapped onto the model with the functionality and sequence of operations correctly captured. However, the model is not intended to directly address how a particular implementation maps to an LFB topology. It is left to the forwarding plane vendors to define how the FE functionality is represented using the FE model. Our goal is to design the FE model such that it is flexible enough to accommodate most common implementations.
本文提出的FE模型基于使用不同逻辑功能块（LFB）的抽象，这些逻辑功能块在有向图中相互连接，并与元数据一起接收、处理、修改和传输数据包。设计FE模型，并设计任何定义的LFB类，以便转发数据路径的不同实现可以逻辑映射到模型上，并正确捕获功能和操作序列。然而，该模型并不打算直接解决特定实现如何映射到LFB拓扑。由转发平面供应商定义如何使用FE模型表示FE功能。我们的目标是设计FE模型，使其足够灵活，以适应大多数常见的实现。
The LFB topology model for a particular data path implementation must correctly capture the sequence of operations on the packet. Metadata generation by certain LFBs MUST always precede any use of that metadata by subsequent LFBs in the topology graph; this is required for logically consistent operation. Further, modification of packet fields that are subsequently used as inputs for further processing MUST occur in the order specified in the model for that particular implementation to ensure correctness.
特定数据路径实现的LFB拓扑模型必须正确捕获数据包上的操作序列。某些LFB的元数据生成必须始终先于拓扑图中后续LFB对该元数据的任何使用；这是逻辑上一致的操作所必需的。此外，随后用作进一步处理输入的数据包字段的修改必须按照该特定实现的模型中指定的顺序进行，以确保正确性。
The ForCES base protocol [RFC5810] is used by the CEs and FEs to maintain the communication channel between the CEs and FEs. The ForCES protocol may be used to query and discover the intra-FE topology. The details of a particular data path implementation inside an FE, including the LFB topology, along with the operational capabilities and attributes of each individual LFB, are conveyed to the CE within information elements in the ForCES protocol. The model of an LFB class should define all of the information that needs to be exchanged between an FE and a CE for the proper configuration and management of that LFB.
CEs和FEs使用ForCES base协议[RFC5810]来维护CEs和FEs之间的通信信道。ForCES协议可用于查询和发现内部FE拓扑。FE内部特定数据路径实现的细节，包括LFB拓扑，以及每个单独LFB的作战能力和属性，在ForCES协议的信息元素内传递给CE。LFB类的模型应定义FE和CE之间需要交换的所有信息，以便正确配置和管理该LFB。
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和LFB），则很难以系统方式指定ForCES消息的各种有效载荷。FE模型文档定义了一组类和组件，用于描述和操作FE中LFB的状态。这些类定义本身通常不会出现在
ForCES protocol. Rather, ForCES protocol operations will reference classes defined in this model, including relevant components and the defined operations.
部队协议。相反，ForCES协议操作将引用此模型中定义的类，包括相关组件和定义的操作。
Section 7 provides more detailed discussion on how the FE model should be used by the ForCES protocol.
第7节更详细地讨论了部队协议应如何使用有限元模型。
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.
尽管不是绝对必需的，但使用正式的数据建模语言来表示本文中描述的概念性有限元模型是有益的。使用形式化语言有助于加强LFB之间的一致性和逻辑兼容性。将使用这种数据建模语言编写完整的规范。LFB类的正式定义可能有助于某些代码生成过程的最终自动化以及任意LFB拓扑的功能验证。这些类定义构成LFB库。因此，描述LFB类的文档称为LFB库文档。
Human readability was the most important factor considered when selecting the specification language, whereas encoding, decoding, and transmission performance were not a selection factor. The encoding method for over-the-wire transport is not dependent on the specification language chosen and is outside the scope of this document and up to the ForCES protocol to define.
人类可读性是选择规范语言时考虑的最重要因素，而编码、解码和传输性能不是选择因素。有线传输的编码方法不依赖于所选的规范语言，不在本文档范围内，由ForCES协议定义。
XML is chosen as the specification language in this document, because XML has the advantage of being both human and machine readable with widely available tools support. This document uses an XML schema to define the structure of the LFB library documents, as defined in [RFC3470] and [Schema1] and [Schema2]. While these LFB class definitions are not sent in the ForCES protocol, these definitions comply with the recommendations in RFC 3470 [RFC3470] on the use of XML in IETF protocols.
在本文档中，选择XML作为规范语言，因为XML的优点是，在广泛可用的工具支持下，它具有可读性和机器可读性。本文档使用XML模式来定义LFB库文档的结构，如[RFC3470]和[Schema1]和[Schema2]中所定义。虽然这些LFB类定义未在ForCES协议中发送，但这些定义符合RFC 3470[RFC3470]中关于在IETF协议中使用XML的建议。
By using an XML schema to define the structure for the LFB library documents, we have a very clear set of syntactic restrictions to go with the desired semantic descriptions and restrictions covered in this document. As a corollary to that, if it is determined that a change in the syntax is needed, then a new schema will be required. This would be identified by a different URN to identify the namespace for such a new schema.
通过使用XML模式来定义LFB库文档的结构，我们有一组非常明确的语法限制，以符合本文档中所涉及的所需语义描述和限制。因此，如果确定需要更改语法，则需要一个新的模式。这将由另一个URN标识，以标识这样一个新模式的名称空间。
Section 3 provides a conceptual overview of the FE model, laying the foundation for the more detailed discussion and specifications in the sections that follow. Section 4 and Section 5 constitute the core of the FE model, detailing the two major aspects of the FE model: a general LFB model and a definition of the FE Object LFB, with its components, including FE capabilities and LFB topology information. Section 6 directly addresses the model requirements imposed by the ForCES requirements defined in RFC 3654 [RFC3654], while Section 7 explains how the FE model should be used in the ForCES protocol.
第3节提供了FE模型的概念性概述，为后续章节中更详细的讨论和规范奠定了基础。第4节和第5节构成了FE模型的核心，详细说明了FE模型的两个主要方面：通用LFB模型和FE对象LFB的定义，以及其组件，包括FE功能和LFB拓扑信息。第6节直接阐述了RFC 3654[RFC3654]中定义的部队要求所施加的模型要求，而第7节解释了FE模型应如何在部队协议中使用。
The use of compliance terminology (MUST, SHOULD, MAY, MUST NOT) is used in accordance with RFC 2119 [RFC2119]. Such terminology is used in describing the required behavior of ForCES forwarding elements or control elements in supporting or manipulating information described in this model.
合规术语（必须、应该、可能、不得）的使用符合RFC 2119[RFC2119]的规定。此类术语用于描述转发元素或控制元素在支持或操作此模型中描述的信息时所需的行为。
Terminology associated with the ForCES requirements is defined in RFC 3654 [RFC3654] and is not copied here. The following list of terminology relevant to the FE model is defined in this section.
RFC 3654[RFC3654]中定义了与部队需求相关的术语，此处未复制。本节定义了以下与FE模型相关的术语列表。
FE Model: The FE model is designed to model the logical processing functions of an FE. The FE model proposed in this document includes three components; the LFB modeling of individual Logical Functional Block (LFB model), the logical interconnection between LFBs (LFB topology), and the FE-level attributes, including FE capabilities. The FE model provides the basis to define the information elements exchanged between the CE and the FE in the ForCES protocol [RFC5810].
FE模型：FE模型旨在对FE的逻辑处理功能进行建模。本文件中提出的有限元模型包括三个部分：；单个逻辑功能块的LFB建模（LFB模型）、LFB之间的逻辑互连（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处理的细粒度、逻辑可分离方面的模板。大多数LFB与数据路径中的数据包处理有关。LFB类是FE模型的基本构建块。
LFB Instance: As a packet flows through an FE along a data path, it flows through one or multiple LFB instances, where each LFB is an instance of a specific LFB class. Multiple instances of the same LFB class can be present in an FE's data path. Note that we often
LFB实例：当数据包沿着数据路径流经FE时，它流经一个或多个LFB实例，其中每个LFB都是特定LFB类的实例。同一LFB类的多个实例可以出现在FE的数据路径中。注意，我们经常
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而不区分LFB类和LFB实例。
LFB Model: The LFB model describes the content and structures in an LFB, plus the associated data definition. XML is used to provide a formal definition of the necessary structures for the modeling. Four types of information are defined in the LFB model. The core part of the LFB model is the LFB class definitions; the other three types of information define constructs associated with and used by the class definition. These are reusable data types, supported frame (packet) formats, and metadata.
LFB模型：LFB模型描述LFB中的内容和结构，以及相关的数据定义。XML用于提供建模所需结构的正式定义。LFB模型中定义了四种类型的信息。LFB模型的核心部分是LFB类定义；其他三种类型的信息定义与类定义关联并由类定义使用的构造。这些是可重用的数据类型、支持的帧（数据包）格式和元数据。
Element: Element is generally used in this document in accordance with the XML usage of the term. It refers to an XML tagged part of an XML document. For a precise definition, please see the full set of XML specifications from the W3C. This term is included in this list for completeness because the ForCES formal model uses XML.
元素：元素通常根据术语的XML用法在本文档中使用。它是指XML文档中带有XML标记的部分。有关精确定义，请参阅W3C提供的完整XML规范集。为了完整起见，此列表中包含了此术语，因为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用法，在ForCES正式建模中使用属性，即提供XML标记中包含的属性信息。
LFB Metadata: Metadata is used to communicate per-packet state from one LFB to another, but is not sent across the network. The FE model defines how such metadata is identified, produced, and consumed by the LFBs, but not how the per-packet state is implemented within actual hardware. Metadata is sent between the FE and the CE on redirect packets.
LFB元数据：元数据用于将每个数据包状态从一个LFB传送到另一个LFB，但不会通过网络发送。FE模型定义了LFB如何识别、生成和使用这些元数据，而不是如何在实际硬件中实现每包状态。元数据在重定向数据包上的FE和CE之间发送。
ForCES Component: A ForCES Component is a well-defined, uniquely identifiable and addressable ForCES model building block. A component has a 32-bit ID, name, type, and an optional synopsis description. These are often referred to simply as components.
力组件：力组件是定义良好、唯一可识别和可寻址的力模型构建块。组件具有32位ID、名称、类型和可选的概要描述。这些通常被简单地称为组件。
LFB Component: An LFB component is a ForCES component that defines the Operational parameters of the LFBs that must be visible to the CEs.
LFB组件：LFB组件是一个力组件，用于定义必须对CEs可见的LFB的操作参数。
Structure Component: A ForCES component that is part of a complex data structure to be used in LFB data definitions. The individual parts that make up a structured set of data are referred to as structure components. These can themselves be of any valid data type, including tables and structures.
结构组件：作为复杂数据结构一部分的强制组件，用于LFB数据定义。构成结构化数据集的各个部分称为结构组件。它们本身可以是任何有效的数据类型，包括表和结构。
Property: ForCES components have properties associated with them, such as readability. Other examples include lengths for variable-sized components. These properties are accessed by the CE for reading (or, where appropriate, writing.) Details on the ForCES properties are found in Section 4.8.
属性：力组件具有与其关联的属性，例如可读性。其他示例包括可变尺寸部件的长度。CE可访问这些属性进行读取（或在适当情况下写入）。有关力属性的详细信息，请参见第4.8节。
LFB Topology: LFB topology is a representation of the logical interconnection and the placement of LFB instances along the data path within one FE. Sometimes this representation is called intra-FE topology, to be distinguished from inter-FE topology. LFB topology is outside of the LFB model, but is part of the FE model.
LFB拓扑：LFB拓扑表示逻辑互连和LFB实例沿一个FE内的数据路径放置。有时，这种表示称为内部FE拓扑，以区别于内部FE拓扑。LFB拓扑位于LFB模型之外，但属于有限元模型的一部分。
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拓扑，以区别于内部FE拓扑（即LFB拓扑）。单个FE可能不具备完整FE拓扑的全局知识，但其与其他FE连接的局部视图被视为FE模型的一部分。FE拓扑是通过ForCES base协议或其他方式发现的。
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类库是一组LFB类，已被确定为大多数FEs中最常见的函数，因此应首先由ForCES工作组定义。
Some of the important ForCES concepts used throughout this document are introduced in this section. These include the capability and state abstraction, the FE and LFB model construction, and the unique addressing of the different model structures. Details of these aspects are described in Section 4 and Section 5. The intent of this section is to discuss these concepts at the high level and lay the foundation for the detailed description in the following sections.
本节介绍了本文件中使用的一些重要力概念。这些包括能力和状态抽象、FE和LFB模型构造，以及不同模型结构的独特寻址。第4节和第5节描述了这些方面的细节。本节的目的是在高层次上讨论这些概念，并为下文的详细描述奠定基础。
The ForCES FE model includes both a capability and a state abstraction.
部队有限元模型包括能力和状态抽象。
o The FE/LFB capability model describes the capabilities and capacities of an FE/LFB by specifying the variation in functions supported and any limitations. Capacity describes the limits of specific components (an example would be a table size limit).
o FE/LFB能力模型通过指定所支持功能的变化和任何限制来描述FE/LFB的能力和能力。容量描述特定组件的限制（例如表格大小限制）。
o The state model describes the current state of the FE/LFB, that is, the instantaneous values or operational behavior of the FE/ LFB.
o 状态模型描述FE/LFB的当前状态，即FE/LFB的瞬时值或操作行为。
Section 3.1 explains the difference between a capability model and a state model, and describes how the two can be combined in the FE model.
第3.1节解释了能力模型和状态模型之间的区别，并描述了如何在FE模型中将两者结合起来。
The ForCES model construction laid out in this document allows an FE to provide information about its structure for operation. This can be thought of as FE-level information and information about the individual instances of LFBs provided by the FE.
本文件中列出的力模型结构允许FE提供有关其运行结构的信息。这可以被认为是FE级别的信息以及FE提供的LFB的各个实例的信息。
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 ForCES模型包括用于定义FE可能支持的逻辑功能块（LFB）类的结构。这些类在本文档和其他文档中定义。此类类的定义提供了用于监控LFB类实例的信息内容，以供部队使用。每个LFB模型类正式定义操作LFB组件、LFB功能和LFB事件。本质上，第3.2节介绍了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 有限元模型还提供了必要的结构，以监测和控制有限元作为一个整体，以达到受力的目的。为了操作的一致性和简单性，该信息表示为LFB、FE对象LFB类和该类的单个LFB实例，使用LFB模型定义。FE对象类定义了在FE级别提供信息的组件，特别是粗略级别的FE能力，即，并非所有可能的能力或FE能力的所有细节。FE级信息的一部分是LFB拓扑，它表示LFB实例之间沿FE内的数据路径的逻辑互连。第3.3节讨论LFB拓扑。FE对象还包括有关FE可以支持哪些LFB类的信息。
The ForCES model allows for unique identification of the different constructs it defines. This includes identification of the LFB classes, and of LFB instances within those classes, as well as identification of components within those instances.
力模型允许对其定义的不同构造进行唯一标识。这包括LFB类和这些类中LFB实例的标识，以及这些实例中组件的标识。
The ForCES protocol [RFC5810] encapsulates target address(es) to eventually get to a fine-grained entity being referenced by the CE. The addressing hierarchy is broken into the following:
强制协议[RFC5810]封装目标地址，最终到达CE引用的细粒度实体。寻址层次结构分为以下几部分：
o An FE is uniquely identified by a 32-bit FEID.
o FE由32位FEID唯一标识。
o Each class of LFB is uniquely identified by a 32-bit LFB ClassID. The LFB ClassIDs are global within the network element and may be issued by IANA.
o 每个LFB类由32位LFB ClassID唯一标识。LFB ClassID在网元内是全局的，可以由IANA发布。
o Within an FE, there can be multiple instances of each LFB class. Each LFB class instance is identified by a 32-bit identifier that is unique within a particular LFB class on that FE.
o 在FE中，每个LFB类可以有多个实例。每个LFB类实例由32位标识符标识，该标识符在该FE上的特定LFB类中是唯一的。
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显示了通过ForCES协议进行CE-FE通信时FE状态、能力和配置的概念。
+-------+ +-------+
| | FE capabilities: what it can/cannot do. | |
| |<-----------------------------------------| |
| | | |
| CE | FE state: what it is now. | FE |
| |<-----------------------------------------| |
| | | |
| | FE configuration: what it should be. | |
| |----------------------------------------->| |
+-------+ +-------+
+-------+ +-------+
| | FE capabilities: what it can/cannot do. | |
| |<-----------------------------------------| |
| | | |
| CE | FE state: what it is now. | FE |
| |<-----------------------------------------| |
| | | |
| | FE configuration: what it should be. | |
| |----------------------------------------->| |
+-------+ +-------+
Figure 1: Illustration of FE capabilities, state, and configuration exchange in the context of CE-FE communication via ForCES.
图1：通过部队进行CE-FE通信时FE能力、状态和配置交换的说明。
Conceptually, the FE capability model tells the CE which states are allowed on an FE, with capacity information indicating certain quantitative limits or constraints. Thus, the CE has general knowledge about configurations that are applicable to a particular FE.
从概念上讲，FE能力模型告诉CE FE上允许哪些状态，能力信息表示某些定量限制或约束。因此，CE具有适用于特定FE的配置的一般知识。
The FE capability model may be used to describe an FE at a coarse level. For example, an FE might be defined as follows:
FE能力模型可用于粗略描述FE。例如，FE的定义如下：
o the FE can handle IPv4 and IPv6 forwarding;
o FE可以处理IPv4和IPv6转发；
o the FE can perform classification based on the following fields: source IP address, destination IP address, source port number, destination port number, etc.;
o FE可以根据以下字段进行分类：源IP地址、目的IP地址、源端口号、目的端口号等。；
o the FE can perform metering;
o FE可以进行计量；
o the FE can handle up to N queues (capacity); and
o FE最多可处理N个队列（容量）；和
o the FE can add and remove encapsulating headers of types including IPsec, GRE, L2TP.
o FE可以添加和删除类型为IPsec、GRE、L2TP的封装头。
While one could try to build an object model to fully represent the FE capabilities, other efforts found this approach to be a significant undertaking. The main difficulty arises in describing detailed limits, such as the maximum number of classifiers, queues, buffer pools, and meters that the FE can provide. We believe that a good balance between simplicity and flexibility can be achieved for the FE model by combining coarse-level-capability reporting with an error reporting mechanism. That is, if the CE attempts to instruct the FE to set up some specific behavior it cannot support, the FE will return an error indicating the problem. Examples of similar approaches include Diffserv PIB RFC 3317 [RFC3317] and framework PIB RFC 3318 [RFC3318].
虽然可以尝试构建一个对象模型来充分表示FE能力，但其他工作发现这种方法是一项重要的任务。主要的困难在于描述详细的限制，例如FE可以提供的分类器、队列、缓冲池和仪表的最大数量。我们相信，通过将粗略级别的能力报告与错误报告机制相结合，FE模型可以实现简单性和灵活性之间的良好平衡。也就是说，如果CE试图指示FE设置其无法支持的某些特定行为，FE将返回一个指示问题的错误。类似方法的示例包括Diffserv PIB RFC 3317[RFC3317]和框架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类可以创建的实例数量、这些LFB实例之间的拓扑（链接）限制等。第5节定义了FE级别的组件，包括能力信息。由于所有信息都表示为LFB，因此这是由FE对象LFB类的单个实例提供的。通过使用具有已知LFB类和已知实例标识的单个实例，ForCES协议可以允许CE在需要时访问该信息，包括在CE建立对FE的控制时。
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状态信息可以在两个级别上表示。第一级是逻辑上可分离且不同的数据包处理函数，称为LFBs。第二级信息描述了这些单独的LFB是如何排序并沿数据路径放置以提供完整的转发平面服务的。LFB的互连和排序称为LFB拓扑。第3.2节讨论了LFB的高层概念，而第3.3节讨论了LFB拓扑问题。该拓扑信息表示为FE对象LFB实例的组件，以允许CE获取和操作该拓扑信息。
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
每个LFB对通过它的数据包执行定义良好的操作或计算。在完成其规定的功能后，要么以某些方式修改数据包（例如，去封装器、标记器），要么生成并存储一些结果，通常以
of metadata (e.g., classifier). Each LFB typically performs a single action. Classifiers, shapers, and meters are all examples of such LFBs. Modeling LFBs at such a fine granularity allows us to use a small number of LFBs to express the higher-order FE functions (such as an IPv4 forwarder) precisely, which in turn can describe more complex networking functions and vendor implementations of software and hardware. These fine-grained LFBs will be defined in detail in one or more documents to be published separately, using the material in this model.
元数据的类型（例如，分类器）。每个LFB通常执行一个动作。分类器、整形器和计量器都是此类LFB的示例。以如此精细的粒度对LFB进行建模，使我们能够使用少量LFB精确地表达高阶FE功能（例如IPv4转发器），这反过来又可以描述更复杂的网络功能以及软件和硬件的供应商实现。这些细粒度LFB将使用此模型中的材料在一个或多个单独发布的文档中详细定义。
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.
同样的情况是，lfb可以存在，以便提供一组组件用于控制CE的FE操作（即，控制点），而不将该控制绑定到数据路径的特定分组或特定部分。这种LFB的一个示例是FE对象，它向CE提供关于整个FE的信息，并允许FE控制FE的一些方面，例如数据路径本身。此类LFB将不具有本节中描述的面向数据包的属性。
In general, multiple LFBs are contained in one FE, as shown in Figure 2, and all the LFBs share the same ForCES protocol (Fp) termination point that implements the ForCES protocol logic and maintains the communication channel to and from the CE.
通常，多个LFB包含在一个FE中，如图2所示，并且所有LFB共享相同的ForCES协议（Fp）终结点，该终结点实现ForCES协议逻辑并维护与CE之间的通信信道。
+-----------+
| 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") |
| | +----------+ | | +----------+ | |
| +--------------+ +--------------+ |
| |
+--------------------------------------------------------------+
+-----------+
| CE |
+-----------+
^
| Fp reference point
|
+--------------------------|-----------------------------------+
| FE | |
| v |
| +----------------------------------------------------------+ |
| | ForCES protocol | |
| | termination point | |
| +----------------------------------------------------------+ |
| ^ ^ |
| : : Internal control |
| : : |
| +---:----------+ +---:----------| |
| | :LFB1 | | : LFB2 | |
| =====>| v |============>| v |======>...|
| Inputs| +----------+ |Outputs | +----------+ | |
| (P,M) | |Components| |(P',M') | |Components| |(P",M") |
| | +----------+ | | +----------+ | |
| +--------------+ +--------------+ |
| |
+--------------------------------------------------------------+
Figure 2: Generic LFB diagram.
图2：通用LFB图。
An LFB, as shown in Figure 2, may have inputs, outputs, and components that can be queried and manipulated by the CE via an Fp reference point (defined in RFC 3746 [RFC3746]) and the ForCES protocol termination point. The horizontal axis is in the forwarding plane for connecting the inputs and outputs of LFBs within the same FE. P (with marks to indicate modification) indicates a data packet, while M (with marks to indicate modification) indicates the metadata associated with a packet. The vertical axis between the CE and the FE denotes the Fp reference point where bidirectional communication between the CE and FE occurs: the CE-to-FE communication is for configuration, control, and packet injection, while the FE-to-CE communication is used for packet redirection to the control plane, reporting of monitoring and accounting information, reporting of errors, etc. Note that the interaction between the CE and the LFB is only abstract and indirect. The result of such an interaction is for the CE to manipulate the components of the LFB instances.
如图2所示，LFB可能具有可由CE通过Fp参考点（在RFC 3746[RFC3746]中定义）和ForCES协议终止点查询和操作的输入、输出和组件。水平轴位于转发平面内，用于连接同一FE内LFB的输入和输出。P（带有表示修改的标记）表示数据包，而M（带有表示修改的标记）表示与数据包关联的元数据。CE和FE之间的纵轴表示CE和FE之间发生双向通信的Fp参考点：CE到FE通信用于配置、控制和分组注入，而FE到CE通信用于分组重定向到控制平面，监控和会计信息报告、错误报告等。请注意，CE和LFB之间的互动只是抽象和间接的。这种交互的结果是CE操纵LFB实例的组件。
An LFB can have one or more inputs. Each input takes a pair of a packet and its associated metadata. Depending upon the LFB input port definition, the packet or the metadata may be allowed to be
LFB可以有一个或多个输入。每个输入获取一对数据包及其相关元数据。根据LFB输入端口定义，可以允许发送数据包或元数据
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时，数据包或其相关元数据必须是非空的，或者实际上没有输入。（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处理输入，并产生一个或多个输出，每个输出是一对数据包及其相关元数据。同样，根据LFB输出端口定义，包或元数据可能被允许为空（或等效地不存在）。在输出时附加到分组的元数据可以是接收到的元数据，或者可以是关于分组处理的信息，该信息可由以后的lfb在FEs分组处理中使用。
A namespace is used to associate a unique name and ID with each LFB class. The namespace MUST be extensible so that a new LFB class can be added later to accommodate future innovation in the forwarding plane.
命名空间用于将唯一的名称和ID与每个LFB类关联。名称空间必须是可扩展的，以便以后可以添加新的LFB类，以适应转发平面中的未来创新。
LFB operation is specified in the model to allow the CE to understand the behavior of the forwarding data path. For instance, the CE needs to understand at what point in the data path the IPv4 header TTL is decremented by the FE. That is, the CE needs to know if a control packet could be delivered to it either before or after this point in the data path. In addition, the CE needs to understand where and what type of header modifications (e.g., tunnel header append or strip) are performed by the FEs. Further, the CE works to verify that the various LFBs along a data path within an FE are compatible to link together. Connecting incompatible LFB instances will produce a non-working data path. So the model is designed to provide sufficient information for the CE to make this determination.
LFB操作在模型中指定，以允许CE了解转发数据路径的行为。例如，CE需要了解IPv4报头TTL在数据路径的哪个点被FE递减。也就是说，CE需要知道是否可以在数据路径中的该点之前或之后向其发送控制分组。此外，CE需要了解FEs在何处以及执行何种类型的标头修改（例如，隧道标头附加或剥离）。此外，CE用于验证FE内沿数据路径的各种lfb是否兼容链接在一起。连接不兼容的LFB实例将产生非工作数据路径。因此，该模型旨在为CE提供足够的信息，以进行此项确定。
Selecting the right granularity for describing the functions of the LFBs is an important aspect of this model. There is value to vendors if the operation of LFB classes can be expressed in sufficient detail so that physical devices implementing different LFB functions can be integrated easily into an FE design. However, the model, and the associated library of LFBs, must not be so detailed and so specific as to significantly constrain implementations. Therefore, a semi-formal specification is needed; that is, a text description of the LFB operation (human readable), but sufficiently specific and unambiguous to allow conformance testing and efficient design, so that interoperability between different CEs and FEs can be achieved.
选择合适的粒度来描述LFB的功能是该模型的一个重要方面。如果LFB类的操作可以足够详细地表示，以便实现不同LFB功能的物理设备可以轻松集成到FE设计中，则供应商将有价值。但是，该模型和相关的LFB库不能太详细、太具体，从而显著限制实现。因此，需要一个半正式的规范；也就是说，LFB操作的文本描述（人类可读），但足够具体和明确，以允许一致性测试和有效设计，从而实现不同CE和FEs之间的互操作性。
The LFB class model specifies the following, among other information:
除其他信息外，LFB类模型规定了以下信息：
o number of inputs and outputs (and whether they are configurable)
o 输入和输出的数量（以及是否可配置）
o metadata read/consumed from inputs
o 从输入读取/使用元数据
o metadata produced at the outputs
o 产出时产生的元数据
o packet types accepted at the inputs and emitted at the outputs
o 在输入端接受并在输出端发出的数据包类型
o packet content modifications (including encapsulation or decapsulation)
o 数据包内容修改（包括封装或去封装）
o packet routing criteria (when multiple outputs on an LFB are present)
o 数据包路由标准（当LFB上存在多个输出时）
o packet timing modifications
o 分组定时修改
o packet flow ordering modifications
o 分组流排序修改
o LFB capability information components
o LFB能力信息组件
o events that can be detected by the LFB, with notification to the CE
o LFB可检测到的事件，并通知CE
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.
如图3.a所示，一些LFB将具有单个输出。
+---------------+ +-----------------+
| | | |
| | | OUT +-->
... OUT +--> ... |
| | | EXCEPTIONOUT +-->
| | | |
+---------------+ +-----------------+
+---------------+ +-----------------+
| | | |
| | | 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 +-->
+-----------------+
+---------------+ +-----------------+
| | | 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。一个输出和一个输出组
Figure 3: Examples of LFBs with various output combinations.
图3：具有各种输出组合的LFB示例。
To accommodate a non-trivial LFB topology, multiple LFB outputs are needed so that an LFB class can fork the data path. Two mechanisms are provided for forking: multiple singleton outputs and output groups, which can be combined in the same LFB class.
为了适应非平凡的LFB拓扑，需要多个LFB输出，以便LFB类可以分叉数据路径。为分叉提供了两种机制：多个单例输出和输出组，它们可以组合在同一LFB类中。
Multiple separate singleton outputs are defined in an LFB class to model a predetermined number of semantically different outputs. That is, the LFB class definition MUST include the number of outputs, implying the number of outputs is known when the LFB class is defined. Additional singleton outputs cannot be created at LFB instantiation time, nor can they be created on the fly after the LFB is instantiated.
LFB类中定义了多个单独的单例输出，以对预定数量的语义不同的输出进行建模。也就是说，LFB类定义必须包括输出的数量，这意味着在定义LFB类时，输出的数量是已知的。其他单例输出不能在LFB实例化时创建，也不能在LFB实例化后动态创建。
For example, an IPv4 LPM (Longest-Prefix-Matching) LFB may have one output (OUT) to send those packets for which the LPM look-up was successful, passing a META_ROUTEID as metadata; and have another output (EXCEPTIONOUT) for sending exception packets when the LPM look-up failed. This example is depicted in Figure 3.b. Packets emitted by these two outputs not only require different downstream treatment, but they are a result of two different conditions in the LFB and each output carries different metadata. This concept assumes that the number of distinct outputs is known when the LFB class is defined. For each singleton output, the LFB class definition defines the types of frames (packets) and metadata the output emits.
例如，IPv4 LPM（最长前缀匹配）LFB可能有一个输出（OUT）来发送LPM查找成功的那些包，将META_ROUTEID作为元数据传递；并具有另一个输出（EXCEPTIONOUT），用于在LPM查找失败时发送异常数据包。该示例如图3.b所示。这两个输出发出的数据包不仅需要不同的下游处理，而且它们是LFB中两个不同条件的结果，每个输出携带不同的元数据。这个概念假设在定义LFB类时，不同输出的数量是已知的。对于每个单例输出，LFB类定义定义输出发出的帧（数据包）和元数据的类型。
An output group, on the other hand, is used to model the case where a flow of similar packets with an identical set of permitted metadata needs to be split into multiple paths. In this case, the number of such paths is not known when the LFB class is defined because it is not an inherent property of the LFB class. An output group consists of a number of outputs, called the output instances of the group, where all output instances share the same frame (packet) and metadata emission definitions (see Figure 3.c). Each output instance can connect to a different downstream LFB, just as if they were separate singleton outputs, but the number of output instances can differ between LFB instances of the same LFB class. The class definition may include a lower and/or an upper limit on the number of outputs. In addition, for configurable FEs, the FE capability information may define further limits on the number of instances in specific output groups for certain LFBs. The actual number of output instances in a group is a component of the LFB instance, which is read-only for static topologies, and read-write for dynamic topologies. The output instances in a group are numbered sequentially, from 0 to N-1, and are addressable from within the LFB. To use Output Port groups, the LFB has to have a built-in mechanism to select one specific output instance for each packet. This mechanism is described in the textual definition of the class and is typically configurable via some attributes of the LFB.
另一方面，输出组用于模拟具有相同允许元数据集的类似数据包流需要拆分为多条路径的情况。在这种情况下，当定义LFB类时，此类路径的数量是未知的，因为它不是LFB类的固有属性。输出组由许多输出组成，称为组的输出实例，其中所有输出实例共享相同的帧（数据包）和元数据发射定义（见图3.c）。每个输出实例都可以连接到不同的下游LFB，就像它们是单独的单例输出一样，但是相同LFB类的LFB实例之间的输出实例数量可能不同。类定义可以包括输出数量的下限和/或上限。此外，对于可配置FEs，FE能力信息可定义特定LFB的特定输出组中实例数量的进一步限制。组中输出实例的实际数量是LFB实例的一个组件，对于静态拓扑，LFB实例是只读的，对于动态拓扑，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.
例如，考虑重定向器LFB，其唯一目的是基于与每个到达分组相关联的元数据之一将数据包引导到N个下行路径中的一个。这样的LFB用途相当广泛，可以在拓扑中的许多不同位置使用。例如，给定在FRAMETYPE元数据中记录数据包类型的LFB，或在COLOR元数据中记录数据包速率类的LFB，可以使用这些元数据进行分支。重定向器可用于根据帧类型元数据（N=2）将数据路径划分为IPv4和IPv6路径，或在使用颜色元数据（红色、黄色、绿色；N=3）进行计量后分岔为速率特定路径等。
Using an output group in the above LFB class provides the desired flexibility to adapt each instance of this class to the required operation. The metadata to be used as a selector for the output instance is a property of the LFB. For each packet, the value of the specified metadata may be used as a direct index to the output instance. Alternatively, the LFB may have a configurable selector table that maps a metadatum value to output instance.
在上述LFB类中使用输出组可以提供所需的灵活性，以使该类的每个实例适应所需的操作。用作输出实例选择器的元数据是LFB的一个属性。对于每个包，指定元数据的值可以用作输出实例的直接索引。或者，LFB可以具有可配置的选择器表，该选择器表将元基准值映射到输出实例。
Note that other LFBs may also use the output group concept to build in similar adaptive forking capability. For example, a classifier LFB with one input and N outputs can be defined easily by using the output group concept. Alternatively, a classifier LFB with one singleton output in combination with an explicit N-output re-director
注意，其他LFB也可以使用输出组概念来构建类似的自适应分叉能力。例如，通过使用输出组概念，可以容易地定义具有一个输入和N个输出的分类器LFB。或者，分类器LFB具有一个单例输出，并结合显式的N-输出再导向器
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有两种类型的输出，OUT（用于正常数据包输出）和EXCEPTIONOUT（用于触发某些异常的数据包）。正常输出有多个实例；因此，它是一个输出组。
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
o 定义LFB类时，下游方向的数量未知
o the frame type and set of metadata emitted on these outputs are sufficiently similar or, ideally, identical, such they can share the same output definition
o 在这些输出上发出的帧类型和元数据集非常相似，或者在理想情况下完全相同，因此它们可以共享相同的输出定义
An LFB input is a conceptual port on an LFB on which the LFB can receive information from other LFBs. The information is typically a pair of a packet and its associated metadata. Either the packet or the metadata may for some LFBs and some situations be empty. They cannot both be empty, as then there is no input.
LFB输入是LFB上的概念端口，LFB可在其上接收来自其他LFB的信息。信息通常是一对数据包及其相关元数据。对于某些LFB和某些情况，数据包或元数据可能为空。它们不能都为空，因为没有输入。
For LFB instances that receive packets from more than one other LFB instance (fan-in), there are three ways to model fan-in, all supported by the LFB model and can all be combined in the same LFB:
对于从多个其他LFB实例（扇入）接收数据包的LFB实例，有三种建模扇入的方法，它们都受LFB模型支持，并且都可以组合在同一LFB中：
o Implicit multiplexing via a single input
o 通过单个输入的隐式多路复用
o Explicit multiplexing via multiple singleton inputs
o 通过多个单态输入的显式多路复用
o Explicit multiplexing via a group of inputs (input group)
o 通过一组输入显式多路复用（输入组）
The simplest form of multiplexing uses a singleton input (Figure 4.a). Most LFBs will have only one singleton input. Multiplexing into a single input is possible because the model allows more than one LFB output to connect to the same LFB input. This property applies to any LFB input without any special provisions in the LFB class. Multiplexing into a single input is applicable when the packets from the upstream LFBs are similar in frametype and accompanying metadata, and require similar processing. Note that this model does not address how potential contention is handled when multiple packets arrive simultaneously. If contention handling needs to be explicitly modeled, one of the other two modeling solutions must be used.
最简单的多路复用形式使用单例输入（图4.a）。大多数LFB只有一个单例输入。多路复用到单个输入是可能的，因为该模型允许多个LFB输出连接到同一个LFB输入。此属性适用于LFB类中没有任何特殊规定的任何LFB输入。当来自上游lfb的数据包在帧类型和伴随的元数据方面类似，并且需要类似的处理时，多路复用到单个输入中是适用的。请注意，此模型没有解决当多个数据包同时到达时如何处理潜在的争用。如果争用处理需要显式建模，则必须使用其他两种建模解决方案之一。
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层帧，一个用于接收用于封装的第3层帧。这种LFB类型在其输入端需要不同的帧（L2与L3），每个帧都有不同的元数据集，因此会对到达这些输入端的帧应用不同的处理。该模型能够通过定义LFB类如何处理竞争数据包来显式解决数据包竞争问题。
+--------------+ +------------------------+
| LFB X +---+ | |
+--------------+ | | |
| | |
+--------------+ v | |
| LFB Y +---+-->|input Meter LFB |
+--------------+ ^ | |
| | |
+--------------+ | | |
| LFB Z |---+ | |
+--------------+ +------------------------+
+--------------+ +------------------------+
| LFB X +---+ | |
+--------------+ | | |
| | |
+--------------+ v | |
| LFB Y +---+-->|input Meter LFB |
+--------------+ ^ | |
| | |
+--------------+ | | |
| LFB Z |---+ | |
+--------------+ +------------------------+
(a) An LFB connects with multiple upstream LFBs via a single input.
(a) LFB通过单个输入与多个上游LFB连接。
+--------------+ +------------------------+
| LFB X +---+ | |
+--------------+ +-->|layer2 |
+--------------+ | |
| LFB Y +------>|layer3 LFB |
+--------------+ +------------------------+
+--------------+ +------------------------+
| LFB X +---+ | |
+--------------+ +-->|layer2 |
+--------------+ | |
| LFB Y +------>|layer3 LFB |
+--------------+ +------------------------+
(b) An LFB connects with multiple upstream LFBs via two separate singleton inputs.
(b) LFB通过两个单独的单态输入与多个上游LFB连接。
+--------------+ +------------------------+
| Queue LFB #1 +---+ | |
+--------------+ | | |
| | |
+--------------+ +-->|in:0 \ |
| Queue LFB #2 +------>|in:1 | input group |
+--------------+ |... | |
+-->|in:N-1 / |
... | | |
+--------------+ | | |
| Queue LFB #N |---+ | Scheduler LFB |
+--------------+ +------------------------+
+--------------+ +------------------------+
| Queue LFB #1 +---+ | |
+--------------+ | | |
| | |
+--------------+ +-->|in:0 \ |
| Queue LFB #2 +------>|in:1 | input group |
+--------------+ |... | |
+-->|in:N-1 / |
... | | |
+--------------+ | | |
| Queue LFB #N |---+ | Scheduler LFB |
+--------------+ +------------------------+
(c) A Scheduler LFB uses an input group to differentiate which queue LFB packets are coming from.
(c) 调度器LFB使用输入组来区分来自哪个队列LFB数据包。
Figure 4: Examples of LFBs with various input combinations.
图4：具有各种输入组合的LFB示例。
The third method to model fan-in uses the concept of an input group. The concept is similar to the output group introduced in the previous section and is depicted in Figure 4.c. An input group consists of a number of input instances, all sharing the properties (same frame and metadata expectations). The input instances are numbered from 0 to N-1. From the outside, these inputs appear as normal inputs, i.e., any compatible upstream LFB can connect its output to one of these inputs. When a packet is presented to the LFB at a particular input instance, the index of the input where the packet arrived is known to the LFB and this information may be used in the internal processing. For example, the input index can be used as a table selector, or as an explicit precedence selector to resolve contention. As with output groups, the number of input instances in an input group is not defined in the LFB class. However, the class definition may include restrictions on the range of possible values. In addition, if an FE supports configurable topologies, it may impose further limitations on the number of instances for particular port group(s) of a particular LFB class. Within these limitations, different instances of the same class may have a different number of input instances.
第三种建模扇入的方法使用输入组的概念。该概念类似于前一节中介绍的输出组，如图4.c所示。输入组由多个输入实例组成，所有实例共享属性（相同的框架和元数据期望）。输入实例从0到N-1进行编号。从外部看，这些输入显示为正常输入，即任何兼容的上游LFB都可以将其输出连接到其中一个输入。当分组在特定输入实例处呈现给LFB时，LFB知道分组到达的输入的索引，并且该信息可在内部处理中使用。例如，输入索引可以用作表选择器，也可以用作解决争用的显式优先级选择器。与输出组一样，LFB类中没有定义输入组中输入实例的数量。但是，类定义可能包括对可能值范围的限制。此外，如果FE支持可配置拓扑，它可能会对特定LFB类的特定端口组的实例数量施加进一步的限制。在这些限制范围内，同一类的不同实例可能具有不同数量的输入实例。
The number of actual input instances in the group is a component defined in the LFB class, which is read-only for static topologies, and is read-write for configurable topologies.
组中实际输入实例的数量是LFB类中定义的组件，对于静态拓扑为只读，对于可配置拓扑为读写。
As an example for the input group, consider the Scheduler LFB depicted in Figure 4.c. Such an LFB receives packets from a number of Queue LFBs via a number of input instances, and uses the input index information to control contention resolution and scheduling.
作为输入组的一个例子，考虑图4中所示的调度器LFB。这样的LFB经由多个输入实例从多个队列LFB接收分组，并使用输入索引信息来控制争用解决和调度。
In summary, the LFB class may define one input, multiple singleton inputs, one or more input groups, or a combination thereof. Any input allows for implicit multiplexing of similar packet streams via connecting multiple outputs to the same input. Explicit multiple singleton inputs are useful when either the contention handling must be handled explicitly or when the LFB class must receive and process a known number of distinct types of packet streams. An input group is suitable when contention handling must be modeled explicitly, but the number of inputs is not inherent from the class (and hence is not known when the class is defined), or when it is critical for LFB operation to know exactly on which input the packet was received.
总之，LFB类可以定义一个输入、多个单例输入、一个或多个输入组或其组合。任何输入都允许通过将多个输出连接到同一输入来隐式复用类似的分组流。当必须显式处理争用处理或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报头之前剥离它。对于行政长官来说，这类处理是否正在进行是不透明的。
Metadata is state that is passed from one LFB to another alongside a packet. The metadata passed with the packet assists subsequent LFBs to process that packet.
元数据是在数据包旁边从一个LFB传递到另一个LFB的状态。随数据包一起传递的元数据有助于后续LFB处理该数据包。
The ForCES model defines metadata as precise atomic definitions in the form of label, value pairs.
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).
每个元数据被建模为一对<标签，值>对，其中标签标识信息类型（例如，“颜色”），其值保存实际信息（例如，“红色”）。此处的标签显示为文本标签，但对于协议处理，它与唯一的数值（标识符）关联。
To ensure inter-operability between LFBs, the LFB class specification must define what metadata the LFB class "reads" or "consumes" on its input(s) and what metadata it "produces" on its output(s). For maximum extensibility, this definition should specify neither which LFBs the metadata is expected to come from for a consumer LFB nor which LFBs are expected to consume metadata for a given producer LFB.
为确保LFB之间的互操作性，LFB类规范必须定义LFB类在其输入上“读取”或“使用”的元数据以及在其输出上“生成”的元数据。为了获得最大的可扩展性，此定义既不应指定使用者LFB的元数据预期来自哪个LFB，也不应指定给定生产者LFB的元数据预期来自哪个LFB。
For a given metadatum on a given packet path, there MUST be at least one producer LFB that creates that metadatum and SHOULD be at least one consumer LFB that needs that metadatum.
对于给定数据包路径上的给定元数据，必须至少有一个生产者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.
在力模型中，元数据的生产者和消费者LFB不需要相邻。此外，同一元数据可能有多个生产者和消费者。当数据包路径涉及同一元数据的多个生产者时，随后的生产者将覆盖该元数据值。
The metadata that is produced by an LFB is specified by the LFB class definition on a per-output-port-group basis. A producer may always generate the metadata on the port group, or may generate it only under certain conditions. We call the former "unconditional" metadata, whereas the latter is "conditional" metadata. For example, deep packet inspection LFB might produce several pieces of metadata about the packet. The first metadatum might be the IP protocol (TCP, UDP, SCTP, ...) being carried, and two additional metadata items might be the source and destination port number. These additional metadata items are conditional on the value of the first metadatum (IP carried protocol) as they are only produced for protocols that
LFB生成的元数据由LFB类定义在每个输出端口组的基础上指定。生产者可以始终在端口组上生成元数据，也可以仅在特定条件下生成元数据。我们称前者为“无条件”元数据，而后者为“有条件”元数据。例如，深度数据包检查LFB可能会生成关于数据包的若干元数据。第一个元数据可能是正在承载的IP协议（TCP、UDP、SCTP等），另外两个元数据项可能是源端口号和目标端口号。这些附加元数据项取决于第一个元数据（IP承载协议）的值，因为它们仅为以下协议生成：
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操作所需的元数据，在LFB类定义中以每个输入端口组为基础进行定义。输入端口组可能“需要”给定的元数据，或将其视为“可选”信息。在后一种情况下，LFB类定义必须明确定义如果没有提供任何可选元数据会发生什么。一种方法是为每个可选元数据指定默认值，并假设默认值用于未随数据包提供的任何元数据。
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被视为黑盒，则对每个激活的元数据执行以下操作之一。
* IGNORE: ignores and forwards the metadatum
* 忽略：忽略并转发图元基准
* READ: reads and forwards the metadatum
* 读取：读取并转发图元数据
* READ/RE-WRITE: reads, over-writes, and forwards the metadatum
* 读/重写：读取、重写和转发元数据
* WRITE: writes and forwards the metadatum (can also be used to create new metadata)
* 写入：写入和转发元数据（也可用于创建新元数据）
* READ-AND-CONSUME: reads and consumes the metadatum
* 读取并使用：读取并使用元数据
* CONSUME: consumes metadatum without reading
* 消费：消费元数据而不读取
The last two operations terminate the life-cycle of the metadatum, meaning that the metadatum is not forwarded with the packet when the packet is sent to the next LFB.
最后两个操作终止了元数据的生命周期，这意味着当数据包被发送到下一个LFB时，元数据不会与数据包一起转发。
In the ForCES model, a new metadatum is generated by an LFB when the LFB applies a WRITE operation to a metadatum type that was not present when the packet was received by the LFB. Such implicit creation may be unintentional by the LFB; that is, the LFB may apply the WRITE operation without knowing or caring whether or not the given metadatum existed. If it existed, the metadatum gets over-written; if it did not exist, the metadatum is created.
在ForCES模型中，当LFB将写操作应用到LFB接收数据包时不存在的元数据类型时，LFB将生成新的元数据。这种隐式创建可能是LFB无意的；也就是说，LFB可以在不知道或不关心给定的元数据是否存在的情况下应用写操作。如果存在，元数据将被重写；如果该图元不存在，则会创建该图元基准。
For LFBs that insert packets into the model, WRITE is the only meaningful metadata operation.
对于向模型中插入数据包的LFB，写入是唯一有意义的元数据操作。
For LFBs that remove the packet from the model, they may either READ-AND-CONSUME (read) or CONSUME (ignore) each active metadatum associated with the packet.
对于从模型中删除数据包的LFB，它们可以读取并使用（读取）或使用（忽略）与数据包关联的每个活动元数据。
During operation, various conditions may occur that can be detected by LFBs. Examples range from link failure or restart to timer expiration in special purpose LFBs. The CE may wish to be notified of the occurrence of such events. The description of how such messages are sent, and their format, is part of the Forwarding and Control Element Separation (ForCES) protocol [RFC5810] document. Indicating how such conditions are understood is part of the job of this model.
在操作过程中，LFB可能会检测到各种情况。示例包括特殊用途LFB中的链路故障或重启到计时器过期。行政长官或愿获通知该等事件的发生。发送此类消息的方式及其格式的说明是转发和控制元件分离（ForCES）协议[RFC5810]文档的一部分。说明如何理解这些条件是该模型工作的一部分。
Events are declared in the LFB class definition. The LFB event declaration constitutes:
事件在LFB类定义中声明。LFB事件声明包括：
o a unique 32-bit identifier.
o 唯一的32位标识符。
o An LFB component that is used to trigger the event. This entity is known as the event target.
o 用于触发事件的LFB组件。此实体称为事件目标。
o A condition that will happen to the event target that will result in a generation of an event to the CE. Examples of a condition include something getting created or deleted, a config change, etc.
o 将发生在事件目标上的一种情况，将导致向CE生成事件。条件的示例包括创建或删除的内容、配置更改等。
o What should be reported to the CE by the FE if the declared condition is met.
o 如果满足声明的条件，FE应向CE报告什么。
The declaration of an event within an LFB class essentially defines what part of the LFB component(s) need to be monitored for events, what condition on the LFB monitored LFB component an FE should detect to trigger such an event, and what to report to the CE when the event is triggered.
LFB类中的事件声明基本上定义了LFB组件的哪些部分需要针对事件进行监控，FE应检测LFB监控LFB组件上的哪些条件以触发此类事件，以及触发事件时向CE报告的内容。
While events may be declared by the LFB class definition, runtime activity is controlled using built-in event properties using LFB component properties (discussed in Section 3.2.6). A CE subscribes to the events on an LFB class instance by setting an event property for subscription. Each event has a subscription property that is by default off. A CE wishing to receive a specific event needs to turn on the subscription property at runtime.
虽然事件可以由LFB类定义声明，但运行时活动使用内置事件属性和LFB组件属性进行控制（在第3.2.6节中讨论）。CE通过设置订阅的事件属性订阅LFB类实例上的事件。每个事件都有一个默认关闭的订阅属性。希望接收特定事件的CE需要在运行时打开subscription属性。
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强烈期望对事件作出反应所需的公共、密切相关的信息。它不打算承载行政长官已经拥有的信息、大量信息或以复杂方式相关的信息。
From a conceptual point of view, at runtime, event processing is split into:
从概念上看，在运行时，事件处理分为：
1. Detection of something happening to the (declared during LFB class definition) event target. Processing the next step happens if the CE subscribed (at runtime) to the event.
1. 检测（在LFB类定义期间声明的）事件目标发生的事件。如果CE（在运行时）订阅了事件，则处理下一步。
2. Checking of the (declared during LFB class definition) condition on the LFB event target. If the condition is met, proceed with the next step.
2. 检查LFB事件目标上的（在LFB类定义期间声明的）条件。如果满足条件，则继续执行下一步。
3. Checking (runtime set) event filters if they exist to see if the event should be reported or suppressed. If the event is to be reported, proceed to the next step.
3. 检查（运行时设置）事件筛选器是否存在，以查看是否应报告或抑制该事件。如果要报告事件，请转至下一步。
4. Submitting of the declared report to the CE.
4. 向行政长官提交申报报告。
Section 4.7.6 discusses events in more details.
第4.7.6节更详细地讨论了事件。
LFBs and structures are made up of components, containing the information that the CE needs to see and/or change about the functioning of the LFB. These components, as described in detail in Section 4.7, may be basic values, complex structures (containing multiple components themselves, each of which can be values, structures, or tables), or tables (which contain values, structures, or tables). Components may be defined such that their appearance in LFB instances is optional. Components may be readable or writable at the discretion of the FE implementation. The CE needs to know these properties. Additionally, certain kinds of components (arrays / tables, aliases, and events) have additional property information that the CE may need to read or write. This model defines the structure of the property information for all defined data types.
LFB和结构由组件组成，包含CE需要查看和/或更改的有关LFB功能的信息。如第4.7节所述，这些组件可以是基本值、复杂结构（包含多个组件本身，每个组件可以是值、结构或表格）或表格（包含值、结构或表格）。可以定义组件，使其在LFB实例中的外观是可选的。FE实现可自行决定组件是否可读写。CE需要了解这些属性。此外，某些类型的组件（数组/表、别名和事件）具有CE可能需要读取或写入的附加属性信息。该模型为所有定义的数据类型定义属性信息的结构。
Section 4.8 describes properties in more details.
第4.8节更详细地描述了属性。
LFB class versioning is a method to enable incremental evolution of LFB classes. In general, an FE is not allowed to contain an LFB instance for more than one version of a particular class. Inheritance (discussed next in Section 3.2.8) has special rules. If an FE data path model containing an LFB instance of a particular class C also simultaneously contains an LFB instance of a class C' inherited from class C; C could have a different version than C'.
LFB类版本控制是一种支持LFB类增量演化的方法。通常，FE不允许包含特定类的多个版本的LFB实例。继承（将在第3.2.8节中讨论）有特殊规则。如果包含特定类别C的LFB实例的FE数据路径模型也同时包含从类别C继承的类别C'的LFB实例；C的版本可能与C不同。
LFB class versioning is supported by requiring a version string in the class definition. CEs may support multiple versions of a particular LFB class to provide backward compatibility, but FEs MUST NOT support more than one version of a particular class.
通过在类定义中要求版本字符串来支持LFB类版本控制。CEs可以支持特定LFB类的多个版本以提供向后兼容性，但FEs不能支持特定类的多个版本。
Versioning is not restricted to making backward-compatible changes. It is specifically expected to be used to make changes that cannot be represented by inheritance. Often this will be to correct errors, and hence may not be backward compatible. It may also be used to remove components that are not considered useful (particularly if they were previously mandatory, and hence were an implementation impediment).
版本控制不限于进行向后兼容的更改。特别期望它用于进行不能由继承表示的更改。这通常是为了纠正错误，因此可能不向后兼容。它还可用于删除不被认为有用的组件（特别是如果它们以前是强制性的，因此是实现障碍的话）。
LFB class inheritance is supported in the FE model as a method to define new LFB classes. This also allows FE vendors to add vendor-specific extensions to standardized LFBs. An LFB class specification MUST specify the base class and version number it inherits from (the default is the base LFB class). Multiple inheritance is not allowed, however, to avoid unnecessary complexity.
FE模型支持LFB类继承作为定义新LFB类的方法。这还允许FE供应商向标准化LFB添加特定于供应商的扩展。LFB类规范必须指定基类及其继承的版本号（默认为基类LFB）。但是，为了避免不必要的复杂性，不允许多重继承。
Inheritance should be used only when there is significant reuse of the base LFB class definition. A separate LFB class should be defined if little or no reuse is possible between the derived and the base LFB class.
只有在大量重用基本LFB类定义时，才应使用继承。如果派生LFB类和基LFB类之间很少或根本不可能重用，则应定义单独的LFB类。
An interesting issue related to class inheritance is backward compatibility between a descendant and an ancestor class. Consider the following hypothetical scenario where a standardized LFB class "L1" exists. Vendor A builds an FE that implements LFB "L1", and vendor B builds a CE that can recognize and operate on LFB "L1". Suppose that a new LFB class, "L2", is defined based on the existing "L1" class by extending its capabilities incrementally. Let us examine the FE backward-compatibility issue by considering what would happen if vendor B upgrades its FE from "L1" to "L2" and vendor C's
与类继承相关的一个有趣问题是后代类和祖先类之间的向后兼容性。考虑下面假设的场景，其中存在标准化的LFB类“L1”。供应商A构建了一个实现LFB“L1”的FE，供应商B构建了一个能够识别LFB“L1”并对其进行操作的CE。假设一个新的LFB类“L2”是基于现有的“L1”类通过增量扩展其功能来定义的。让我们通过考虑如果供应商B将其FE从“L1”升级到“L2”以及供应商C将发生什么情况来检查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".
行政长官没有改变。如果派生的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.
相反的情况是问题小得多的情况，即CE供应商B升级到新的LFB类“L2”，但FE未升级。注意，只要CE能够处理较旧的LFB类，这个问题就不会影响模型；因此，我们将使用术语“向后兼容性”来指代第一种与FE向后兼容性相关的场景。
Backward compatibility can be designed into the inheritance model by constraining LFB inheritance to require that the derived class be a functional superset of the base class (i.e., the derived class can only add functions to the base class, but not remove functions). Additionally, the following mechanisms are required to support FE backward compatibility:
通过约束LFB继承以要求派生类是基类的函数超集（即，派生类只能向基类添加函数，而不能删除函数），可以将向后兼容性设计到继承模型中。此外，需要以下机制来支持FE向后兼容性：
1. When detecting an LFB instance of an LFB type that is unknown to the CE, the CE MUST be able to query the base class of such an LFB from the FE.
1. 当检测到CE未知的LFB类型的LFB实例时，CE必须能够从FE查询此类LFB的基类。
2. The LFB instance on the FE SHOULD support a backward-compatibility mode (meaning the LFB instance reverts itself back to the base class instance), and the CE SHOULD be able to configure the LFB to run in such a mode.
2. FE上的LFB实例应该支持向后兼容模式（这意味着LFB实例将自身恢复为基类实例），CE应该能够配置LFB以这种模式运行。
Figure 5 demonstrates the abstraction of the different ForCES model entities. The ForCES protocol provides the mechanism to uniquely identify any of the LFB class instance components.
图5展示了不同部队模型实体的抽象。ForCES协议提供了唯一标识任何LFB类实例组件的机制。
FE Address = FE01
+--------------------------------------------------------------+
| |
| +--------------+ +--------------+ |
| | LFB ClassID 1| |LFB ClassID 91| |
| | InstanceID 3 |============>|InstanceID 3 |======>... |
| | +----------+ | | +----------+ | |
| | |Components| | | |Components| | |
| | +----------+ | | +----------+ | |
| +--------------+ +--------------+ |
| |
+--------------------------------------------------------------+
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的两个LFB类。上面的示例进一步说明了两个类中每个类的一个实例。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 | |
| | +-----------------+ | |
| | | | | |
| | +-----------------+ | |
| +----------------------+ |
| |
| |
+-------------------------------------+
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实例ID 3携带的组件。
The example shows three components with 32-bit component identifiers 1, 31, and 51. LFB ComponentID 51 is a complex structure encapsulating within it an entity with LFB ComponentID 89. LFB ComponentID 89 could be a complex structure itself, but is restricted in the example for the sake of clarity.
该示例显示了具有32位组件标识符1、31和51的三个组件。LFB ComponentD 51是一个复杂的结构，其中封装了一个具有LFB ComponentD 89的实体。LFB ComponentD 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 model XML schema（第4节）允许唯一标识具有这种复杂性的任何内容，利用点注释静态路径的概念和从键派生的路径的内容寻址。例如，如果LFB ComponentD 51是一个结构，那么上面LFB ComponentD 89的路径将是51.89。
LFB ComponentID 51 might represent a table (an array). In that case, to select the LFB component with ID 89 from within the 7th entry of the table, one would use the path 51.7.89. In addition to supporting explicit table element selection by including an index in the dotted path, the model supports identifying table elements by their contents. This is referred to as using keys, or key indexing. So, as a further example, if ComponentID 51 was a table that was key index-able, then a key describing content could also be passed by the CE, along with path 51 to select the table, and followed by the path 89 to select the table structure element, which upon computation by the FE would resolve to the LFB ComponentID 89 within the specified table entry.
LFB组件51可能表示一个表（一个数组）。在这种情况下，要从表的第7个条目中选择ID为89的LFB组件，可以使用路径51.7.89。除了通过在虚线路径中包含索引来支持显式的表元素选择之外，该模型还支持通过表元素的内容来识别表元素。这称为使用键或键索引。因此，作为进一步的示例，如果ComponentD 51是一个可索引键的表，那么描述内容的键也可以由CE传递，路径51用于选择表，路径89用于选择表结构元素，FE计算后将解析为指定表项内的LFB组件89。
Packets coming into the FE from ingress ports generally flow through one or more LFBs before leaving out of the egress ports. How an FE treats a packet depends on many factors, such as type of the packet (e.g., IPv4, IPv6, or MPLS), header values, time of arrival, etc. The result of LFB processing may have an impact on how the packet is to be treated in downstream LFBs. This differentiation of packet treatment downstream can be conceptualized as having alternative data paths in the FE. For example, the result of a 6-tuple classification performed by a classifier LFB could control which rate meter is applied to the packet by a rate meter LFB in a later stage in the data path.
从入口端口进入FE的分组通常在离开出口端口之前流过一个或多个LFB。FE如何处理数据包取决于许多因素，例如数据包的类型（例如IPv4、IPv6或MPLS）、报头值、到达时间等。LFB处理的结果可能会影响下游LFB中如何处理数据包。这种分组处理下游的区别可以被概念化为在FE中具有替代数据路径。例如，由分类器LFB执行的6元组分类的结果可以控制在数据路径的稍后阶段由速率计LFB将哪个速率计应用于分组。
LFB topology is a directed graph representation of the logical data paths within an FE, with the nodes representing the LFB instances and the directed link depicting the packet flow direction from one LFB to
LFB拓扑是FE内逻辑数据路径的有向图表示，节点表示LFB实例，有向链路表示从一个LFB到另一个LFB的分组流方向
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.
下一个。第3.4.1节讨论如何将FE数据路径建模为LFB拓扑，而第3.4.2节重点讨论与LFB拓扑重构相关的问题。
There are two basic ways to express the differentiation in packet treatment within an FE; one represents the data path directly and graphically (topological approach) and the other utilizes metadata (the encoded state approach).
有两种基本的方式来表达FE内数据包处理的差异；一种是直接以图形方式表示数据路径（拓扑方法），另一种是利用元数据（编码状态方法）。
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将具有单独的输出端口，每个可选处理一个，连接到单独的子图，每个子图表示各自的下游处理。
o Encoded State Approach
o 编码状态方法
An alternate way of expressing differential treatment is by using metadata. The result of the operation of an LFB can be encoded in a metadatum, which is passed along with the packet to downstream LFBs. A downstream LFB, in turn, can use the metadata and its value (e.g., as an index into some table) to determine how to treat the packet.
表示差别待遇的另一种方法是使用元数据。LFB操作的结果可以编码在元数据中，该元数据与数据包一起传递给下游LFB。下游LFB反过来可以使用元数据及其值（例如，作为某个表的索引）来确定如何处理数据包。
Theoretically, either approach could substitute for the other, so one could consider using a single pure approach to describe all data paths in an FE. However, neither model by itself results in the best representation for all practically relevant cases. For a given FE with certain logical data paths, applying the two different modeling approaches will result in very different looking LFB topology graphs. A model using only the topological approach may require a very large graph with many links or paths, and nodes (i.e., LFB instances) to express all alternative data paths. On the other hand, a model using only the encoded state model would be restricted to a string of LFBs, which is not an intuitive way to describe different data paths (such as MPLS and IPv4). Therefore, a mix of these two approaches will likely be used for a practical model. In fact, as we illustrate below, the two approaches can be mixed even within the same LFB.
理论上，任何一种方法都可以替代另一种方法，因此可以考虑使用单一纯方法来描述FE中的所有数据路径。然而，这两个模型本身都不能最好地表示所有实际相关的情况。对于具有特定逻辑数据路径的给定FE，应用两种不同的建模方法将产生外观非常不同的LFB拓扑图。仅使用拓扑方法的模型可能需要一个包含许多链接或路径的非常大的图，以及表示所有可选数据路径的节点（即LFB实例）。另一方面，仅使用编码状态模型的模型将被限制为LFB字符串，这不是描述不同数据路径（如MPLS和IPv4）的直观方式。因此，这两种方法的组合很可能用于实际模型。事实上，正如我们下面所说明的，即使在同一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
图7.a显示了使用纯拓扑方法时，LFB拓扑是什么样子的。使用一个简单的分类器示例，该分类器有N个分类输出，后面跟着其他LFB。分类器的每个输出都会传递到不需要元数据的N个LFB中的一个。拓扑方法简单、直观、图形化
intuitive. However, if N is large and the N nodes following the classifier (LFB#1, LFB#2, ..., LFB#N) all belong to the same LFB type (e.g., meter), but each has its own independent components, the encoded state approach gives a much simpler topology representation, as shown in Figure 7.b. The encoded state approach requires that a table of N rows of meter components be provided in the Meter node itself, with each row representing the attributes for one meter instance. A metadatum M is also needed to pass along with the packet P from the classifier to the meter, so that the meter can use M as a look-up key (index) to find the corresponding row of the attributes that should be used for any particular packet P.
直觉的然而，如果N较大，且分类器（LFB#1、LFB#2、…、LFB#N）后面的N个节点都属于相同的LFB类型（例如，米），但每个节点都有自己的独立组件，则编码状态方法给出了一个更简单的拓扑表示，如图7.b所示。编码状态方法要求在仪表节点本身中提供一个包含N行仪表组件的表，每行表示一个仪表实例的属性。还需要元数据M与包P一起从分类器传递到计量器，以便计量器可以使用M作为查找键（索引），以查找应用于任何特定包P的属性的对应行。
What if those N nodes (LFB#1, LFB#2, ..., LFB#N) are not of the same type? For example, if LFB#1 is a queue while the rest are all meters, what is the best way to represent such data paths? While it is still possible to use either the pure topological approach or the pure encoded state approach, the natural combination of the two appears to be the best option. Figure 7.c depicts two different functional data paths using the topological approach while leaving the N-1 meter instances distinguished by metadata only, as shown in Figure 7.c.
如果这N个节点（LFB#1、LFB#2、…、LFB#N）不是同一类型的节点，该怎么办？例如，如果LFB#1是一个队列，而其余的都是米，那么表示此类数据路径的最佳方式是什么？虽然仍然可以使用纯拓扑方法或纯编码状态方法，但两者的自然组合似乎是最佳选择。图7.c描述了使用拓扑方法的两个不同的功能数据路径，同时仅通过元数据区分N-1米实例，如图7.c所示。
+----------+
P | LFB#1 |
+--------->|(Compon-1)|
+-------------+ | +----------+
| 1|------+ P +----------+
| 2|---------------->| LFB#2 |
| classifier 3| |(Compon-2)|
| ...|... +----------+
| N|------+ ...
+-------------+ | P +----------+
+--------->| LFB#N |
|(Compon-N)|
+----------+
+----------+
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) |
+-------------+ +-------------+
+-------------+ +-------------+
| 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) |
+-------------+
+-------------+
+-------------+ (P, M) | queue |
| 1|------------->| (Compon-1) |
| 2| +-------------+
| 3| (P, M) +-------------+
| ...|------------->| Meter |
| N| | (Compon-2) |
+-------------+ | ... |
| (Compon-N) |
+-------------+
(c) Using a combination of the two, if LFB#1, LFB#2, ..., and LFB#N are of different types (e.g., queue and meter).
(c) 如果LFB#1、LFB#2、…、和LFB#N属于不同的类型（例如，队列和计量器），则使用两者的组合。
Figure 7: An example of how to model FE data paths.
图7：如何对FE数据路径建模的示例。
From this example, we demonstrate that each approach has a distinct advantage depending on the situation. Using the encoded state approach, fewer connections are typically needed between a fan-out node and its next LFB instances of the same type because each packet carries metadata the following nodes can interpret and hence invoke a different packet treatment. For those cases, a pure topological approach forces one to build elaborate graphs with many more connections and often results in an unwieldy graph. On the other hand, a topological approach is the most intuitive for representing functionally different data paths.
从这个例子中，我们证明了每种方法都有明显的优势，这取决于具体情况。使用编码状态方法，扇出节点与其相同类型的下一个LFB实例之间通常需要较少的连接，因为每个数据包都携带元数据，以下节点可以解释并因此调用不同的数据包处理。对于这些情况，纯拓扑方法迫使人们构建具有更多连接的复杂图，并且常常导致难以处理的图。另一方面，拓扑方法是表示功能不同的数据路径最直观的方法。
For complex topologies, a combination of the two is the most flexible. A general design guideline is provided to indicate which approach is best used for a particular situation. The topological approach should primarily be used when the packet data path forks to distinct LFB classes (not just distinct parameterizations of the same LFB class), and when the fan-outs do not require changes, such as adding/removing LFB outputs, or require only very infrequent changes.
对于复杂拓扑，两者的组合是最灵活的。提供了一般设计指南，以说明哪种方法最适合于特定情况。当包数据路径分叉到不同的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).
需要频繁更改的配置信息应该通过使用一个或多个LFB的内部属性来表示（因此使用编码状态方法）。
+---------------------------------------------+
| |
+----------+ V +----------+ +------+ |
| | | | |if IP-in-IP| | |
---->| ingress |->+----->|classifier|---------->|Decap.|---->---+
| ports | | |---+ | |
+----------+ +----------+ |others +------+
|
V
(a) The LFB topology with a logical loop
+---------------------------------------------+
| |
+----------+ 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.
+-------+ +-----------+ +------+ +-----------+
| | | |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示例。在此示例中，来自IPsec应用程序（如VPN）的IP-In-IP分组可以首先到达分类器，并基于外部IP报头进行分类。在被分类为IP-in-IP分组后，该分组随后被发送到去封装器以剥离外部IP报头，随后再次由分类器对内部IP报头执行分类。如果相同的分类器硬件或软件使用相同的过滤规则集用于外部和内部IP报头分类，则LFB拓扑中自然会出现逻辑循环，如图8.a所示。然而，如果分类是由两个不同的硬件或软件使用不同的过滤器（即，一组过滤器用于外部IP报头，另一组用于内部IP报头）实现的，则更自然地将它们建模为分类器LFB的两个不同实例，如图8.b所示。
While there is little doubt that an individual LFB must be configurable, the configurability question is more complicated for LFB topology. Since the LFB topology is really the graphic representation of the data paths within an FE, configuring the LFB topology means dynamically changing the data paths, including changing the LFBs along the data paths on an FE (e.g., creating/ instantiating, updating, or deleting LFBs) and setting up or deleting interconnections between outputs of upstream LFBs to inputs of downstream LFBs.
尽管毫无疑问，单个LFB必须是可配置的，但LFB拓扑的可配置性问题更为复杂。由于LFB拓扑实际上是FE内数据路径的图形表示，因此配置LFB拓扑意味着动态更改数据路径，包括沿FE上的数据路径更改LFB（例如，创建/实例化、更新或删除LFB）以及设置或删除上游lfb的输出与下游lfb的输入之间的互连。
Why would the data paths on an FE ever change dynamically? The data paths on an FE are set up by the CE to provide certain data plane services (e.g., Diffserv, VPN) to the network element's (NE) customers. The purpose of reconfiguring the data paths is to enable the CE to customize the services the NE is delivering at run time. The CE needs to change the data paths when the service requirements change, such as adding a new customer or when an existing customer changes their service. However, note that not all data path changes result in changes in the LFB topology graph. Changes in the graph are dependent on the approach used to map the data paths into LFB topology. As discussed in Section 3.4.1, the topological approach and encoded state approach can result in very different looking LFB topologies for the same data paths. In general, an LFB topology based on a pure topological approach is likely to experience more frequent topology reconfiguration than one based on an encoded state approach. However, even an LFB topology based entirely on an encoded state approach may have to change the topology at times, for example, to bypass some LFBs or insert new LFBs. Since a mix of these two approaches is used to model the data paths, LFB topology reconfiguration is considered an important aspect of the FE model.
为什么FE上的数据路径会动态变化？FE上的数据路径由CE设置，以向网元（NE）客户提供某些数据平面服务（例如，Diffserv、VPN）。重新配置数据路径的目的是使CE能够定制网元在运行时提供的服务。当服务需求发生变化时，如添加新客户或现有客户改变其服务时，CE需要更改数据路径。但是，请注意，并非所有数据路径更改都会导致LFB拓扑图中的更改。图中的更改取决于用于将数据路径映射到LFB拓扑的方法。如第3.4.1节所述，拓扑方法和编码状态方法可能导致相同数据路径的LFB拓扑外观非常不同。通常，基于纯拓扑方法的LFB拓扑可能比基于编码状态方法的LFB拓扑经历更频繁的拓扑重构。然而，即使完全基于编码状态方法的LFB拓扑有时也必须改变拓扑，例如，绕过一些LFB或插入新的LFB。由于混合使用这两种方法来建模数据路径，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
我们想指出的是，在FE模型中允许可配置LFB拓扑并不要求所有FEs都必须具备此功能。即使FE支持可配置LFB拓扑，FE也可能对实际可配置的内容施加限制。性能优化的硬件实现可能具有零或非常有限的可配置性，而在网络处理器上运行的FE实现可能提供更大的灵活性和可配置性。FE设计者完全可以决定FE是否真正实现了重新配置，如果是的话，需要多少。无论是使用简单的运行时开关来启用或禁用（即旁路）某些LFB，还是使用更灵活的软件重新配置，都是FE内部和FE模型范围之外的实现细节。无论哪种情况，CE都必须能够了解FE的配置能力。因此，必须建立有限元模型
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拓扑配置功能的机制。这些功能可能包括（有关详细信息，请参见第5节）：
o Which LFB classes the FE can instantiate
o FE可以实例化哪些LFB类
o The maximum number of instances of the same LFB class that can be created
o 可以创建的同一LFB类的最大实例数
o Any topological limitations, for example:
o 任何拓扑限制，例如：
* The maximum number of instances of the same class or any class that can be created on any given branch of the graph
* 可以在图的任何给定分支上创建的同一类或任何类的最大实例数
* Ordering restrictions on LFBs (e.g., any instance of LFB class A must be always downstream of any instance of LFB class B)
* LFB的订购限制（例如，LFB类别A的任何实例必须始终位于LFB类别B的任何实例的下游）
The CE needs some programming help in order to cope with the range of complexity. In other words, even when the CE is allowed to configure LFB topology for the FE, the CE is not expected to be able to interpret an arbitrary LFB topology and determine which specific service or application (e.g., VPN, Diffserv) is supported by the FE. However, once the CE understands the coarse capability of an FE, the CE MUST configure the LFB topology to implement the network service the NE is supposed to provide. Thus, the mapping the CE has to understand is from the high-level NE service to a specific LFB topology, not the other way around. The CE is not expected to have the ultimate intelligence to translate any high-level service policy into the configuration data for the FEs. However, it is conceivable that within a given network service domain, a certain amount of intelligence can be programmed into the CE to give the CE a general understanding of the LFBs involved to allow the translation from a high-level service policy to the low-level FE configuration to be done automatically. Note that this is considered an implementation issue internal to the control plane and outside the scope of the FE model. Therefore, it is not discussed any further in this document.
CE需要一些编程帮助来处理复杂的范围。换句话说，即使当允许CE为FE配置LFB拓扑时，CE也不期望能够解释任意LFB拓扑并确定FE支持哪个特定服务或应用（例如VPN、Diffserv）。然而，一旦CE了解FE的粗略能力，CE必须配置LFB拓扑以实现网元应该提供的网络服务。因此，CE必须理解的映射是从高级NE服务到特定LFB拓扑，而不是相反。预计CE不会拥有将任何高级服务策略转换为FEs配置数据的最终智能。然而，可以想象的是，在给定的网络服务域内，可以将一定量的智能编程到CE中，以使CE对所涉及的lfb有一个大致的了解，从而允许自动完成从高级服务策略到低级FE配置的转换。请注意，这被视为控制平面内部和FE模型范围之外的实施问题。因此，本文件不再进一步讨论。
+----------+ +-----------+
---->| Ingress |---->|classifier |--------------+
| | |chip | |
+----------+ +-----------+ |
v
+-------------------------------------------+
+--------+ | Network Processor |
<----| Egress | | +------+ +------+ +-------+ |
+--------+ | |Meter | |Marker| |Dropper| |
^ | +------+ +------+ +-------+ |
| | |
+----------+-------+ |
| | |
| +---------+ +---------+ +------+ +---------+ |
| |Forwarder|<------|Scheduler|<--|Queue | |Counter | |
| +---------+ +---------+ +------+ +---------+ |
+--------------------------------------------------------------+
+----------+ +-----------+
---->| Ingress |---->|classifier |--------------+
| | |chip | |
+----------+ +-----------+ |
v
+-------------------------------------------+
+--------+ | Network Processor |
<----| Egress | | +------+ +------+ +-------+ |
+--------+ | |Meter | |Marker| |Dropper| |
^ | +------+ +------+ +-------+ |
| | |
+----------+-------+ |
| | |
| +---------+ +---------+ +------+ +---------+ |
| |Forwarder|<------|Scheduler|<--|Queue | |Counter | |
| +---------+ +---------+ +------+ +---------+ |
+--------------------------------------------------------------+
Figure 9: The capability of an FE as reported to the CE.
图9：向CE报告的FE的能力。
Figure 9 shows an example where a QoS-enabled (quality-of-service) router has several line cards that have a few ingress ports and egress ports, a specialized classification chip, and a network processor containing codes for FE blocks like meter, marker, dropper, counter, queue, scheduler, and IPv4 forwarder. Some of the LFB topology is already fixed and has to remain static due to the physical layout of the line cards. For example, all of the ingress ports might be hardwired into the classification chip so all packets flow from the ingress port into the classification engine. On the other hand, the LFBs on the network processor and their execution order are programmable. However, certain capacity limits and linkage constraints could exist between these LFBs. Examples of the capacity limits might be:
图9显示了一个示例，其中启用QoS（服务质量）的路由器具有多个线路卡，这些线路卡具有几个入口端口和出口端口、一个专用分类芯片和一个网络处理器，其中包含FE块的代码，如仪表、标记器、滴管、计数器、队列、调度器和IPv4转发器。由于线路卡的物理布局，一些LFB拓扑已经固定，必须保持静态。例如，所有入口端口可以硬连线到分类芯片中，以便所有分组从入口端口流入分类引擎。另一方面，网络处理器上的LFB及其执行顺序是可编程的。然而，这些LFB之间可能存在某些容量限制和连接限制。容量限制的示例可能是：
o 8 meters
o 8米
o 16 queues in one FE
o 一个FE中有16个队列
o the scheduler can handle at most up to 16 queues
o 调度程序最多可以处理16个队列
o The linkage constraints might dictate that:
o 链接约束可能规定：
* the classification engine may be followed by:
* 分级引擎后面可能有：
+ a meter
+ 米
+ marker
+ 标记
+ dropper
+ 滴管
+ counter
+ 柜台
+ queue or IPv4 forwarder, but not a scheduler
+ 队列或IPv4转发器，但不是计划程序
* queues can only be followed by a scheduler
* 队列后面只能有计划程序
* a scheduler must be followed by the IPv4 forwarder
* 计划程序后面必须跟IPv4转发器
* the last LFB in the data path before going into the egress ports must be the IPv4 forwarder
* 进入出口端口之前，数据路径中的最后一个LFB必须是IPv4转发器
+-----+ +-------+ +---+
| A|--->|Queue1 |--------------------->| |
------>| | +-------+ | | +---+
| | | | | |
| | +-------+ +-------+ | | | |
| B|--->|Meter1 |----->|Queue2 |------>| |->| |
| | | | +-------+ | | | |
| | | |--+ | | | |
+-----+ +-------+ | +-------+ | | +---+
classifier +-->|Dropper| | | IPv4
+-------+ +---+ Fwd.
Scheduler
+-----+ +-------+ +---+
| A|--->|Queue1 |--------------------->| |
------>| | +-------+ | | +---+
| | | | | |
| | +-------+ +-------+ | | | |
| B|--->|Meter1 |----->|Queue2 |------>| |->| |
| | | | +-------+ | | | |
| | | |--+ | | | |
+-----+ +-------+ | +-------+ | | +---+
classifier +-->|Dropper| | | IPv4
+-------+ +---+ Fwd.
Scheduler
Figure 10: An LFB topology as configured by the CE and accepted by the FE.
图10：由CE配置并由FE接受的LFB拓扑。
Once the FE reports these capabilities and capacity limits to the CE, it is now up to the CE to translate the QoS policy into a desirable configuration for the FE. Figure 9 depicts the FE capability, while Figure 10 and Figure 11 depict two different topologies that the CE may request the FE to configure. Note that Figure 11 is not fully drawn, as inter-LFB links are included to suggest potential complexity, without drawing in the endpoints of all such links.
一旦FE向CE报告这些能力和容量限制，现在就由CE将QoS策略转化为FE所需的配置。图9描述了FE能力，而图10和图11描述了CE可能要求FE配置的两种不同拓扑。请注意，图11未完全绘制，因为包含LFB间链路是为了表示潜在的复杂性，而没有绘制所有此类链路的端点。
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 +--+ |
+---------------------------->| |---+
| |
+--+
Queue1
+---+ +--+
| A|------------------->| |--+
+->| | | | |
| | B|--+ +--+ +--+ +--+ |
| +---+ | | | | | |
| Meter1 +->| |-->| | |
| | | | | |
| +--+ +--+ | IPv4
| Counter1 Dropper1 Queue2| +--+ Fwd.
+---+ | +--+ +--->|A | +-+
| A|---+ | |------>|B | | |
------>| B|------------------------------>| | +-->|C |->| |->
| C|---+ +--+ | +>|D | | |
| D|-+ | | | +--+ +-+
+---+ | | +---+ Queue3 | |Scheduler
Classifier1 | | | A|------------> +--+ | |
| +->| | | |-+ |
| | B|--+ +--+ +-------->| | |
| +---+ | | | | +--+ |
| Meter2 +->| |-+ |
| | | |
| +--+ Queue4 |
| Marker1 +--+ |
+---------------------------->| |---+
| |
+--+
Figure 11: Another LFB topology as configured by the CE and accepted by the FE.
图11:CE配置并被FE接受的另一个LFB拓扑。
Note that both the ingress and egress are omitted in Figure 10 and Figure 11 to simplify the representation. The topology in Figure 11 is considerably more complex than Figure 10, but both are feasible within the FE capabilities, and so the FE should accept either configuration request from the CE.
注意，为了简化表示，图10和图11中省略了入口和出口。图11中的拓扑结构比图10复杂得多，但两者在FE能力范围内都是可行的，因此FE应该接受来自CE的任一配置请求。
The main goal of the FE model is to provide an abstract, generic, modular, implementation-independent representation of the FEs. This is facilitated using the concept of LFBs, which are instantiated from LFB classes. LFB classes and associated definitions will be provided
FE模型的主要目标是提供FEs的抽象、通用、模块化、独立于实现的表示。使用LFB的概念可以简化这一过程，LFB是从LFB类实例化的。将提供LFB类和相关定义
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.
在XML文档集合中。这些XML文档的集合称为LFB类库，每个文档称为LFB类库文档（简称库文档）。每个库文档必须符合本节中介绍的模式。此处的模式和符合模式的规则是W3C在XML模式中的XML模式定义[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.
预计FEs和CEs之间不会“通过网络”交换图书馆文件。但该模型将为CEs（软件）和FEs（主要是软件部分）的设计和开发提供重要参考。当指定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 <description>提供图书馆文档用途的文本说明，
o <load> for loading information from other library documents,
o <load>用于从其他库文档加载信息，
o <frameDefs> for the frame declarations,
o <frameDefs>用于帧声明，
o <dataTypeDefs> for defining common data types,
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”指令。导入通过使用<load>元素来表示，该元素必须位于文档中上述所有元素之前。对于唯一引用，每个LFBLibrary实例文档都有一个在LFBLibrary元素的“提供”属性中定义的唯一标签。请注意，这执行的是强制包含，而不是XML包含。包含<load>元素引用的库的语义内容，而不是xml内容。此外，就<load>元素的概念处理而言，加载的文档的整个集合被视为形成单个文档进行处理。给定的文档仅包含在此集中一次，即使它被<load>元素多次引用，甚至来自多个不同的文件。由于LFBLibrary信息的处理不依赖于顺序，因此处理加载元素的顺序取决于实现者，只要总体效果是所有文件中的所有信息都可以在需要时引用。请注意，对ForCES模型库文档的这种计算机处理可能有助于各种实现，但不需要定义库或协议本身的实际操作。
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">
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
provides="this_library">
<description>
<description>
</description>
</description>
<!-- Loading external libraries (optional) --> <load library="another_library"/> ...
<!-- 正在加载外部库（可选）--><load library=“另一个库”/>。。。
<!-- FRAME TYPE DEFINITIONS (optional) -->
<frameDefs>
...
</frameDefs>
<!-- FRAME TYPE DEFINITIONS (optional) -->
<frameDefs>
...
</frameDefs>
<!-- DATA TYPE DEFINITIONS (optional) -->
<dataTypeDefs>
...
</dataTypeDefs>
<!-- DATA TYPE DEFINITIONS (optional) -->
<dataTypeDefs>
...
</dataTypeDefs>
<!-- METADATA DEFINITIONS (optional) -->
<metadataDefs>
...
</metadataDefs>
<!-- METADATA DEFINITIONS (optional) -->
<metadataDefs>
...
</metadataDefs>
<!--
-
-
LFB CLASS DEFINITIONS (optional) -->
<LFBCLassDefs>
<!--
-
-
LFB CLASS DEFINITIONS (optional) -->
<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:
load元素必须包含要包含的库文档的标签，并且可能包含一个URL，用于指定可以检索库的位置。荷载元素可以无限次重复。以下是<load>元素的三个示例：
<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"/>
<load library="a_library"/>
<load library="another_library" location="another_lib.xml"/>
<load library="yetanother_library"
location="http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/>
Frame names are used in the LFB definition to define the types of frames the LFB expects at its input port(s) and emits at its output port(s). The <frameDefs> optional element in the library document contains one or more <frameDef> elements, each declaring one frame type.
帧名称在LFB定义中用于定义LFB在其输入端口期望的帧类型和在其输出端口发射的帧类型。库文档中的<frameDefs>可选元素包含一个或多个<frameDef>元素，每个元素声明一种帧类型。
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:
以下示例定义了两种帧类型：
<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>
<name>ipv4</name>
<synopsis>IPv4 packet</synopsis>
<description>
This frame type refers to an IPv4 packet.
</description>
</frameDef>
<frameDef>
<name>ipv6</name>
<synopsis>IPv6 packet</synopsis>
<description>
This frame type refers to an IPv6 packet.
</description>
</frameDef>
...
</frameDefs>
The (optional) <dataTypeDefs> element can be used to define commonly used data types. It contains one or more <dataTypeDef> elements, each defining a data type with a unique name. Such data types can be used in several places in the library documents, including:
（可选）<dataTypeDefs>元素可用于定义常用的数据类型。它包含一个或多个<dataTypeDef>元素，每个元素用唯一的名称定义一个数据类型。此类数据类型可用于图书馆文档中的多个位置，包括：
o Defining other data types
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>
<name>ieeemacaddr</name>
<synopsis>48-bit IEEE MAC address</synopsis>
... type definition ...
</dataTypeDef>
<dataTypeDef>
<name>ipv4addr</name>
<synopsis>IPv4 address</synopsis>
... type definition ...
</dataTypeDef>
...
</dataTypeDefs>
There are two kinds of data types: atomic and compound. Atomic data types are appropriate for single-value variables (e.g., integer, string, byte array).
有两种数据类型：原子数据类型和复合数据类型。原子数据类型适用于单值变量（例如，整数、字符串、字节数组）。
The following built-in atomic data types are provided, but additional atomic data types can be defined with the <typeRef> and <atomic> elements:
提供了以下内置原子数据类型，但可以使用<typeRef>和<atomic>元素定义其他原子数据类型：
<name> Meaning
---- -------
char 8-bit signed integer
uchar 8-bit unsigned integer
int16 16-bit signed integer
uint16 16-bit unsigned integer
int32 32-bit signed integer
uint32 32-bit unsigned integer
int64 64-bit signed integer
uint64 64-bit unsigned integer
boolean A true / false value where
0 = false, 1 = true
string[N] A UTF-8 string represented in at most
N octets
string A UTF-8 string without a configured
storage length limit
byte[N] A byte array of N bytes
octetstring[N] A buffer of N octets, which MAY
contain fewer than N octets. Hence
the encoded value will always have
a length.
float32 32-bit IEEE floating point number
float64 64-bit IEEE floating point number
<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属性，但也可以在定义新数据类型时用作构建块。此处定义布尔数据类型是因为它非常常见，即使它可以通过子范围内的uchar数据类型构建，如原子类型（第4.5.2节）中所定义。
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.
复合数据类型可以构建在原子数据类型和其他复合数据类型的基础上。复合数据类型可以用四种方式之一定义。它们可以定义为某种化合物或原子数据类型的组件数组。它们可能是化合物或原子数据类型的命名组件的结构（参见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协议需要一种机制来传递复合数据类型。但是，此类表示的详细信息由ForCES协议[RFC5810]文档定义，而非模型文档。字符串和八进制字符串必须通过协议以其长度进行传输，因为它们没有分隔，值本身不包括长度，并且这些项是可变长度的。
With regard to strings, this model defines a small set of restrictions and definitions on how they are structured. String and octetstring length limits can be specified in the LFB class definitions. The component properties for string and octetstring components also contain actual lengths and length limits. This duplication of limits is to allow for implementations with smaller limits than the maximum limits specified in the LFB class definition. In all cases, these lengths are specified in octets, not in characters. In terms of protocol operation, as long as the specified length is within the FE's supported capabilities, the FE stores the contents of a string exactly as provided by the CE, and returns those contents when requested. No canonicalization, transformations, or equivalences are performed by the FE. Components of type string (or string[n]) MAY be used to hold identifiers for correlation with components in other LFBs. In such cases, an exact octet for octet match is used. No equivalences are used by the FE or CE in performing that matching. The ForCES protocol [RFC5810] does not perform or require validation of the content of UTF-8 strings. However, UTF-8 strings SHOULD be encoded in the shortest form to avoid potential security issues described in [UNICODE]. Any entity displaying such strings is expected to perform its own validation (for example, for correct multi-byte characters, and for ensuring that the string does not end in the middle of a multi-byte sequence). Specific LFB class definitions MAY restrict the valid contents of a string as suited to the particular usage (for example, a component that holds a DNS name would be restricted to hold only octets valid in such a name). FEs should validate the contents of SET requests for such restricted components at the time the set is performed, just as range checks for range-limited components are performed. The ForCES protocol behavior defines the normative processing for requests using that protocol.
关于字符串，这个模型定义了一组关于它们的结构的限制和定义。可以在LFB类定义中指定字符串和八进制字符串长度限制。字符串和八进制字符串组件的组件属性还包含实际长度和长度限制。这种限制的重复是为了允许实现比LFB类定义中指定的最大限制更小的限制。在所有情况下，这些长度都是以八位字节而不是字符指定的。在协议操作方面，只要指定的长度在FE支持的功能范围内，FE就会完全按照CE提供的方式存储字符串的内容，并在请求时返回这些内容。FE不执行规范化、转换或等效。string（或string[n]）类型的组件可用于保存与其他lfb中的组件相关的标识符。在这种情况下，使用精确的八位字节进行八位字节匹配。FE或CE在执行该匹配时不使用等价物。ForCES协议[RFC5810]不执行UTF-8字符串的内容，也不要求验证UTF-8字符串的内容。但是，UTF-8字符串应以最短的形式编码，以避免[UNICODE]中描述的潜在安全问题。任何显示此类字符串的实体都希望执行自己的验证（例如，对于正确的多字节字符，并确保字符串不在多字节序列的中间结束）。特定LFB类定义可能会根据特定用途限制字符串的有效内容（例如，持有DNS名称的组件将被限制为仅持有此类名称中有效的八位字节）。FEs应在执行SET时验证此类受限组件的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>、<atomic>、<array>、<struct>和<union>。
The predefined type alias is somewhere between the atomic and compound data types. Alias is used to allow a component inside an LFB to be an indirect reference to another component inside the same or a different LFB class or instance. The alias component behaves like a structure, one component of which has special behavior. Given that the special behavior is tied to the other parts of the structure, the compound result is treated as a predefined construct.
预定义的类型别名介于原子数据类型和复合数据类型之间。别名用于允许LFB中的组件间接引用相同或不同LFB类或实例中的另一个组件。alias组件的行为类似于结构，其中一个组件具有特殊行为。鉴于特殊行为与结构的其他部分相关联，复合结果将被视为预定义的构造。
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:
元素通过名称引用现有的数据类型。引用的数据类型必须在同一个库文档或其中一个包含的库文档中定义。如果引用的数据类型是原子数据类型，则新定义的类型也将被视为原子数据类型。如果引用的数据类型是复合类型，则新类型也将是复合类型。下面是一些用法示例：
<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>
<name>short</name>
<synopsis>Alias to int16</synopsis>
<typeRef>int16</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>ieeemacaddr</name>
<synopsis>48-bit IEEE MAC address</synopsis>
<typeRef>byte[6]</typeRef>
</dataTypeDef>
The <atomic> element allows the definition of a new atomic type from an existing atomic type, applying range restrictions and/or providing special enumerated values. Note that the <atomic> element can only use atomic types as base types, and its result MUST be another atomic type.
元素允许从现有原子类型定义新的原子类型，应用范围限制和/或提供特殊枚举值。请注意，<atomic>元素只能使用原子类型作为基类型，其结果必须是另一个原子类型。
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>
<name>dscp</name>
<synopsis>Diffserv code point.</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="63"/>
</rangeRestriction>
<specialValues>
<specialValue value="0">
<name>DSCP-BE</name>
<synopsis>Best Effort</synopsis>
</specialValue>
...
</specialValues>
</atomic>
</dataTypeDef>
The <array> element can be used to create a new compound data type as an array of a compound or an atomic data type. Depending upon context, this document and others refer to such arrays as tables or arrays interchangeably, without semantic or syntactic implication. The type of the array entry can be specified either by referring to an existing type (using the <typeRef> element) or defining an unnamed type inside the <array> element using any of the <atomic>, <array>, <struct>, or <union> elements.
元素可用于创建新的复合数据类型，作为复合或原子数据类型的数组。根据上下文，本文档和其他文档可以互换地将这些数组称为表或数组，而不涉及语义或语法含义。可以通过引用现有类型（使用<typeRef>元素）或使用<atomic>、<array>、<struct>或<union>元素中的任何元素在<array>元素内定义未命名类型来指定数组项的类型。
The array can be "fixed-size" or "variable-size", which is specified by the "type" attribute of the <array> element. The default is "variable-size". For variable-size arrays, an optional "maxlength" attribute specifies the maximum allowed length. This attribute should be used to encode semantic limitations, not implementation limitations. The latter (support for implementation constraints) should be handled by capability components of LFB classes, and should never be included as the maxlength in a data type array that is regarded as being of unlimited size.
数组可以是“固定大小”或“可变大小”，由<array>元素的“type”属性指定。默认值为“可变大小”。对于可变大小数组，可选的“maxlength”属性指定允许的最大长度。此属性应用于编码语义限制，而不是实现限制。后者（对实现约束的支持）应该由LFB类的功能组件来处理，并且不应该作为maxlength包含在被视为具有无限大小的数据类型数组中。
For fixed-size arrays, a "length" attribute MUST be provided that specifies the constant size of the array.
对于固定大小的数组，必须提供一个“length”属性来指定数组的常量大小。
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协议中使用任何声明的密钥来选择用于操作的组件（有关详细信息，请参阅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 在数组的任何实例中，每个声明的键在该实例中都必须是唯一的。也就是说，数组的任何两个组件在组成键的所有字段上的值都不可能相同。
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
每个密钥都用一个keyID声明，以便在ForCES协议[RFC5810]中使用，其中唯一密钥是通过组合一个或多个指定的密钥字段形成的。为了支持具有唯一值的原子类型的数组可以被这些值引用的情况，键字段标识符可以是“*”（即，数组条目是键）。如果数组的值类型是结构或数组，则键是值类型的一个或多个组件，每个组件由
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.
名称由于字段可能是包含结构的组件、结构组件的组件或进一步嵌套的组件，因此字段名实际上是组件标识符的串联序列，由小数点（“.”）分隔。下面的数组示例给出了键字段标识的语法。
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>
<name>dscp-mapping-table</name>
<synopsis>
A table of 64 DSCP values, used to re-map code space.
</synopsis>
<array type="fixed-size" length="64">
<typeRef>dscp</typeRef>
</array>
</dataTypeDef>
The following example defines a variable-size array with an upper limit on its size:
以下示例定义了一个可变大小数组，其大小有一个上限：
<dataTypeDef>
<name>mac-alias-table</name>
<synopsis>A table with up to 8 IEEE MAC addresses</synopsis>
<array type="variable-size" maxlength="8">
<typeRef>ieeemacaddr</typeRef>
</array>
</dataTypeDef>
<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>
<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").
在上面的示例中，数组的每个条目都是由两个组件（“规则”和“操作码”）组成的<struct>。
The following example shows a table of IP prefix information that can be accessed by a multi-field content key on the IP address, prefix length, and information source. This means that in any instance of this table, no two entries can have the same IP address, prefix length, and information source.
以下示例显示了IP地址、前缀长度和信息源上的多字段内容键可以访问的IP前缀信息表。这意味着在该表的任何实例中，任何两个条目都不能具有相同的IP地址、前缀长度和信息源。
<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>
<name>ipPrefixInfo_table</name>
<synopsis>
A table of information about known prefixes
</synopsis>
<array type="variable-size">
<struct>
<component componentID="1">
<name>address-prefix</name>
<synopsis>the prefix being described</synopsis>
<typeRef>ipv4Prefix</typeRef>
</component>
<component componentID="2">
<name>source</name>
<synopsis>
the protocol or process providing this information
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="3">
<name>prefInfo</name>
<synopsis>the information we care about</synopsis>
<typeRef>hypothetical-info-type</typeRef>
</component>
</struct>
<contentKey contentKeyID="1">
<contentKeyField> address-prefix.ipv4addr</contentKeyField>
<contentKeyField> address-prefix.prefixlen</contentKeyField>
<contentKeyField> source</contentKeyField>
</contentKey>
</array>
</dataTypeDef>
Note that the keyField elements could also have been simply address-prefix and source, since all of the fields of address-prefix are being used.
请注意，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).
为了使用键声明，必须引用可能嵌套在数组中其他组件中的组件。如果存在嵌套数组，甚至可以使用数组元素作为键（但需要非常小心以确保唯一性）。
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.
键字段中单个字段标识符的有效字符串取决于当前上下文。最初，在数组键声明中，上下文是数组的类型。逐步地，上下文是当前键字段声明中迄今为止处理的字段标识符所选择的任何类型。
When the current context is an array (e.g., when declaring a key for an array whose content is an array), then the only valid value for the field identifier is an explicit number.
当当前上下文是数组时（例如，当为内容为数组的数组声明键时），字段标识符的唯一有效值是显式数字。
When the current context is a structure, the valid values for the field identifiers are the names of the components of the structure. In the special case of declaring a key for an array containing an atomic type, where that content is unique and is to be used as a key, the value "*" MUST be used as the single key field identifier.
当当前上下文是结构时，字段标识符的有效值是结构组件的名称。在为包含原子类型的数组声明键的特殊情况下，如果该内容是唯一的并将用作键，则值“*”必须用作单个键字段标识符。
In reference array or structure elements, it is possible to construct keyFields that do not exist. keyField references SHOULD never reference optional structure components. For references to array elements, care must be taken to ensure that the necessary array elements exist when creating or modifying the overall array element. Failure to do so will result in FEs returning errors on the creation attempt.
在引用数组或结构元素中，可以构造不存在的关键字段。键域引用不应引用可选结构组件。对于数组元素的引用，必须注意确保在创建或修改整个数组元素时存在必要的数组元素。否则将导致FEs在创建尝试时返回错误。
A structure is composed of a collection of data components. Each data component has a data type (either an atomic type or an existing compound type) and is assigned a name unique within the scope of the compound data type being defined. These serve the same function as "struct" in C, etc. These components are defined using <component> elements. A <struct> element MAY contain an optional derivation indication, a <derivedFrom> element. The structure definition MUST contain a sequence of one or more <component> elements.
结构由一组数据组件组成。每个数据组件都有一个数据类型（原子类型或现有复合类型），并在所定义的复合数据类型的范围内分配一个唯一的名称。这些组件与C等中的“struct”功能相同。这些组件使用<component>元素定义。<struct>元素可以包含可选的派生指示，<derivedFrom>元素。结构定义必须包含一个或多个<component>元素的序列。
The actual type of the component can be defined by referring to an existing type (using the <typeRef> element), or can be a locally defined (unnamed) type created by any of the <atomic>, <array>, <struct>, or <union> elements.
组件的实际类型可以通过引用现有类型（使用<typeRef>元素）来定义，也可以是由<atomic>、<array>、<struct>或<union>元素创建的本地定义（未命名）类型。
The <component> element MUST include a componentID attribute. This provides the numeric ID for this component, for use by the protocol. The <component> MUST contain a component name and a synopsis. It MAY contain a <description> element giving a textual description of the component. The definition MAY also include an <optional> element, which indicates that the component being defined is optional. The definition MUST contain elements to define the data type of the component, as described above.
<component>元素必须包含一个componentID属性。这将提供此组件的数字ID，供协议使用。<component>必须包含组件名称和概要。它可能包含一个<description>元素，给出组件的文本描述。该定义还可以包括<optional>元素，该元素指示所定义的组件是可选的。定义必须包含定义组件数据类型的元素，如上所述。
For a dataTypeDef of a struct, the structure definition MAY be inherited from, and augment, a previously defined structured type. This is indicated by including the optional derivedFrom attribute in the struct declaration before the definition of the augmenting or replacing components. Section 4.5.7 describes how this is done in more detail.
对于结构的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.
结构（或LFB）中不同组件的componentID属性必须不同。它们不需要按顺序排列，也不需要按顺序排列。为了清晰易懂，易于维护，通常至少定义一组连续的值。但这是为了人的方便，而不是模型或协议要求。
The result of this construct is always a compound type, even when the <struct> contains only one field.
此构造的结果始终是复合类型，即使<struct>仅包含一个字段。
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>
<name>ipv4prefix</name>
<synopsis>
IPv4 prefix defined by an address and a prefix length
</synopsis>
<struct>
<component componentID="1">
<name>address</name>
<synopsis>Address part</synopsis>
<typeRef>ipv4addr</typeRef>
</component>
<component componentID="2">
<name>prefixlen</name>
<synopsis>Prefix length part</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="32"/>
</rangeRestriction>
</atomic>
</component>
</struct>
</dataTypeDef>
Similar to the union declaration in C, this construct allows the definition of overlay types. Its format is identical to the <struct> element.
与C中的union声明类似，此构造允许定义覆盖类型。其格式与<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
有时有必要在LFB中有一个组件，或在其他LFB中引用信息（组件）的结构。例如，这可以允许ARP LFB与本地传输LFB共享IP->MAC地址表，而无需重复信息。类似地，它可以允许流量测量LFB与流量执行LFB共享信息。<alias>声明为此创建了构造。此构造告诉CE和FE，对已定义数据的任何操作实际上都是对数据的操作
defined to exist in some specified part of some other LFB instance. The content of an <alias> element MUST be a named type. Whatever component the alias references (which is determined by the alias component properties, as described below), that component must be of the same type as that declared for the alias. Thus, when the CE or FE dereferences the alias component, the type of the information returned is known. The type can be a base type or a derived type. The actual value referenced by an alias is known as its target. When a GET or SET operation references the alias element, the value of the target is returned or replaced. Write access to an alias element is permitted if write access to both the alias and the target is permitted.
定义为存在于其他LFB实例的某些指定部分中。<alias>元素的内容必须是命名类型。别名引用的任何组件（由别名组件属性确定，如下所述），该组件的类型必须与为别名声明的组件的类型相同。因此，当CE或FE取消对别名组件的引用时，返回的信息类型是已知的。类型可以是基类型或派生类型。别名引用的实际值称为其目标值。当GET或SET操作引用alias元素时，将返回或替换目标的值。如果同时允许对别名和目标进行写访问，则允许对别名元素进行写访问。
The target of a component declared by an <alias> element is determined by the information in the component's properties. Like all components, the properties include the support / read / write permission for the alias. In addition, there are several fields (components) in the alias properties that define the target of the alias. These components are the ID of the LFB class of the target, the ID of the LFB instance of the target, and a sequence of integers representing the path within the target LFB instance to the target component. The type of the target element must match the declared type of the alias. Details of the alias property structure are described in Section 4.8 of this document, on properties.
由<alias>元素声明的组件的目标由组件属性中的信息确定。与所有组件一样，属性包括别名的支持/读/写权限。此外，别名属性中有几个字段（组件）定义别名的目标。这些组件是目标的LFB类的ID、目标的LFB实例的ID以及表示目标LFB实例到目标组件的路径的整数序列。目标元素的类型必须与声明的别名类型匹配。关于alias属性结构的详细信息，请参见本文档第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
这样做的一个结果是，扩充与派生它们的复合类型向后兼容。因此，扩充在为具有向后兼容性的LFB子类定义组件时非常有用。除了向类添加新组件外，现有组件的数据类型还可以替换为
augmentation of that component, and still meet the compatibility rules for subclasses. This compatibility constraint is why augmentations cannot be applied to unions.
该组件的扩展，并且仍然满足子类的兼容性规则。这个兼容性约束就是为什么不能将增强应用于联合。
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.
例如，考虑一个简单的基LFB类A，它只有X的一个组件（COMP1）。从A类中派生类A1的一种方法可以是简单地添加第二个组件（任何类型）。从a派生A2类的另一种方法是将X类a中的原始组件（comp1）替换为Y类中的一个，其中Y是X的扩充。A1类和A2类都与a类向后兼容。
The syntax for augmentations is to include a <derivedFrom> element in a structure definition, indicating what structure type is being augmented. Component names and component IDs for new components within the augmentation MUST NOT be the same as those in the structure type being augmented. For those components where the data type of an existing component is being replaced with a suitable augmenting data type, the existing component name and component ID MUST be used in the augmentation. Other than the constraint on existing elements, there is no requirement that the new component IDs be sequential with, greater than, or in any other specific relationship to the existing component IDs except different. It is expected that using values sequential within an augmentation, and distinct from the previously used values, will be a common method to enhance human readability.
扩充的语法是在结构定义中包含<derivedFrom>元素，指示要扩充的结构类型。扩充中新组件的组件名称和组件ID不得与要扩充的结构类型中的组件名称和组件ID相同。对于那些将现有组件的数据类型替换为合适的扩充数据类型的组件，必须在扩充中使用现有组件名称和组件ID。除了对现有元素的约束外，不要求新组件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>元素包含一个或多个<metadataDef>元素。每个<metadataDef>元素定义一个元数据。
Each <metadataDef> element MUST contain a unique name (NMTOKEN). Uniqueness is defined to be over all metadata defined in this library document and in all directly or indirectly included library documents. The <metadataDef> element MUST also contain a brief synopsis, the tag value to be used for this metadata, and value type definition information. Only atomic data types can be used as value types for metadata. The <metadataDef> element MAY contain a detailed description element.
每个<metadataDef>元素必须包含唯一的名称（NMTOKEN）。唯一性定义为此库文档以及所有直接或间接包含的库文档中定义的所有元数据。<metadataDef>元素还必须包含简短的概要、用于此元数据的标记值以及值类型定义信息。只有原子数据类型可以用作元数据的值类型。<metadataDef>元素可能包含详细的描述元素。
Two forms of type definitions are allowed. The first form uses the <typeRef> element to refer to an existing atomic data type defined in the <dataTypeDefs> element of the same library document or in one of the included library documents. The usage of the <typeRef> element is identical to how it is used in the <dataTypeDef> elements, except here it can only refer to atomic types. The latter restriction is not enforced by the XML schema.
允许使用两种形式的类型定义。第一种形式使用<typeRef>元素来引用在同一个库文档的<dataTypeDefs>元素或其中一个包含的库文档中定义的现有原子数据类型。<typeRef>元素的用法与它在<dataTypeDef>元素中的用法相同，只是这里它只能引用原子类型。XML模式不强制执行后一个限制。
The second form is an explicit type definition using the <atomic> element. This element is used here in the same way as in the <dataTypeDef> elements.
第二种形式是使用<atomic>元素的显式类型定义。此元素在此处的使用方式与<dataTypeDef>元素中的使用方式相同。
The following example shows both usages:
以下示例显示了这两种用法：
<metadataDefs>
<metadataDef>
<name>NEXTHOPID</name>
<synopsis>Refers to a Next Hop entry in NH LFB</synopsis>
<metadataID>17</metadataID>
<typeRef>int32</typeRef>
</metadataDef>
<metadataDef>
<name>CLASSID</name>
<synopsis>
Result of classification (0 means no match).
</synopsis>
<metadataID>21</metadataID>
<atomic>
<baseType>int32</baseType>
<specialValues>
<specialValue value="0">
<name>NOMATCH</name>
<synopsis>
Classification didn't result in match.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
</metadataDefs>
<metadataDefs>
<metadataDef>
<name>NEXTHOPID</name>
<synopsis>Refers to a Next Hop entry in NH LFB</synopsis>
<metadataID>17</metadataID>
<typeRef>int32</typeRef>
</metadataDef>
<metadataDef>
<name>CLASSID</name>
<synopsis>
Result of classification (0 means no match).
</synopsis>
<metadataID>21</metadataID>
<atomic>
<baseType>int32</baseType>
<specialValues>
<specialValue value="0">
<name>NOMATCH</name>
<synopsis>
Classification didn't result in match.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
</metadataDefs>
The (optional) <LFBClassDefs> element can be used to define one or more LFB classes using <LFBClassDef> elements. Each <LFBClassDef> element MUST define an LFB class and include the following elements:
（可选）<LFBClassDefs>元素可用于使用<LFBClassDef>元素定义一个或多个LFB类。每个<LFBClassDef>元素必须定义一个LFB类，并包括以下元素：
o <name> provides the symbolic name of the LFB class. Example: "ipv4lpm".
o <name>提供LFB类的符号名。示例：“ipv4lpm”。
o <synopsis> provides a short synopsis of the LFB class. Example: "IPv4 Longest Prefix Match Lookup LFB".
o <synopsis>提供LFB类的简短概要。示例：“IPv4最长前缀匹配查找LFB”。
o <version> is the version indicator.
o <version>是版本指示器。
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 <components>定义LFB的操作组件。
o <capabilities> defines the capability components of the LFB.
o <capabilities>定义LFB的功能组件。
o <description> contains the operational specification of the LFB.
o <description>包含LFB的操作规范。
o The LFBClassID attribute of the LFBClassDef element defines the ID for this class. These must be globally unique.
o LFBClassDef元素的LFBClassID属性定义了此类的ID。这些必须是全球唯一的。
o <events> defines the events that can be generated by instances of this LFB.
o <events>定义此LFB实例可以生成的事件。
LFB class names must be unique, in order to enable other documents to reference the classes by name, and to enable human readers to understand references to class names. While a complex naming structure could be created, simplicity is preferred. As given in the IANA Considerations section of this document, the IANA maintains a registry of LFB class names and class identifiers, along with a reference to the document defining the class.
LFB类名必须是唯一的，以使其他文档能够按名称引用类，并使人类读者能够理解对类名的引用。虽然可以创建复杂的命名结构，但简单性是首选。如本文档IANA注意事项部分所述，IANA维护LFB类名和类标识符的注册表，以及对定义类的文档的引用。
Below is a skeleton of an example LFB class definition. Note that in order to keep from complicating the XML schema, the order of elements in the class definition is fixed. Elements, if they appear, must appear in the order shown.
下面是一个示例LFB类定义的框架。注意，为了避免使XML模式复杂化，类定义中元素的顺序是固定的。元素（如果出现）必须按显示的顺序出现。
<LFBClassDefs>
<LFBClassDef LFBClassID="12345">
<name>ipv4lpm</name>
<synopsis>IPv4 Longest Prefix Match Lookup LFB</synopsis>
<version>1.0</version>
<derivedFrom>baseclass</derivedFrom>
<LFBClassDefs>
<LFBClassDef LFBClassID="12345">
<name>ipv4lpm</name>
<synopsis>IPv4 Longest Prefix Match Lookup LFB</synopsis>
<version>1.0</version>
<derivedFrom>baseclass</derivedFrom>
<inputPorts>
...
</inputPorts>
<inputPorts>
...
</inputPorts>
<outputPorts>
...
</outputPorts>
<outputPorts>
...
</outputPorts>
<components>
...
</components>
<components>
...
</components>
<capabilities>
...
</capabilities>
<capabilities>
...
</capabilities>
<events>
...
</events>
<events>
...
</events>
<description> This LFB represents the IPv4 longest prefix match lookup operation. The modeled behavior is as follows: Blah-blah-blah. </description>
<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协议使用。这些组件与结构中使用的组件并行，并以相同的方式使用。组件和功能组件在LFB类定义中必须是唯一的。
Note that the <name>, <synopsis>, and <version> elements are required; all other elements are optional in <LFBClassDef>. However, when they are present, they must occur in the above order.
注意，<name>、<synopsis>和<version>元素是必需的；所有其他元素在<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类的唯一名称（<name>）。引用的LFB类必须在同一个库文档或其中一个包含的库文档中定义。在缺少<derivedFrom>的情况下，该类从概念上派生自公共的空基类。
It is assumed that a derived class is backward compatible with its base class. A derived class MAY add components to a parent class, but cannot delete components. This also applies to input and output ports, events, and capabilities.
假定派生类与其基类向后兼容。派生类可以向父类添加组件，但不能删除组件。这也适用于输入和输出端口、事件和功能。
The optional <inputPorts> element is used to define input ports. An LFB class MAY have zero, one, or more inputs. If the LFB class has no input ports, the <inputPorts> element MUST be omitted. The <inputPorts> element can contain one or more <inputPort> elements, one for each port or port group. We assume that most LFBs will have exactly one input. Multiple inputs with the same input type are modeled as one input group. Input groups are defined the same way as input ports by the <inputPort> element, differentiated only by an optional "group" attribute.
可选的<inputPorts>元素用于定义输入端口。LFB类可以有零个、一个或多个输入。如果LFB类没有输入端口，则必须省略<inputPorts>元素。<inputPorts>元素可以包含一个或多个<inputPort>元素，每个端口或端口组一个。我们假设大多数LFB只有一个输入。具有相同输入类型的多个输入被建模为一个输入组。输入组的定义方式与输入端口相同，由<inputPort>元素定义，仅由可选的“group”属性区分。
Multiple inputs with different input types should be avoided if possible (see discussion in Section 4.7.3). Some special LFBs will have no inputs at all. For example, a packet generator LFB does not need an input.
如果可能，应避免使用不同输入类型的多个输入（见第4.7.3节的讨论）。一些特殊LFB将完全没有输入。例如，分组生成器LFB不需要输入。
Single input ports and input port groups are both defined by the <inputPort> element; they are differentiated only by an optional "group" attribute.
单个输入端口和输入端口组都由<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 <name>提供输入的符号名称。例如：“在”。请注意，此符号名只能在LFB类的范围内唯一。
o <synopsis> contains a brief description of the input. Example: "Normal packet input".
o <synopsis>包含输入的简要说明。示例：“正常数据包输入”。
o <expectation> lists all allowed frame formats. Example: {"ipv4" and "ipv6"}. Note that this list should refer to names specified in the <frameDefs> element of the same library document or in any included library documents. The <expectation> element can also provide a list of required metadata. Example: {"classid", "vpnid"}. This list should refer to names of metadata defined in the <metadataDefs> element in the same library document or in any included library documents. For each metadatum, it must be specified whether the metadatum is required or optional. For each optional metadatum, a default value must be specified, which is used by the LFB if the metadatum is not provided with a packet.
o <expectation>列出所有允许的帧格式。示例：{“ipv4”和“ipv6”}。请注意，此列表应引用在同一库文档的<frameDefs>元素或任何包含的库文档中指定的名称。<expectation>元素还可以提供所需元数据的列表。示例：{“classid”、“vpnid”}。此列表应引用在同一库文档或任何包含的库文档中的<metadataDefs>元素中定义的元数据名称。对于每个元基准，必须指定元基准是必需的还是可选的。对于每个可选元数据，必须指定一个默认值，如果该元数据未随数据包提供，LFB将使用该值。
In addition, the optional "group" attribute of the <inputPort> element can specify if the port can behave as a port group, i.e., it is allowed to be instantiated. This is indicated by a "true" value (the default value is "false").
此外，<inputPort>元素的可选“group”属性可以指定端口是否可以作为端口组使用，即允许对其进行实例化。这由“真”值表示（默认值为“假”）。
An example <inputPorts> element, defining two input ports, the second one being an input port group is the following:
定义两个输入端口（第二个为输入端口组）的<inputPorts>元素示例如下：
<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>
<name>in</name>
<synopsis>Normal input</synopsis>
<expectation>
<frameExpected>
<ref>ipv4</ref>
<ref>ipv6</ref>
</frameExpected>
<metadataExpected>
<ref>classid</ref>
<ref>vifid</ref>
<ref dependency="optional" defaultValue="0">vrfid</ref>
</metadataExpected>
</expectation>
</inputPort>
<inputPort group="true">
... another input port ...
</inputPort>
</inputPorts>
For each <inputPort>, the frame type expectations are defined by the
<frameExpected> element using one or more <ref> elements (see example
above). When multiple frame types are listed, it means that "one of
these" frame types is expected. A packet of any other frame type is
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".
视为与LFB类的此输入端口不兼容。上面的示例列出了两种预期的帧类型：“ipv4”和“ipv6”。
Metadata expectations are specified by the <metadataExpected> element. In its simplest form, this element can contain a list of <ref> elements, each referring to a metadatum. When multiple instances of metadata are listed by <ref> elements, it means that "all of these" metadata must be received with each packet (except metadata that are marked as "optional" by the "dependency" attribute of the corresponding <ref> element). For a metadatum that is specified "optional", a default value MUST be provided using the "defaultValue" attribute. The above example lists three metadata as expected metadata, two of which are mandatory ("classid" and "vifid"), and one being optional ("vrfid").
元数据期望值由<metadataExpected>元素指定。在最简单的形式中，该元素可以包含<ref>元素的列表，每个元素都引用一个元数据。当<ref>元素列出多个元数据实例时，这意味着每个数据包都必须接收“所有这些”元数据（由相应<ref>元素的“dependency”属性标记为“可选”的元数据除外）。对于指定为“可选”的元数据，必须使用“defaultValue”属性提供默认值。上面的示例列出了三个元数据作为预期元数据，其中两个是必需的（“classid”和“vifid”），一个是可选的（“vrfid”）。
The schema also allows for more complex definitions of metadata expectations. For example, using the <one-of> element, a list of metadata can be specified to express that at least one of the specified metadata must be present with any packet. An example is the following:
该模式还允许对元数据期望进行更复杂的定义。例如，使用<one of>元素，可以指定元数据列表，以表示任何数据包都必须至少存在一个指定的元数据。一个例子如下：
<metadataExpected>
<one-of>
<ref>prefixmask</ref>
<ref>prefixlen</ref>
</one-of>
</metadataExpected>
<metadataExpected>
<one-of>
<ref>prefixmask</ref>
<ref>prefixlen</ref>
</one-of>
</metadataExpected>
The above example specifies that either the "prefixmask" or the "prefixlen" metadata must be provided with any packet.
上面的示例指定任何数据包都必须提供“prefixmask”或“prefixlen”元数据。
The two forms can also be combined, as shown in the following example:
这两种形式也可以组合，如下例所示：
<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>
<ref>classid</ref>
<ref>vifid</ref>
<ref dependency="optional" defaultValue="0">vrfid</ref>
<one-of>
<ref>prefixmask</ref>
<ref>prefixlen</ref>
</one-of>
</metadataExpected>
Although the schema is constructed to allow even more complex definitions of metadata expectations, we do not discuss those here.
尽管模式的构造允许对元数据期望进行更复杂的定义，但我们在此不讨论这些定义。
The optional <outputPorts> element is used to define output ports. An LFB class MAY have zero, one, or more outputs. If the LFB class has no output ports, the <outputPorts> element MUST be omitted. The <outputPorts> element MUST contain one or more <outputPort> elements, one for each port or port group. If there are multiple outputs with the same output type, we model them as an output port group. Some special LFBs have no outputs at all (e.g., Dropper).
可选的<outputPorts>元素用于定义输出端口。LFB类可以有零个、一个或多个输出。如果LFB类没有输出端口，则必须省略<outputPorts>元素。<outputPorts>元素必须包含一个或多个<outputPort>元素，每个端口或端口组一个。如果有多个输出具有相同的输出类型，我们将它们建模为一个输出端口组。一些特殊LFB根本没有输出（例如滴管）。
Single output ports and output port groups are both defined by the <outputPort> element; they are differentiated only by an optional "group" attribute.
单个输出端口和输出端口组都由<outputPort>元素定义；它们仅通过可选的“组”属性进行区分。
The <outputPort> element MUST contain the following elements:
<outputPort>元素必须包含以下元素：
o <name> provides the symbolic name of the output. Example: "out". Note that the symbolic name must be unique only within the scope of the LFB class.
o <name>提供输出的符号名称。例如：“退出”。请注意，符号名只能在LFB类的范围内唯一。
o <synopsis> contains a brief description of the output port. Example: "Normal packet output".
o <synopsis>包含输出端口的简要说明。示例：“正常数据包输出”。
o <product> lists the allowed frame formats. Example: {"ipv4", "ipv6"}. Note that this list should refer to symbols specified in the <frameDefs> element in the same library document or in any included library documents. The <product> element MAY also contain the list of emitted (generated) metadata. Example: {"classid", "color"}. This list should refer to names of metadata specified in the <metadataDefs> element in the same library document or in any included library documents. For each generated metadatum, it should be specified whether the metadatum is always generated or generated only in certain conditions. This information is important when assessing compatibility between LFBs.
o <product>列出了允许的帧格式。示例：{“ipv4”、“ipv6”}。请注意，此列表应参考同一库文档或任何包含的库文档中<frameDefs>元素中指定的符号。<product>元素还可能包含发出（生成）元数据的列表。示例：{“classid”，“color”}。此列表应引用在同一库文档或任何包含的库文档中的<metadataDefs>元素中指定的元数据名称。对于每个生成的元数据，应指定是始终生成元数据还是仅在特定条件下生成元数据。在评估LFB之间的兼容性时，此信息非常重要。
In addition, the optional "group" attribute of the <outputPort> element can specify if the port can behave as a port group, i.e., it is allowed to be instantiated. This is indicated by a "true" value (the default value is "false").
此外，<outputPort>元素的可选“group”属性可以指定端口是否可以作为端口组使用，即允许对其进行实例化。这由“真”值表示（默认值为“假”）。
The following example specifies two output ports, the second being an output port group:
以下示例指定了两个输出端口，第二个是输出端口组：
<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>
<outputPort>
<name>out</name>
<synopsis>Normal output</synopsis>
<product>
<frameProduced>
<ref>ipv4</ref>
<ref>ipv4bis</ref>
</frameProduced>
<metadataProduced>
<ref>nhid</ref>
<ref>nhtabid</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="true">
<name>exc</name>
<synopsis>Exception output port group</synopsis>
<product>
<frameProduced>
<ref>ipv4</ref>
<ref>ipv4bis</ref>
</frameProduced>
<metadataProduced>
<ref availability="conditional">errorid</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
The types of frames and metadata the port produces are defined inside the <product> element in each <outputPort>. Within the <product> element, the list of frame types the port produces is listed in the <frameProduced> element. When more than one frame is listed, it means that "one of" these frames will be produced.
端口生成的帧和元数据的类型在每个<outputPort>的<product>元素中定义。在<product>元素中，端口生成的帧类型列表列在<frameproducted>元素中。当列出多个帧时，表示将生成这些帧中的“一个”。
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.
每个数据包生成的元数据列表列在<product>的可选<metadataproducted>元素中。在最简单的形式中，该元素可以包含一个<ref>元素列表，每个元素都引用一个元基准类型。这种列表的含义是，除了那些以可选的“可用性”属性设置为“条件”列出的元数据外，每个数据包都提供“所有”这些元数据。与<inputPort>的<metadataExpected>元素类似，<MetadataProducted>元素支持更复杂的形式，我们在这里不再进一步讨论。
Operational parameters of the LFBs that must be visible to the CEs are conceptualized in the model as the LFB components. These include, for example, flags, single parameter arguments, complex arguments, and tables. Note that the components here refer to only those operational parameters of the LFBs that must be visible to the CEs. Other variables that are internal to LFB implementation are not regarded as LFB components and hence are not covered.
CEs必须可见的LFB操作参数在模型中被概念化为LFB组件。例如，这些参数包括标志、单参数参数参数、复杂参数和表。请注意，此处的组件仅指必须对CEs可见的LFB的操作参数。LFB实现内部的其他变量不被视为LFB组件，因此不包括在内。
Some examples for LFB components are:
LFB组件的一些示例如下：
o Configurable flags and switches selecting between operational modes of the LFB
o 在LFB操作模式之间选择的可配置标志和开关
o Number of inputs or outputs in a port group
o 端口组中的输入或输出数
o Various configurable lookup tables, including interface tables, prefix tables, classification tables, DSCP mapping tables, MAC address tables, etc.
o 各种可配置的查找表，包括接口表、前缀表、分类表、DSCP映射表、MAC地址表等。
o Packet and byte counters
o 数据包和字节计数器
o Various event counters
o 各种事件计数器
o Number of current inputs or outputs for each input or output group
o 每个输入或输出组的当前输入或输出数量
The ForCES model supports the definition of access permission restrictions on what the CE can do with an LFB component. The following categories are supported by the model:
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 只写组件。这可以是任何未向CEs提供读取能力的可配置数据（例如，安全密钥信息）。
o Read-reset components. The CE can read and reset this resource, but cannot set it to an arbitrary value. Example: Counters.
o 读取重置组件。CE可以读取并重置此资源，但不能将其设置为任意值。示例：计数器。
o Firing-only components. A write attempt to this resource will trigger some specific actions in the LFB, but the actual value written is ignored.
o 只发射组件。对该资源的写入尝试将触发LFB中的某些特定操作，但实际写入的值将被忽略。
The LFB class MUST define only one possible access mode for a given component.
LFB类只能为给定组件定义一种可能的访问模式。
The components of the LFB class are listed in the <components> element. Each component is defined by an <component> element. A <component> element contains some or all of the following elements, some of which are mandatory:
LFB类的组件列在<components>元素中。每个组件由<component>元素定义。<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 <name>必须出现，并定义组件的名称。该名称在LFB类的组件中必须是唯一的。例如：“版本”。
o <synopsis> is also mandatory, and provides a brief description of the purpose of the component.
o <synopsis>也是强制性的，并提供了组件用途的简要说明。
o <optional/> is an optional element, and if present indicates that this component is optional.
o <optional/>是可选元素，如果存在，则表示此组件是可选的。
o The data type of the component can be defined either via a reference to a predefined data type or by providing a local definition of the type. The former is provided by using the <typeRef> element, which must refer to the unique name of an existing data type defined in the <dataTypeDefs> element in the same library document or in any of the included library documents. When the data type is defined locally (unnamed type), one of the following elements can be used: <atomic>, <array>, <struct>, or <union>. Their usage is identical to how they are used inside <dataTypeDef> elements (see Section 4.5). Some form of data type definition MUST be included in the component definition.
o 可以通过引用预定义的数据类型或提供类型的本地定义来定义组件的数据类型。前者通过使用<typeRef>元素提供，该元素必须引用同一库文档或任何包含的库文档中<dataTypeDefs>元素中定义的现有数据类型的唯一名称。在本地定义数据类型（未命名类型）时，可以使用以下元素之一：<atomic>、<array>、<struct>或<union>。它们的用法与<dataTypeDef>元素中使用它们的方式相同（参见第4.5节）。组件定义中必须包含某种形式的数据类型定义。
o The <defaultValue> element is optional, and if present is used to specify a default value for a component. If a default value is specified, the FE must ensure that the component has that value when the LFB is initialized or reset. If a default value is not specified for a component, the CE MUST make no assumptions as to what the value of the component will be upon initialization. The CE must either read the value or set the value, if it needs to know what it is.
o <defaultValue>元素是可选的，如果存在，则用于指定组件的默认值。如果指定了默认值，FE必须确保LFB初始化或重置时组件具有该值。如果未为组件指定默认值，CE不得假设组件在初始化时的值。如果CE需要知道该值是什么，则必须读取该值或设置该值。
o The <description> element MAY also appear. If included, it provides a longer description of the meaning or usage of the particular component being defined.
o <description>元素也可能出现。如果包括，它将对所定义的特定组件的含义或用法提供更长的描述。
The <component> element also MUST have a componentID attribute, which is a numeric value used by the ForCES protocol.
<component>元素还必须具有componentID属性，该属性是ForCES协议使用的数值。
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>元素还包括可选的“access”属性，该属性可以采用以下任意值：“只读”、“读写”、“仅写”、“读重置”和“仅触发器”。默认访问模式为“读写”。
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.
对于给定的LFB实例，CE可以通过读取该组件的属性信息来确定是否支持可选组件，以及定义为读写的组件是否可以实际写入。“仅触发器”的访问控制设置意味着此组件仅用于事件检测。
The following example defines two components for an LFB:
以下示例为LFB定义了两个组件：
<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>
<components>
<component access="read-only" componentID="1">
<name>foo</name>
<synopsis>number of things</synopsis>
<typeRef>uint32</typeRef>
</component>
<component access="read-write" componentID="2">
<name>bar</name>
<synopsis>number of this other thing</synopsis>
<atomic>
<baseType>uint32</baseType>
<rangeRestriction>
<allowedRange min="10" max="2000"/>
</rangeRestriction>
</atomic>
<defaultValue>10</defaultValue>
</component>
</components>
The first component ("foo") is a read-only 32-bit unsigned integer, defined by referring to the built-in "uint32" atomic type. The second component ("bar") is also an integer, but uses the <atomic> element to provide additional range restrictions. This component has access mode of read-write allowing it to be both read and written. A default value of 10 is provided for bar. Although the access for bar is read-write, some implementations MAY offer only more restrictive access, and this would be reported in the component properties.
第一个组件（“foo”）是一个只读的32位无符号整数，通过引用内置的“uint32”原子类型来定义。第二个组件（“条”）也是一个整数，但使用<atomic>元素提供额外的范围限制。该组件具有读写访问模式，允许读写。bar的默认值为10。尽管对bar的访问是读写的，但某些实现可能只提供更严格的访问，这将在组件属性中报告。
Note that not all components are likely to exist at all times in a particular implementation. While the capabilities will frequently indicate this non-existence, CEs may attempt to reference non-existent or non-permitted components anyway. The ForCES protocol mechanisms should include appropriate error indicators for this case.
请注意，并非所有组件都可能在特定实现中始终存在。虽然这些功能经常表明不存在，但CEs可能会尝试引用不存在或不允许的组件。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类规范为FE实现提供了关于如何实现LFB类的一些灵活性。例如，该实例可能有一些不是类定义固有的限制，而是一些实现限制的结果。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>中单独的<capabilities>元素中。<capability>元素包含一个或多个<capability>元素，每个元素定义一个功能组件。<capability>元素的格式几乎与<component>元素相同。它在两个方面有所不同：它缺少访问模式属性（因为它总是只读的），并且它缺少<defaultValue>元素（因为默认值不适用于只读属性）。
Some examples of capability components follow:
以下是一些功能组件的示例：
o The version of the LFB class with which this LFB instance complies
o 此LFB实例所遵循的LFB类的版本
o Supported optional features of the LFB class
o LFB类支持的可选功能
o Maximum number of configurable outputs for an output group
o 输出组的最大可配置输出数
o Metadata pass-through limitations of the LFB
o 元数据通过LFB的限制
o Additional range restriction on operational components
o 对运行部件的附加范围限制
The following example lists two capability attributes:
以下示例列出了两个功能属性：
<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>
<capabilities>
<capability componentID="3">
<name>version</name>
<synopsis>
LFB class version this instance is compliant with.
</synopsis>
<typeRef>version</typeRef>
</capability>
<capability componentID="4">
<name>limitBar</name>
<synopsis>
Maximum value of the "bar" attribute.
</synopsis>
<typeRef>uint16</typeRef>
</capability>
</capabilities>
The <events> element contains the information about the occurrences for which instances of this LFB class can generate notifications to the CE. High-level view on the declaration and operation of LFB events is described in Section 3.2.5.
<events>元素包含有关此LFB类的实例可以生成通知给CE的事件的信息。第3.2.5节描述了LFB事件声明和操作的高级视图。
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:
<events>元素包含0个或多个<event>元素，每个元素声明一个事件。<event>元素有一个eventID属性，该属性给出事件的唯一（每个LFB类）ID。该要素将包括：
o <eventTarget> element indicating which LFB field (component) is tested to generate the event.
o <eventTarget>元素，指示测试哪个LFB字段（组件）以生成事件。
o <condition> element indicating what condition on the field will generate the event from a list of defined conditions.
o <condition>元素，指示字段上的哪个条件将从定义的条件列表生成事件。
o <eventReports> element indicating what values are to be reported in the notification of the event.
o <eventReports>元素，指示在事件通知中要报告的值。
The example below demonstrates the different constructs.
下面的示例演示了不同的构造。
The <events> element has a baseID attribute value, which is normally <events baseID="number">. The value of the baseID is the starting componentID for the path that identifies events. It must not be the same as the componentID of any top-level components (including capabilities) of the LFB class. In derived LFBs (i.e., ones with a <derivedFrom> element) where the parent LFB class has an events
<events>元素有一个baseID属性值，通常为<events baseID=“number”>。baseID的值是标识事件的路径的起始组件ID。它不能与LFB类的任何顶级组件（包括功能）的组件ID相同。在派生LFB中（即具有<derivedFrom>元素的LFB），父LFB类具有事件
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.
声明时，派生的LFB<events>元素中不能存在baseID。而是使用父LFB类中的baseID值。在所示的示例中，baseID是7。
<events baseID="7">
<event eventID="7">
<name>Foochanged</name>
<synopsis>
An example event for a scalar
</synopsis>
<eventTarget>
<eventField>foo</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<!-- report the new state -->
<eventReport>
<eventField>foo</eventField>
</eventReport>
</eventReports>
</event>
<events baseID="7">
<event eventID="7">
<name>Foochanged</name>
<synopsis>
An example event for a scalar
</synopsis>
<eventTarget>
<eventField>foo</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<!-- report the new state -->
<eventReport>
<eventField>foo</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="8">
<name>Goof1changed</name>
<synopsis>
An example event for a complex structure
</synopsis>
<eventTarget>
<!-- target is goo.f1 -->
<eventField>goo</eventField>
<eventField>f1</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<!-- report the new state of goo.f1 -->
<eventReport>
<eventField>goo</eventField>
<eventField>f1</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="8">
<name>Goof1changed</name>
<synopsis>
An example event for a complex structure
</synopsis>
<eventTarget>
<!-- target is goo.f1 -->
<eventField>goo</eventField>
<eventField>f1</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<!-- report the new state of goo.f1 -->
<eventReport>
<eventField>goo</eventField>
<eventField>f1</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="9">
<name>NewbarEntry</name>
<synopsis>
Event for a new entry created on table bar
</synopsis>
<eventTarget>
<eventField>bar</eventField>
<eventSubscript>_barIndex_</eventSubscript>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>bar</eventField>
<eventSubscript>_barIndex_</eventSubscript>
</eventReport>
<eventReport>
<eventField>foo</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="9">
<name>NewbarEntry</name>
<synopsis>
Event for a new entry created on table bar
</synopsis>
<eventTarget>
<eventField>bar</eventField>
<eventSubscript>_barIndex_</eventSubscript>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>bar</eventField>
<eventSubscript>_barIndex_</eventSubscript>
</eventReport>
<eventReport>
<eventField>foo</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="10">
<name>Gah11changed</name>
<synopsis>
Event for table gah, entry index 11 changing
</synopsis>
<eventTarget>
<eventField>gah</eventField>
<eventSubscript>11</eventSubscript>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>gah</eventField>
<eventSubscript>11</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="10">
<name>Gah11changed</name>
<synopsis>
Event for table gah, entry index 11 changing
</synopsis>
<eventTarget>
<eventField>gah</eventField>
<eventSubscript>11</eventSubscript>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>gah</eventField>
<eventSubscript>11</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="11">
<name>Gah10field1</name>
<synopsis>
Event for table gah, entry index 10, column field1 changing
</synopsis>
<eventTarget>
<eventField>gah</eventField>
<eventSubscript>10</eventSubscript>
<eventField>field1</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>gah</eventField>
<eventSubscript>10</eventSubscript>
</eventReport>
</eventReports>
</event>
</events>
<event eventID="11">
<name>Gah10field1</name>
<synopsis>
Event for table gah, entry index 10, column field1 changing
</synopsis>
<eventTarget>
<eventField>gah</eventField>
<eventSubscript>10</eventSubscript>
<eventField>field1</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>gah</eventField>
<eventSubscript>10</eventSubscript>
</eventReport>
</eventReports>
</event>
</events>
The <eventTarget> element contains information identifying a field in the LFB that is to be monitored for events.
<eventTarget>元素包含识别LFB中要监视事件的字段的信息。
The <eventTarget> element contains one or more <eventField>s each of which MAY be followed by one or more <eventSubscript> elements. Each of these two elements represents the textual equivalent of a path select component of the LFB.
<eventTarget>元素包含一个或多个<eventField>s，每个<eventField>s后面可以跟一个或多个<eventSubscript>元素。这两个元素中的每一个都表示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>元素。在所示示例中，四个LFB组件foo、goo、bar和gah用作<eventField>s。
In the simple case, an <eventField> identifies an atomic component. This is the case illustrated in the event named Foochanged. <eventField> is also used to address complex components such as arrays or structures.
在简单的情况下，<eventField>标识原子组件。这是名为Foochanged的事件中说明的情况<eventField>还用于处理复杂组件，如数组或结构。
The first defined event, Foochanged, demonstrates how a scalar LFB component, foo, could be monitored to trigger an event.
第一个定义的事件Foochanged演示了如何监视标量LFB组件foo以触发事件。
The second event, Goof1changed, demonstrates how a member of the complex structure goo could be monitored to trigger an event.
第二个事件Goof1changed演示了如何监视复杂结构goo的成员以触发事件。
The events named NewbarEntry, Gah11changed, and Gah10field1 represent monitoring of arrays bar and gah in differing details.
名为NewbarEntry、Gah11changed和Gah10field1的事件以不同的细节表示对阵列bar和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>指向结构goo的成员f1。
If an <eventField> identifies an array, then the following rules apply:
如果<eventField>标识数组，则应用以下规则：
o <eventSubscript> elements MUST be present as the next XML element after an <eventField> that identifies an array component. <eventSubscript> MUST NOT occur other than after an array reference, as it is only meaningful in that context.
o <eventSubscript>元素必须作为标识数组组件的<eventField>之后的下一个XML元素出现<eventSubscript>只能在数组引用之后出现，因为它仅在该上下文中有意义。
o An <eventSubscript> contains either:
o <eventSubscript>包含以下内容之一：
* A numeric value to indicate that the event applies to a specific entry (by index) of the array. As an example, event Gah11changed shows how table gah's index 11 is being targeted for monitoring.
* 一个数值，指示事件应用于数组的特定项（按索引）。例如，事件Gah11changed显示了表gah的索引11是如何作为监视目标的。
Or
或
* It is expected that the more common usage is to have the event being defined across all elements of the array (i.e., a wildcard for all indices). In that case, the value of the <eventSubscript> MUST be a name rather than a numeric value. That same name can then be used as the value of <eventSubscript> in <eventReport> elements as described below. An example of a wild card table index is shown in event NewBarentry where the <eventSubscript> value is named _barIndex_
* 更常见的用法是在数组的所有元素中定义事件（即，所有索引的通配符）。在这种情况下，<eventSubscript>的值必须是名称而不是数值。该名称可以用作<eventReport>元素中<eventSubscript>的值，如下所述。在event NewBarentry中显示了通配符表索引的示例，其中<eventSubscript>值命名为_barIndex_
o An <eventField> MAY follow an <eventSubscript> to further refine the path to the target element. (Note: this is in the same spirit as the case where <eventField> is used to further refine <eventField> in the earlier example of a complex structure example of Goof1changed.) The example event Gah10field1 illustrates how the column field1 of table gah is monitored for changes.
o <eventField>可以跟随<eventSubscript>进一步细化到目标元素的路径。（注意：这与前面Goof1changed复杂结构示例中使用<eventField>进一步细化<eventField>的情况相同。）示例事件Gah10field1说明了如何监控表gah的列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定义的<eventReport>元素（如第4.7.6.3节所述）。此名称必须与<eventReport>子句中有效出现的任何组件名称不同。
The event condition element represents a condition that triggers a notification. The list of conditions is:
event condition元素表示触发通知的条件。条件清单如下：
<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.
<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
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.
包含整数。如果它们包含名称，则它们必须是事件中<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的值。对于作用于LFB组件栏（一个数组）的已定义事件NewbarEntry，有两个项被报告，如两个<eventReport>声明所示：
o The first <eventReport> details what new entry was added in the table bar. Recall that _barIndex_ is declared as the event's <eventTarget> <eventSubcript> and that by virtue of using a name instead of a numeric value, the <eventSubcript> is implied to be a wildcard and will carry whatever index of the new entry.
o 第一个<eventReport>详细说明了在表格栏中添加了哪些新条目。回想一下，_barIndex_uu被声明为事件的<eventTarget><eventsubscript>，并且由于使用了名称而不是数值，<eventsubscript>被暗示为通配符，将携带新条目的任何索引。
o The second <eventReport> includes the value of LFB component foo at the time the new entry was created in bar. Reporting foo in this case is provided to demonstrate the flexibility of event reporting.
o 第二个<eventReport>包括在bar中创建新条目时LFB组件foo的值。在这种情况下，提供报告foo是为了证明事件报告的灵活性。
This event reporting structure is designed to allow the LFB designer to specify information that is likely not known a priori by the CE and is likely needed by the CE to process the event. While the structure allows for pointing at large blocks of information (full arrays or complex structures), this is not recommended. Also, the variable reference/subscripting in reporting only captures a small portion of the kinds of related information. Chaining through index fields stored in a table, for example, is not supported. In general, the <eventReports> mechanism is an optimization for cases that have been found to be common, saving the CE from having to query for information it needs to understand the event. It does not represent all possible information needs.
此事件报告结构旨在允许LFB设计器指定CE可能事先不知道且CE可能需要的信息来处理事件。虽然该结构允许指向大型信息块（完整数组或复杂结构），但不建议这样做。此外，报告中的变量引用/订阅仅捕获一小部分相关信息。例如，不支持通过存储在表中的索引字段进行链接。一般来说，<eventReports>机制是对常见案例的一种优化，使CE不必查询了解事件所需的信息。它并不代表所有可能的信息需求。
If any components referenced by the eventReport are optional, then the report MUST use a protocol format that supports optional elements and allows for the non-existence of such elements. Any components that do not exist are not reported.
如果eventReport引用的任何组件都是可选的，则报告必须使用支持可选元素并允许不存在此类元素的协议格式。不报告任何不存在的组件。
The high-level view of the declaration and operation of LFB events is described in Section 3.2.5.
第3.2.5节描述了LFB事件声明和操作的高级视图。
The <eventTarget> provides additional components used in the path to reference the event. The path constitutes the baseID for events, followed by the ID for the specific event, followed by a value for each <eventSubscript> element if it exists in the <eventTarget>.
<eventTarget>提供路径中用于引用事件的其他组件。路径构成事件的baseID，后跟特定事件的ID，如果<eventTarget>中存在每个<eventSubscript>元素，则后跟该元素的值。
The event path will uniquely identify a specific occurrence of the event in the event notification to the CE. In the example provided above, at the end of Section 4.7.6, a notification with path of 7.7 uniquely identifies the event to be that caused by the change of foo; an event with path 7.9.100 uniquely identifies the event to be that caused by a creation of table bar entry with index/subscript 100.
事件路径将在向CE发送的事件通知中唯一标识事件的特定事件。在上面提供的示例中，在第4.7.6节末尾，路径为7.7的通知唯一标识了由foo变更引起的事件；路径为7.9.100的事件唯一标识由创建索引/下标为100的表格条目的事件。
As described in Section 4.8.5, event elements have properties associated with them. These properties include the subscription information indicating whether the CE wishes the FE to generate event reports for the event at all, thresholds for events related to level crossing, and filtering conditions that may reduce the set of event notifications generated by the FE. Details of the filtering conditions that can be applied are given in that section. The filtering conditions allow the FE to suppress floods of events that could result from oscillation around a condition value. For FEs that do not wish to support filtering, the filter properties can be either read-only or not supported.
如第4.8.5节所述，事件元素具有与其关联的属性。这些属性包括指示CE是否希望FE生成事件报告的订阅信息、与平交道口相关的事件阈值以及可能减少FE生成的事件通知集的过滤条件。该部分给出了可应用的过滤条件的详细信息。过滤条件允许FE抑制可能由条件值附近的振荡引起的事件洪流。对于不希望支持筛选的FEs，筛选器属性可以是只读的，也可以是不受支持的。
In addition to identifying the event sources, the CE also uses the event path to activate runtime control of the event via the event properties (defined in Section 4.8.5) utilizing SET-PROP as defined in the ForCES protocol [RFC5810] operation.
除了识别事件源外，CE还使用事件路径通过事件属性（定义见第4.8.5节）激活事件的运行时控制，该属性使用ForCES协议[RFC5810]操作中定义的SET-PROP。
To activate event generation on the FE, a SET-PROP message referencing the event and registration property of the event is issued to the FE by the CE with any prefix of the path of the event. So, for an event defined on the example table bar, a SET-PROP with a path of 7.9 will subscribe the CE to all occurrences of that event on any entry of the table. This is particularly useful for the <eventCreated/> and <eventDestroyed/> conditions on tables. Events using those conditions will generally be defined with a field/ subscript sequence that identifies an array and ends with an <eventSubscript> element. Thus, the event notification will indicate which array entry has been created or destroyed. A typical subscriber will subscribe for the array, as opposed to a specific entry in an array, so it will use a shorter path.
要激活FE上的事件生成，CE将引用事件和事件注册属性的SET-PROP消息以事件路径的任何前缀发送给FE。因此，对于示例表栏上定义的事件，路径为7.9的SET-PROP将向CE订阅该事件在表的任何条目上的所有事件。这对于表上的<eventCreated/>和<eventdestromed/>条件特别有用。使用这些条件的事件通常使用一个字段/下标序列来定义，该序列标识一个数组，并以<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>元素提供非结构化文本（XML意义上）来解释LFB对人类用户的作用。
Components of LFBs have properties that are important to the CE. The most important property is the existence / readability / writeability of the element. Depending on the type of the component, other information may be of importance.
LFB的组件具有对CE非常重要的特性。最重要的属性是元素的存在性/可读性/可写性。根据部件的类型，其他信息可能很重要。
The model provides the definition of the structure of property information. There is a base class of property information. For the array, alias, and event components, there are subclasses of property information providing additional fields. This information is accessed by the CE (and updated where applicable) via the ForCES protocol. While some property information is writeable, there is no mechanism currently provided for checking the properties of a property element. Writeability can only be checked by attempting to modify the value.
该模型提供了属性信息结构的定义。有一个属性信息的基类。对于数组、别名和事件组件，有属性信息的子类提供附加字段。该信息由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>
<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>
<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>
<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类定义。
<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>
<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.
事件的属性添加三个（通常）可写字段。一个是订阅字段。0表示未生成通知。任何非零值（通常使用1）表示生成通知。滞后场用于抑制条件值周围振荡通知的生成，如下所述（第4.8.5.2节）。阈值字段用于<eventGreaterThan/>和<eventLessThan/>条件。它指示要与事件目标进行比较的值。使用属性允许CE设置感兴趣的级别。不支持设置事件阈值的FEs将使此字段为只读。
<dataTypeDef>
<name>eventElementProperties</name>
<synopsis>event Element Properties definition</synopsis>
<struct>
<derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2">
<name>registration</name>
<synopsis>
has the CE registered to be notified of this event
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>threshold</name>
<synopsis> comparison value for level crossing events
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>eventHysteresis</name>
<synopsis> region to suppress event recurrence notices
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name>eventCount</name>
<synopsis> number of occurrences to suppress
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="6">
<name>eventInterval</name>
<synopsis> time interval in ms between notifications
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<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和EventHi滞。将条件变量设置为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.
条件交互的一个示例是eventCount属性设置为5且eventInterval属性设置为500毫秒的事件。假设FE检测到此事件的突发事件。第一次出现将导致向CE发送通知。然后，如果快速检测到四次以上的事件（少于0.5秒），则不会导致通知。如果检测到另外两个事件，则第二个事件将导致通知。或者，如果自通知以来已超过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
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
<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:
<variance>元素是一个数值。当支持滞后时，FE必须跟踪元素的值，并确保条件至少因事件属性的滞后而变得不真实。具体而言，如果滞后为V，则：
o For an <eventChanged/> condition, if the last notification was for value X, then the <changed/> notification MUST NOT be generated until the value reaches X +/- V.
o 对于<eventChanged/>条件，如果最后一次通知是针对值X，则在值达到X+/-V之前，不得生成<changed/>通知。
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.
别名的属性添加三个（通常）可写字段。这些组合用于标识主题别名所指的目标组件。
<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>
<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>
<?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:key name="LFBClassDef">
<xsd:selector xpath="lfb:LFBClassDefs/lfb:LFBClassDef"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
</xsd:element>
<xsd:complexType name="loadType">
<xsd:attribute name="library" type="xsd:Name" use="required"/>
<xsd:attribute name="location" type="xsd:anyURI" use="optional"/>
</xsd:complexType>
<xsd:complexType name="frameDefsType">
<xsd:sequence>
<xsd:element name="frameDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="dataTypeDefsType">
<xsd:sequence>
<xsd:element name="dataTypeDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<!--
Predefined (built-in) atomic data-types are:
char, uchar, int16, uint16, int32, uint32, int64, uint64,
string[N], string, byte[N], boolean, octetstring[N],
float32, float64
-->
<xsd:group name="typeDeclarationGroup">
<xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/>
<xsd:element name="array" type="arrayType"/>
<xsd:element name="struct" type="structType"/>
<xsd:element name="union" type="structType"/>
<xsd:element name="alias" type="typeRefNMTOKEN"/>
</xsd:choice>
</xsd:group>
<xsd:simpleType name="typeRefNMTOKEN">
<xsd:restriction base="xsd:token">
<xsd:pattern value="\c+"/>
<xsd:pattern value="string\[\d+\]"/>
<xsd:pattern value="byte\[\d+\]"/>
<xsd:pattern value="octetstring\[\d+\]"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="atomicType">
<xsd:sequence>
<xsd:element name="baseType" type="typeRefNMTOKEN"/>
<xsd:element name="rangeRestriction"
type="rangeRestrictionType" minOccurs="0"/>
<xsd:element name="specialValues" type="specialValuesType"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="rangeRestrictionType">
<xsd:sequence>
<xsd:element name="allowedRange" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="min" type="xsd:integer"
use="required"/>
<xsd:attribute name="max" type="xsd:integer"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="specialValuesType">
<xsd:sequence>
<xsd:element name="specialValue" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
</xsd:sequence>
<xsd:attribute name="value" type="xsd:token"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="arrayType">
<xsd:sequence>
<xsd:element name="union" type="structType"/>
<xsd:element name="alias" type="typeRefNMTOKEN"/>
</xsd:choice>
</xsd:group>
<xsd:simpleType name="typeRefNMTOKEN">
<xsd:restriction base="xsd:token">
<xsd:pattern value="\c+"/>
<xsd:pattern value="string\[\d+\]"/>
<xsd:pattern value="byte\[\d+\]"/>
<xsd:pattern value="octetstring\[\d+\]"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="atomicType">
<xsd:sequence>
<xsd:element name="baseType" type="typeRefNMTOKEN"/>
<xsd:element name="rangeRestriction"
type="rangeRestrictionType" minOccurs="0"/>
<xsd:element name="specialValues" type="specialValuesType"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="rangeRestrictionType">
<xsd:sequence>
<xsd:element name="allowedRange" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="min" type="xsd:integer"
use="required"/>
<xsd:attribute name="max" type="xsd:integer"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="specialValuesType">
<xsd:sequence>
<xsd:element name="specialValue" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
</xsd:sequence>
<xsd:attribute name="value" type="xsd:token"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="arrayType">
<xsd:sequence>
<xsd:group ref="typeDeclarationGroup"/>
<xsd:element name="contentKey" minOccurs="0"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="contentKeyField" maxOccurs="unbounded"
type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="contentKeyID" use="required"
type="xsd:integer"/>
</xsd:complexType>
<!--declare keys to have unique IDs -->
<xsd:key name="contentKeyID">
<xsd:selector xpath="lfb:contentKey"/>
<xsd:field xpath="@contentKeyID"/>
</xsd:key>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="type" use="optional"
default="variable-size">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="fixed-size"/>
<xsd:enumeration value="variable-size"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="length" type="xsd:integer" use="optional"/>
<xsd:attribute name="maxLength" type="xsd:integer"
use="optional"/>
</xsd:complexType>
<xsd:complexType name="structType">
<xsd:sequence>
<xsd:element name="derivedFrom" type="typeRefNMTOKEN"
minOccurs="0"/>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<xsd:attribute name="componentID" use="required"
type="xsd:unsignedInt"/>
</xsd:complexType>
<!-- key declaration to make componentIDs unique in a struct
<xsd:group ref="typeDeclarationGroup"/>
<xsd:element name="contentKey" minOccurs="0"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="contentKeyField" maxOccurs="unbounded"
type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="contentKeyID" use="required"
type="xsd:integer"/>
</xsd:complexType>
<!--declare keys to have unique IDs -->
<xsd:key name="contentKeyID">
<xsd:selector xpath="lfb:contentKey"/>
<xsd:field xpath="@contentKeyID"/>
</xsd:key>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="type" use="optional"
default="variable-size">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="fixed-size"/>
<xsd:enumeration value="variable-size"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="length" type="xsd:integer" use="optional"/>
<xsd:attribute name="maxLength" type="xsd:integer"
use="optional"/>
</xsd:complexType>
<xsd:complexType name="structType">
<xsd:sequence>
<xsd:element name="derivedFrom" type="typeRefNMTOKEN"
minOccurs="0"/>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<xsd:attribute name="componentID" use="required"
type="xsd:unsignedInt"/>
</xsd:complexType>
<!-- key declaration to make componentIDs unique in a struct
-->
<xsd:key name="structComponentID">
<xsd:selector xpath="lfb:component"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="metadataDefsType">
<xsd:sequence>
<xsd:element name="metadataDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="metadataID" type="xsd:integer"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="LFBClassDefsType">
<xsd:sequence>
<xsd:element name="LFBClassDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="version" type="versionType"/>
<xsd:element name="derivedFrom" type="xsd:NMTOKEN"
minOccurs="0"/>
<xsd:element name="inputPorts" type="inputPortsType"
minOccurs="0"/>
<xsd:element name="outputPorts" type="outputPortsType"
minOccurs="0"/>
<xsd:element name="components" type="LFBComponentsType"
minOccurs="0"/>
<xsd:element name="capabilities"
type="LFBCapabilitiesType" minOccurs="0"/>
<xsd:element name="events"
type="eventsType" minOccurs="0"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
-->
<xsd:key name="structComponentID">
<xsd:selector xpath="lfb:component"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="metadataDefsType">
<xsd:sequence>
<xsd:element name="metadataDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="metadataID" type="xsd:integer"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="LFBClassDefsType">
<xsd:sequence>
<xsd:element name="LFBClassDef" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="version" type="versionType"/>
<xsd:element name="derivedFrom" type="xsd:NMTOKEN"
minOccurs="0"/>
<xsd:element name="inputPorts" type="inputPortsType"
minOccurs="0"/>
<xsd:element name="outputPorts" type="outputPortsType"
minOccurs="0"/>
<xsd:element name="components" type="LFBComponentsType"
minOccurs="0"/>
<xsd:element name="capabilities"
type="LFBCapabilitiesType" minOccurs="0"/>
<xsd:element name="events"
type="eventsType" minOccurs="0"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="LFBClassID" use="required"
type="xsd:unsignedInt"/>
</xsd:complexType>
<!-- Key constraint to ensure unique attribute names within
a class:
-->
<xsd:key name="components">
<xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="capabilities">
<xsd:selector xpath="lfb:capabilities/lfb:capability"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="componentIDs">
<xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
<xsd:key name="capabilityIDs">
<xsd:selector xpath="lfb:capabilities/lfb:capability"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="versionType">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="[1-9][0-9]*\.([1-9][0-9]*|0)"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="inputPortsType">
<xsd:sequence>
<xsd:element name="inputPort" type="inputPortType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="inputPortType">
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="expectation" type="portExpectationType"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="group" type="xsd:boolean" use="optional"
default="0"/>
</xsd:complexType>
<xsd:complexType name="portExpectationType">
<xsd:sequence>
<xsd:attribute name="LFBClassID" use="required"
type="xsd:unsignedInt"/>
</xsd:complexType>
<!-- Key constraint to ensure unique attribute names within
a class:
-->
<xsd:key name="components">
<xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="capabilities">
<xsd:selector xpath="lfb:capabilities/lfb:capability"/>
<xsd:field xpath="lfb:name"/>
</xsd:key>
<xsd:key name="componentIDs">
<xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
<xsd:key name="capabilityIDs">
<xsd:selector xpath="lfb:capabilities/lfb:capability"/>
<xsd:field xpath="@componentID"/>
</xsd:key>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="versionType">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="[1-9][0-9]*\.([1-9][0-9]*|0)"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="inputPortsType">
<xsd:sequence>
<xsd:element name="inputPort" type="inputPortType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="inputPortType">
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="expectation" type="portExpectationType"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="group" type="xsd:boolean" use="optional"
default="0"/>
</xsd:complexType>
<xsd:complexType name="portExpectationType">
<xsd:sequence>
<xsd:element name="frameExpected" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<!-- ref must refer to a name of a defined frame type -->
<xsd:element name="ref" type="xsd:string"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="metadataExpected" minOccurs="0">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="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:element name="ref" type="metadataInputRefType"/>
<xsd:element name="one-of"
type="metadataInputChoiceType"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="metadataInputChoiceType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="xsd:NMTOKEN"/>
<xsd:element name="one-of" type="metadataInputChoiceType"/>
<xsd:element name="metadataSet" type="metadataInputSetType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataInputSetType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="metadataInputRefType"/>
<xsd:element name="one-of" type="metadataInputChoiceType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataInputRefType">
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="dependency" use="optional"
default="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="required"/>
<xsd:enumeration value="optional"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="defaultValue" type="xsd:token"
use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="outputPortsType">
<xsd:sequence>
<xsd:element name="outputPort" type="outputPortType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="outputPortType">
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="product" type="portProductType"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="group" type="xsd:boolean" use="optional"
default="0"/>
</xsd:complexType>
<xsd:complexType name="portProductType">
<xsd:sequence>
<xsd:element name="frameProduced">
<xsd:complexType>
<xsd:sequence>
<!-- ref must refer to a name of a defined frame type
-->
<xsd:element name="ref" type="xsd:NMTOKEN"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="metadataProduced" minOccurs="0">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata
-->
<xsd:element name="ref" type="metadataOutputRefType"/>
<xsd:element name="one-of"
type="metadataOutputChoiceType"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="metadataOutputChoiceType">
</xsd:attribute>
<xsd:attribute name="defaultValue" type="xsd:token"
use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="outputPortsType">
<xsd:sequence>
<xsd:element name="outputPort" type="outputPortType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="outputPortType">
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="product" type="portProductType"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="group" type="xsd:boolean" use="optional"
default="0"/>
</xsd:complexType>
<xsd:complexType name="portProductType">
<xsd:sequence>
<xsd:element name="frameProduced">
<xsd:complexType>
<xsd:sequence>
<!-- ref must refer to a name of a defined frame type
-->
<xsd:element name="ref" type="xsd:NMTOKEN"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="metadataProduced" minOccurs="0">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata
-->
<xsd:element name="ref" type="metadataOutputRefType"/>
<xsd:element name="one-of"
type="metadataOutputChoiceType"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="metadataOutputChoiceType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="xsd:NMTOKEN"/>
<xsd:element name="one-of" type="metadataOutputChoiceType"/>
<xsd:element name="metadataSet" type="metadataOutputSetType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataOutputSetType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="metadataOutputRefType"/>
<xsd:element name="one-of" type="metadataOutputChoiceType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataOutputRefType">
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="availability" use="optional"
default="unconditional">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="unconditional"/>
<xsd:enumeration value="conditional"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="LFBComponentsType">
<xsd:sequence>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
<xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="access" use="optional"
default="read-write">
<xsd:simpleType>
<xsd:list itemType="accessModeType"/>
</xsd:simpleType>
</xsd:attribute>
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="xsd:NMTOKEN"/>
<xsd:element name="one-of" type="metadataOutputChoiceType"/>
<xsd:element name="metadataSet" type="metadataOutputSetType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataOutputSetType">
<xsd:choice minOccurs="2" maxOccurs="unbounded">
<!-- ref must refer to a name of a defined metadata -->
<xsd:element name="ref" type="metadataOutputRefType"/>
<xsd:element name="one-of" type="metadataOutputChoiceType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="metadataOutputRefType">
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="availability" use="optional"
default="unconditional">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="unconditional"/>
<xsd:enumeration value="conditional"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="LFBComponentsType">
<xsd:sequence>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
<xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="access" use="optional"
default="read-write">
<xsd:simpleType>
<xsd:list itemType="accessModeType"/>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="componentID" use="required"
type="xsd:unsignedInt"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="accessModeType">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="read-only"/>
<xsd:enumeration value="read-write"/>
<xsd:enumeration value="write-only"/>
<xsd:enumeration value="read-reset"/>
<xsd:enumeration value="trigger-only"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="LFBCapabilitiesType">
<xsd:sequence>
<xsd:element name="capability" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<xsd:attribute name="componentID" use="required"
type="xsd:integer"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="eventsType">
<xsd:sequence>
<xsd:element name="event" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="eventTarget" type="eventPathType"/>
<xsd:element ref="eventCondition"/>
<xsd:element name="eventReports" type="eventReportsType"
minOccurs="0"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="eventID" use="required"
type="xsd:integer"/>
</xsd:complexType>
<xsd:attribute name="componentID" use="required"
type="xsd:unsignedInt"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="accessModeType">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="read-only"/>
<xsd:enumeration value="read-write"/>
<xsd:enumeration value="write-only"/>
<xsd:enumeration value="read-reset"/>
<xsd:enumeration value="trigger-only"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="LFBCapabilitiesType">
<xsd:sequence>
<xsd:element name="capability" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<xsd:attribute name="componentID" use="required"
type="xsd:integer"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="eventsType">
<xsd:sequence>
<xsd:element name="event" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element name="eventTarget" type="eventPathType"/>
<xsd:element ref="eventCondition"/>
<xsd:element name="eventReports" type="eventReportsType"
minOccurs="0"/>
<xsd:element ref="description" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="eventID" use="required"
type="xsd:integer"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="baseID" type="xsd:integer"
use="optional"/>
</xsd:complexType>
<!-- the substitution group for the event conditions -->
<xsd:element name="eventCondition" abstract="true"/>
<xsd:element name="eventCreated"
substitutionGroup="eventCondition"/>
<xsd:element name="eventDeleted"
substitutionGroup="eventCondition"/>
<xsd:element name="eventChanged"
substitutionGroup="eventCondition"/>
<xsd:element name="eventGreaterThan"
substitutionGroup="eventCondition"/>
<xsd:element name="eventLessThan"
substitutionGroup="eventCondition"/>
<xsd:complexType name="eventPathType">
<xsd:sequence>
<xsd:element ref="eventPathPart" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<!-- the substitution group for the event path parts -->
<xsd:element name="eventPathPart" type="xsd:string"
abstract="true"/>
<xsd:element name="eventField" type="xsd:string"
substitutionGroup="eventPathPart"/>
<xsd:element name="eventSubscript" type="xsd:string"
substitutionGroup="eventPathPart"/>
<xsd:complexType name="eventReportsType">
<xsd:sequence>
<xsd:element name="eventReport" type="eventPathType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="booleanType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="0"/>
<xsd:enumeration value="1"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="baseID" type="xsd:integer"
use="optional"/>
</xsd:complexType>
<!-- the substitution group for the event conditions -->
<xsd:element name="eventCondition" abstract="true"/>
<xsd:element name="eventCreated"
substitutionGroup="eventCondition"/>
<xsd:element name="eventDeleted"
substitutionGroup="eventCondition"/>
<xsd:element name="eventChanged"
substitutionGroup="eventCondition"/>
<xsd:element name="eventGreaterThan"
substitutionGroup="eventCondition"/>
<xsd:element name="eventLessThan"
substitutionGroup="eventCondition"/>
<xsd:complexType name="eventPathType">
<xsd:sequence>
<xsd:element ref="eventPathPart" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<!-- the substitution group for the event path parts -->
<xsd:element name="eventPathPart" type="xsd:string"
abstract="true"/>
<xsd:element name="eventField" type="xsd:string"
substitutionGroup="eventPathPart"/>
<xsd:element name="eventSubscript" type="xsd:string"
substitutionGroup="eventPathPart"/>
<xsd:complexType name="eventReportsType">
<xsd:sequence>
<xsd:element name="eventReport" type="eventPathType"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="booleanType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="0"/>
<xsd:enumeration value="1"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
A ForCES forwarding element handles traffic on behalf of a ForCES control element. While the standards will describe the protocol and mechanisms for this control, different implementations and different instances will have different capabilities. The CE MUST be able to determine what each instance it is responsible for is actually capable of doing. As stated previously, this is an approximation. The CE is expected to be prepared to cope with errors in requests and variations in detail not captured by the capabilities information about an FE.
ForCES转发元素代表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。此类的LFBClassID为1。FE中只会存在此类的一个实例，协议中该实例的实例ID为1。因此，通过引用class:1、instance: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是为该类保留的。该类也只有一个实例。该类的详细信息在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>
<?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>
<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>
</component>
<component componentID="3">
<name>LFBVersion</name>
<synopsis>
The version of the LFB class used
by this FE.
</synopsis>
<typeRef>string</typeRef>
</component>
<component componentID="4">
<name>LFBOccurrenceLimit</name>
<synopsis>
the upper limit of instances of LFBs of this class
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<!-- For each port group, how many ports can exist
-->
<component componentID="5">
<name>PortGroupLimits</name>
<synopsis>Table of Port Group Limits</synopsis>
<optional/>
<array type="variable-size">
<typeRef>PortGroupLimitType</typeRef>
</array>
</component>
<!-- for the named LFB Class, the LFB Classes it may follow -->
<component componentID="6">
<name>CanOccurAfters</name>
<synopsis>
List of LFB classes that this LFB class can follow
</synopsis>
<optional/>
<array type="variable-size">
<typeRef>LFBAdjacencyLimitType</typeRef>
</array>
</component>
<!-- for the named LFB Class, the LFB Classes that may follow it
-->
<component componentID="7">
<name>CanOccurBefores</name>
<synopsis>
List of LFB classes that can follow this LFB class
</synopsis>
<optional/>
<array type="variable-size">
<typeRef>LFBAdjacencyLimitType</typeRef>
</array>
</component>
<component componentID="8">
<name>UseableParentLFBClasses</name>
<synopsis>
List of LFB classes from which this class has
inherited, and which the FE is willing to allow
for references to instances of this class.
</synopsis>
<optional/>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>FEStateValues</name>
<synopsis>The possible values of status</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>AdminDisable</name>
<synopsis>
FE is administratively disabled
</synopsis>
</specialValue>
<specialValue value="1">
<name>OperDisable</name>
<synopsis>FE is operatively disabled</synopsis>
</specialValue>
<specialValue value="2">
<name>OperEnable</name>
<synopsis>FE is operating</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FEConfiguredNeighborType</name>
<synopsis>Details of the FE's Neighbor</synopsis>
<struct>
<component componentID="1">
<name>NeighborID</name>
<synopsis>Neighbors FEID</synopsis>
<typeRef>uint32</typeRef>
<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>
</component>
<component componentID="2">
<name>InterfaceToNeighbor</name>
<synopsis>
FE's interface that connects to this neighbor
</synopsis>
<optional/>
<typeRef>string</typeRef>
</component>
<component componentID="3">
<name>NeighborInterface</name>
<synopsis>
The name of the interface on the neighbor to
which this FE is adjacent. This is required
in case two FEs are adjacent on more than
one interface.
</synopsis>
<optional/>
<typeRef>string</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>LFBSelectorType</name>
<synopsis>
Unique identification of an LFB class-instance
</synopsis>
<struct>
<component componentID="1">
<name>LFBClassID</name>
<synopsis>LFB Class Identifier</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>LFBInstanceID</name>
<synopsis>LFB Instance ID</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>LFBLinkType</name>
<synopsis>
Link between two LFB instances of topology
</synopsis>
<struct>
<component componentID="1">
<name>FromLFBID</name>
<synopsis>LFB src</synopsis>
<typeRef>LFBSelectorType</typeRef>
</component>
<component componentID="2">
<name>FromPortGroup</name>
<synopsis>src port group</synopsis>
<typeRef>string</typeRef>
</component>
<component componentID="3">
<name>FromPortIndex</name>
<synopsis>src port index</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>ToLFBID</name>
<synopsis>dst LFBID</synopsis>
<typeRef>LFBSelectorType</typeRef>
</component>
<component componentID="5">
<name>ToPortGroup</name>
<synopsis>dst port group</synopsis>
<typeRef>string</typeRef>
</component>
<component componentID="6">
<name>ToPortIndex</name>
<synopsis>dst port index</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="1">
<name>FEObject</name>
<synopsis>Core LFB: FE Object</synopsis>
<version>1.0</version>
<components>
<component access="read-write" componentID="1">
<name>LFBTopology</name>
<synopsis>the table of known Topologies</synopsis>
<array type="variable-size">
<typeRef>LFBLinkType</typeRef>
</array>
</component>
<component access="read-write" componentID="2">
<name>LFBSelectors</name>
<synopsis>
table of known active LFB classes and
<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>
instances
</synopsis>
<array type="variable-size">
<typeRef>LFBSelectorType</typeRef>
</array>
</component>
<component access="read-write" componentID="3">
<name>FEName</name>
<synopsis>name of this FE</synopsis>
<typeRef>string[40]</typeRef>
</component>
<component access="read-write" componentID="4">
<name>FEID</name>
<synopsis>ID of this FE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component access="read-only" componentID="5">
<name>FEVendor</name>
<synopsis>vendor of this FE</synopsis>
<typeRef>string[40]</typeRef>
</component>
<component access="read-only" componentID="6">
<name>FEModel</name>
<synopsis>model of this FE</synopsis>
<typeRef>string[40]</typeRef>
</component>
<component access="read-only" componentID="7">
<name>FEState</name>
<synopsis>State of this FE</synopsis>
<typeRef>FEStateValues</typeRef>
</component>
<component access="read-write" componentID="8">
<name>FENeighbors</name>
<synopsis>table of known neighbors</synopsis>
<optional/>
<array type="variable-size">
<typeRef>FEConfiguredNeighborType</typeRef>
</array>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>ModifiableLFBTopology</name>
<synopsis>
Whether Modifiable LFB is supported
</synopsis>
<optional/>
<typeRef>boolean</typeRef>
</capability>
<capability componentID="31">
<name>SupportedLFBs</name>
<synopsis>List of all supported LFBs</synopsis>
<optional/>
<array type="variable-size">
<typeRef>SupportedLFBType</typeRef>
</array>
</capability>
</capabilities>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
</capability>
<capability componentID="31">
<name>SupportedLFBs</name>
<synopsis>List of all supported LFBs</synopsis>
<optional/>
<array type="variable-size">
<typeRef>SupportedLFBType</typeRef>
</array>
</capability>
</capabilities>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
The FE capability information is contained in the capabilities element of the class definition. As described elsewhere, capability information is always considered to be read-only.
FE能力信息包含在类定义的capabilities元素中。如其他地方所述，能力信息始终被认为是只读的。
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.
当前定义的功能是可修改的LFB拓扑和受支持的LFB。有关支持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更改。如果缺少该组件，则假定默认值为true，并且CE假定LFB拓扑可能会更改。如果该值存在并设置为false，则FE的LFB拓扑是固定的。如果拓扑是固定的，则可以省略SupportedLFBs元素，CE根据LFB拓扑信息推断支持的LFB列表。如果在ModifiableLFB拓扑为false时提供了受支持的LFB列表，则应忽略CanOccurBefore和CANoccurRafter信息。
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类的信息。数组结构类型定义为SupportedLFB类型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
SupportedLFBs数组中的每个条目都描述FE支持的LFB类。除了指示FE支持该类之外，具有可修改LFB拓扑的FEs还应包括信息
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.
关于指定类的LFB如何连接到其他LFB。该信息应描述指定LFB类在LFB拓扑中可能成功或领先的LFB类。FE应包括关于哪些端口组可连接到给定相邻LFB类的信息。如果省略端口组信息，则假定可以使用所有端口组。如果实施者得出结论，认为实际约束会使信息对CE产生误导，则可以省略关于LFB的可接受顺序和连接的能力信息。
This component has as its value the name of the LFB class being described.
该组件的值为所描述的LFB类的名称。
LFBClassID is the numeric ID of the LFB class being described. While conceptually redundant with the LFB name, both are included for clarity and to allow consistency checking.
LFBClassID是正在描述的LFB类的数字ID。虽然LFB名称在概念上是多余的，但为了清晰起见，并允许进行一致性检查，两者都包括在内。
LFBVersion is the version string specifying the LFB class version supported by this FE. As described above in versioning, an FE can support only a single version of a given LFB class.
LFBVersion是指定此FE支持的LFB类版本的版本字符串。如上版本控制中所述，FE只能支持给定LFB类的单个版本。
This component, if present, indicates the largest number of instances of this LFB class the FE can support. For FEs that do not have the capability to create or destroy LFB instances, this can either be omitted or be the same as the number of LFB instances of this class contained in the LFB list attribute.
此组件（如果存在）表示FE可以支持的LFB类实例的最大数量。对于不具备创建或销毁LFB实例能力的FEs，可以忽略此项，也可以与LFB list属性中包含的此类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.
canoccrafters组件是一个数组，其中包含所描述的类可能出现的LFB列表。数组项在LFBADjacyClimitType数据类型定义中定义。
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.
数组条目描述了所描述的LFB类（此处称为SupportedLFB）的允许定位。具体地说，每个数组条目命名一个LFB，该LFB在拓扑上可以位于该LFB类之前。也就是说，SupportedLFB可以有一个输入端口连接到CanOccurAfters阵列中出现的LFB的输出端口。SupportedLFB可以遵循的LFB类由CanOccurAfters数组项的NeightrFB组件（LFBadjacyClimitType数据类型定义的）标识。如果该邻居只能连接到一组特定的输入端口组，则包括viaPort组件。这个组件是一个数组，支持的LFB的每个输入端口组有一个条目，可以连接到相邻的RLFB的输出端口。
(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.)
（例如，在SupportedLFB条目中，CanOccurAfters数组的每个数组条目必须具有唯一的邻域FB，并且在每个这样的数组条目中，每个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.
数组条目列出了拓扑中受支持的LFB可能位于其前面的LFB类。在该组件中，数组值的viaPort组件中的条目表示可能连接到相邻RLFB的SupportedLFB的输出端口组。与CanocCrafters一样，如果多个输出端口可以合法地连接到给定的NeighborLFB类，则viaPort可能有多个条目。
(And a similar set of uniqueness constraints applies to the CanOccurBefore clauses, even though an LFB may occur both in CanOccurAfter and CanOccurBefore.)
（一组类似的唯一性约束适用于CanOccurBefore子句，即使LFB可能同时出现在CANOCCURAFER和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
UsableParentLFBClasses数组（如果存在）用于保存父LFB类ID的列表。列表中的所有条目必须是所描述的SupportedLFB类所属的类的ID
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.
继承（直接或通过中间父级。）（如果FE在此列表中包含不正确的值，则CE可能会进行不正确的操作，并且操作可能会失败。）此外，FE通过在最后一个列表中包含给定类，向CE指示给定父类可用于操作此受支持LFB类的实例。
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类共享一个父类，并且如果该父类在两个特定LFB类的UsableParentLFBClass中列出，则这两个类的所有实例（或任何实例，如果多个类列出了公共父类）都必须使用不同的实例。这允许FE确定CE操纵操作想要哪个LFB实例，即使在使用父类时也是如此。
While it would be desirable to include class-capability-level information, this is not included in the model. While such information belongs in the FE Object in the supported class table, the contents of that information would be class specific. The currently expected encoding structures for transferring information between the CE and FE are such that allowing completely unspecified information would be likely to induce parse errors. We could specify that the information be encoded in an octetstring, but then we would have to define the internal format of that octet string.
虽然需要包含类能力级别信息，但模型中不包含这一信息。虽然此类信息属于受支持类表中的FE对象，但该信息的内容是特定于类的。当前预期用于在CE和FE之间传输信息的编码结构是这样的，允许完全未指定的信息可能会导致解析错误。我们可以指定将信息编码为八位字节字符串，但随后必须定义该八位字节字符串的内部格式。
As there also are not currently any defined LFB class-level capabilities that the FE needs to report, this information is not present now, but may be added in a future version of the FE object. (This is an example of a case where versioning, rather than inheritance, would be needed, since the FE object must have class ID 1 and instance ID 1 so that the protocol behavior can start by finding this object.)
由于FE目前还不需要报告任何已定义的LFB类级功能，因此该信息现在不存在，但可能会添加到FE对象的未来版本中。（这是一个需要版本控制而不是继承的示例，因为FE对象必须具有类ID 1和实例ID 1，以便协议行为可以从查找该对象开始。）
The <components> element is included if the class definition contains the definition of the components of the FE object that are not considered "capabilities". Some of these components are writeable and some are read-only, which is determinable by examining the property information of the components.
如果类定义包含FE对象中不被视为“能力”的组件的定义，则包含<components>元素。这些组件中有些是可写的，有些是只读的，这可以通过检查组件的属性信息来确定。
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控制从Operable到AdminDisable的转换。有关详细信息，请参阅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.
LFB选择器组件是关于当前可通过FE中的力访问的LFB的信息数组。LFB信息的结构由LFBSelectorType数据类型定义。
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.
可选LFB拓扑组件包含FE内每个LFB间链路的信息，其中每个链路在LFBLinkType dataTypeDef中描述。LFBLinkType组件包含足够的信息来精确标识链接的端点。FromLFBID和ToLFBID组件指定链接两端的LFB实例，并且必须引用LFB实例表中的LFB。FROMPORTGOUP和TOPORTGOUP必须标识在FromLFBID和ToLFBID标识的LFB实例的LFB类中定义的输出和输入端口组。FromPortIndex和ToporIndex组件从该链接连接的端口组中选择条目。所有链接都由FromLFBID、FROMPORTGOUP和FromPortIndex字段唯一标识。多个链路可能具有相同的ToLFBID、TOPORTGOUP和ToPortIndex，因为此模型支持LFB间链路的扇入，但不支持扇出。
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之间手动配置的邻接的信息数组。数组的内容由FeConfiguredNeightType数据类型定义。
This array is intended to capture information that may be configured on the FE and is needed by the CE, where one array entry corresponds to each configured neighbor. Note that this array is not intended to represent the results of any discovery protocols, as those will have their own LFBs. This component is optional.
此阵列旨在捕获FE上可能配置的、CE需要的信息，其中一个阵列条目对应于每个配置的邻居。请注意，此数组并不表示任何发现协议的结果，因为这些协议将有自己的LFB。此组件是可选的。
While there may be many ways to configure neighbors, the FE-ID is the best way for the CE to correlate entities. And the interface identifier (name string) is the best correlator. The CE will be able to determine the IP address and media-level information about the neighbor from the neighbor directly. Omitting that information from this table avoids the risk of incorrect double configuration.
虽然可能有许多方法可以配置邻居，但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.
这标识了邻居上的接口，通过该接口可以访问邻居。当只有相邻的一侧具有配置信息或两个FE在多个接口上相邻时，需要进行接口标识。
This section describes how the proposed FE model meets the requirements outlined in Section 5 of RFC 3654 [RFC3654]. The requirements can be separated into general requirements (Section 5, 5.1 - 5.4) and the specification of the minimal set of logical functions that the FE model must support (Section 5.5).
本节描述了拟定FE模型如何满足RFC 3654[RFC3654]第5节中概述的要求。需求可分为一般需求（第5节，5.1-5.4）和FE模型必须支持的最小逻辑功能集规范（第5.5节）。
The general requirement on the FE model is that it be able to express the logical packet processing capability of the FE, through both a capability and a state model. In addition, the FE model is expected to allow flexible implementations and be extensible to allow defining new logical functions.
FE模型的一般要求是，它能够通过能力和状态模型来表示FE的逻辑数据包处理能力。此外，FE模型预计将允许灵活的实现，并可扩展以允许定义新的逻辑功能。
A major component of the proposed FE model is the Logical Functional Block (LFB) model. Each distinct logical function in an FE is modeled as an LFB. Operational parameters of the LFB that must be visible to the CE are conceptualized as LFB components. These components express the capability of the FE and support flexible implementations by allowing an FE to specify which optional features are supported. The components also indicate whether they are configurable by the CE for an LFB class. Configurable components provide the CE some flexibility in specifying the behavior of an LFB. When multiple LFBs belonging to the same LFB class are instantiated on an FE, each of those LFBs could be configured with different component settings. By querying the settings of the components for an instantiated LFB, the CE can determine the state of that LFB.
提出的有限元模型的一个主要组成部分是逻辑功能块（LFB）模型。FE中每个不同的逻辑函数都被建模为LFB。必须对CE可见的LFB操作参数被概念化为LFB组件。这些组件表示FE的能力，并通过允许FE指定支持哪些可选功能来支持灵活的实现。这些组件还指示CE是否可以为LFB类配置它们。可配置组件为CE提供了指定LFB行为的一些灵活性。当在FE上实例化属于同一LFB类的多个LFB时，这些LFB中的每一个都可以配置不同的组件设置。通过查询实例化LFB的组件设置，CE可以确定该LFB的状态。
Instantiated LFBs are interconnected in a directed graph that describes the ordering of the functions within an FE. This directed graph is described by the topology model. The combination of the components of the instantiated LFBs and the topology describe the packet processing functions available on the FE (current state).
实例化的LFB在一个有向图中相互连接，该图描述FE中函数的顺序。该有向图由拓扑模型描述。实例化LFB的组件和拓扑的组合描述FE（当前状态）上可用的分组处理功能。
Another key component of the FE model is the FE components. The FE components are used mainly to describe the capabilities of the FE, but they also convey information about the FE state.
有限元模型的另一个关键组件是有限元组件。FE组件主要用于描述FE的能力，但它们也传递有关FE状态的信息。
The FE model includes only the definition of the FE Object LFB itself. Meeting the full set of working group requirements requires other LFBs. The class definitions for those LFBs will be provided in other documents.
FE模型仅包含FE对象LFB本身的定义。满足全套工作组要求需要其他LFB。这些LFB的类别定义将在其他文件中提供。
The actual model of the forwarding plane in a given NE is something the CE must learn and control by communicating with the FEs (or by other means). Most of this communication will happen in the post-association phase using the ForCES protocol. The following types of information must be exchanged between CEs and FEs via the ForCES protocol [RFC5810]:
给定网元中转发平面的实际模型是CE必须通过与FEs通信（或通过其他方式）来学习和控制的。大多数通信将使用ForCES协议在关联后阶段进行。CEs和FEs之间必须通过ForCES协议[RFC5810]交换以下类型的信息：
1. FE topology query,
1. FE拓扑查询，
2. FE capability declaration,
2. FE能力声明，
3. LFB topology (per FE) and configuration capabilities query,
3. LFB拓扑（每个FE）和配置能力查询，
4. LFB capability declaration,
4. LFB能力声明，
5. State query of LFB components,
5. LFB组件的状态查询，
6. Manipulation of LFB components, and
6. LFB组件的操作，以及
7. LFB topology reconfiguration.
7. LFB拓扑重构。
Items 1 through 5 are query exchanges, where the main flow of information is from the FEs to the CEs. Items 1 through 4 are typically queried by the CE(s) in the beginning of the post-association (PA) phase, though they may be repeatedly queried at any time in the PA phase. Item 5 (state query) will be used at the beginning of the PA phase, and often frequently during the PA phase (especially for the query of statistical counters).
第1项到第5项是查询交换，其中主要的信息流是从FEs到CEs。项目1至4通常由CE在关联后（PA）阶段开始时进行查询，尽管在关联后（PA）阶段随时可能重复查询。第5项（状态查询）将在PA阶段开始时使用，通常在PA阶段频繁使用（尤其是查询统计计数器）。
Items 6 and 7 are "command" types of exchanges, where the main flow of information is from the CEs to the FEs. Messages in Item 6 (the LFB re-configuration commands) are expected to be used frequently. Item 7 (LFB topology re-configuration) is needed only if dynamic LFB topologies are supported by the FEs and it is expected to be used infrequently.
第6项和第7项是“命令”类型的交换，其中主要的信息流是从CEs到FEs。第6项（LFB重新配置命令）中的消息预计会经常使用。仅当FEs支持动态LFB拓扑且预计不经常使用时，才需要第7项（LFB拓扑重新配置）。
The inter-FE topology (Item 1 above) can be determined by the CE in many ways. Neither this document nor the ForCES protocol [RFC5810] document mandates a specific mechanism. The LFB class definition does include the capability for an FE to be configured with, and to provide to the CE in response to a query, the identity of its neighbors. There may also be defined specific LFB classes and protocols for neighbor discovery. Routing protocols may be used by the CE for adjacency determination. The CE may be configured with the relevant information.
FE间拓扑（上文第1项）可由CE以多种方式确定。本文件和部队协议[RFC5810]文件均未规定具体机制。LFB类定义确实包括FE配置的能力，以及为响应查询向CE提供其邻居身份的能力。还可以为邻居发现定义特定的LFB类和协议。路由协议可由CE用于邻接确定。可以使用相关信息配置CE。
The relationship between the FE model and the seven post-association messages is visualized in Figure 12:
FE模型和七条关联后消息之间的关系如图12所示：
+--------+
..........-->| CE |
/----\ . +--------+
\____/ FE Model . ^ |
| |................ (1),2 | | 6, 7
| | (off-line) . 3, 4, 5 | |
\____/ . | v
. +--------+
e.g., RFCs ..........-->| FE |
+--------+
+--------+
..........-->| 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）是部队基本协议的一部分，其余由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的组件，在这种情况下，这些组件必须在LFB类中定义。
o The understanding of the type of information that must be exchanged between the FEs and CEs can help to select the appropriate protocol format and the actual encoding method (such as XML, TLVs).
o 了解FEs和CEs之间必须交换的信息类型有助于选择适当的协议格式和实际编码方法（如XML、TLV）。
o Understanding the frequency of these types of messages should influence the selection of the protocol format (efficiency considerations).
o 了解这些类型消息的频率会影响协议格式的选择（效率考虑）。
The remaining sub-sections of this section address each of the seven message types.
本节的其余小节分别介绍七种消息类型。
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可能包含零个、一个或多个外部入口端口。类似地，FE可以包含零个、一个或多个外部出口端口。换句话说，并非每个FE都必须包含任何外部入口或出口接口。例如，图13显示了两个级联FEs。FE#1包含一个外部入口接口但没有外部出口接口，而FE#2包含一个外部出口接口但没有入口接口。可以通过它们的内部接口将这两个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间通信协议超出了ForCES的范围，但应由CE查询并了解多个FE如何相互连接以执行完整的进出包处理功能，如图13中所述。FE间拓扑信息可以由FEs提供，可以硬编码到CE中，或者可以由独立于FEs的某个其他实体（例如，总线管理器）提供。因此，虽然ForCES协议[RFC5810]支持来自FEs的FE拓扑查询，但是CE使用它是可选的，假设CE有其他方法来收集此类拓扑信息。
+-----------------------------------------------------+
| +---------+ +------------+ +---------+ |
input| | | | | | output |
---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+
| | port | |Decompressor| |Forwarder| FE | |
| +---------+ +------------+ +---------+ #1 | |
+-----------------------------------------------------+ V
|
+-----------------------<-----------------------------+
|
| +----------------------------------------+
V | +------------+ +----------+ |
| input | | | | output |
+->--+->|Header |-->| Egress |---------+-->
| |Compressor | | port | FE |
| +------------+ +----------+ #2 |
+----------------------------------------+
+-----------------------------------------------------+
| +---------+ +------------+ +---------+ |
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：两个FEs连接在一起的示例。
Once the inter-FE topology is discovered by the CE after this query, it is assumed that the inter-FE topology remains static. However, it is possible that an FE may go down during the NE operation, or a board may be inserted and a new FE activated, so the inter-FE topology will be affected. It is up to the ForCES protocol to provide a mechanism for the CE to detect such events and deal with the change in FE topology. FE topology is outside the scope of the FE model.
一旦CE在此查询后发现了FE间拓扑，则假定FE间拓扑保持静态。然而，在NE操作期间，FE可能会下降，或者可能会插入板并激活新FE，因此FE间拓扑将受到影响。由ForCES协议为CE提供检测此类事件和处理FE拓扑变化的机制。FE拓扑不在FE模型的范围内。
FEs will have many types of limitations. Some of the limitations must be expressed to the CEs as part of the capability model. The CEs must be able to query these capabilities on a per-FE basis. Examples are the following:
FEs将有许多类型的限制。一些限制必须作为能力模型的一部分表达给CEs。CEs必须能够根据每个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).
o 全局资源查询限制（适用于FE的所有LFB）。
o LFB supported by the FE.
o 由FE支持的LFB。
o LFB class instantiation limit.
o LFB类实例化限制。
o LFB topological limitations (linkage constraint, ordering, etc.).
o LFB拓扑限制（链接约束、排序等）。
The ForCES protocol must provide the means for the CEs to discover the current set of LFB instances in an FE and the interconnections between the LFBs within the FE. In addition, sufficient information should be available to determine whether the FE supports any CE-initiated (dynamic) changes to the LFB topology, and if so, determine the allowed topologies. Topology configurability can also be considered as part of the FE capability query as described in Section 7.2.
ForCES协议必须提供CEs发现FE中当前LFB实例集以及FE中LFB之间互连的方法。此外，应提供足够的信息，以确定FE是否支持CE对LFB拓扑发起的任何（动态）更改，如果支持，则确定允许的拓扑。拓扑可配置性也可被视为FE能力查询的一部分，如第7.2节所述。
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
LFB类规范定义了一组通用的功能。当在供应商的FE上实现（实例化）LFB实例时，可能会引入一些额外的限制。注意，我们只讨论LFB类规范灵活性范围内的限制。也就是说，LFB实例将保持与
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类的某些特性可能是可选的，在这种情况下，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实例的实际性能。能力查询通常在CE首次检测到LFB时发生。在静态限制的情况下，不需要重新查询功能。然而，在某些情况下，某些能力可能会随时间发生变化（例如，由于添加/删除其他LFB，或在LFB共享物理资源时配置某些其他LFB的某些组件），在这种情况下，必须实施额外的机制来通知CE这些变化。
The following two broad types of limitations will exist:
存在以下两大类限制：
o Qualitative restrictions. For example, a standardized multi-field classifier LFB class may define a large number of classification fields, but a given FE may support only a subset of those fields.
o 质量限制。例如，标准化的多字段分类器LFB类可以定义大量的分类字段，但是给定的FE可能只支持这些字段的子集。
o Quantitative restrictions, such as the maximum size of tables, etc.
o 数量限制，如表的最大大小等。
The capability parameters that can be queried on a given LFB class will be part of the LFB class specification. The capability parameters should be regarded as special components of the LFB. The actual values of these components may, therefore, be obtained using the same component query mechanisms as used for other LFB components.
可在给定LFB类上查询的能力参数将是LFB类规范的一部分。能力参数应视为LFB的特殊组件。因此，可以使用与其他LFB组件相同的组件查询机制来获得这些组件的实际值。
Capability components are read-only arguments. In cases where some implementations may allow CE modification of the value, the information must be represented as an operational component, not a capability component.
功能组件是只读参数。在某些实现可能允许CE修改值的情况下，信息必须表示为操作组件，而不是能力组件。
Assuming that capabilities will not change frequently, the efficiency of the protocol/schema/encoding is of secondary concern.
假设功能不会频繁更改，协议/模式/编码的效率是次要考虑的问题。
Much of this restrictive information is captured by the component property information, and so can be accessed uniformly for all information within the model.
这些限制性信息大部分由组件属性信息捕获，因此可以统一访问模型中的所有信息。
This feature must be provided by all FEs. The ForCES protocol and the data schema/encoding conveyed by the protocol must together satisfy the following requirements to facilitate state query of the LFB components:
所有FEs都必须提供此功能。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实例，但可选地支持一组（或全部）LFB的寻址。
o Must support addressing of individual components of an LFB.
o 必须支持LFB单个组件的寻址。
o Must provide efficient encoding and decoding of the addressing info and the configured data.
o 必须提供寻址信息和配置数据的有效编码和解码。
o Must provide efficient data transmission of the component state over the wire (to minimize communication load on the CE-FE link).
o 必须通过导线提供组件状态的有效数据传输（以最小化CE-FE链路上的通信负载）。
The FE model provides for the definition of LFB classes. Each class has a globally unique identifier. Information within the class is represented as components and assigned identifiers within the scope of that class. This model also specifies that instances of LFB classes have identifiers. The combination of class identifiers, instance identifiers, and component identifiers is used by the protocol to reference the LFB information in the protocol operations.
FE模型提供了LFB类的定义。每个类都有一个全局唯一标识符。类中的信息表示为该类范围内的组件和分配的标识符。该模型还指定LFB类的实例具有标识符。协议使用类标识符、实例标识符和组件标识符的组合来引用协议操作中的LFB信息。
Operations that will be needed to reconfigure LFB topology are as follows:
重新配置LFB拓扑所需的操作如下：
o Create a new instance of a given LFB class on a given FE.
o 在给定FE上创建给定LFB类的新实例。
o Connect a given output of LFB x to the given input of LFB y.
o 将LFB x的给定输出连接到LFB y的给定输入。
o Disconnect: remove a link between a given output of an LFB and a given input of another LFB.
o 断开：删除LFB的给定输出和另一LFB的给定输入之间的链接。
o Delete a given LFB (automatically removing all interconnects to/ from the LFB).
o 删除给定LFB（自动删除LFB之间的所有互连）。
This section contains an example LFB definition. While some properties of LFBs are shown by the FE Object LFB, this endeavors to show how a data plane LFB might be build. This example is a fictional case of an interface supporting a coarse WDM optical interface that carries frame relay traffic. The statistical information (including error statistics) is omitted.
本节包含一个示例LFB定义。虽然LFB的某些属性由FE对象LFB显示，但这试图显示如何构建数据平面LFB。此示例是一个虚构的接口案例，该接口支持承载帧中继业务的粗略WDM光学接口。省略统计信息（包括错误统计）。
Later portions of this example include references to protocol operations. The operations described are operations the protocol needs to support. The exact format and fields are purely informational here, as the ForCES protocol [RFC5810] document defines the precise syntax and semantics of its operations.
本示例后面的部分包括对协议操作的引用。所描述的操作是协议需要支持的操作。这里的确切格式和字段纯粹是信息性的，因为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" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="LaserFrameLFB">
<frameDefs>
<frameDef>
<name>FRFrame</name>
<synopsis>
A frame relay frame, with DLCI without
stuffing)
</synopsis>
</frameDef>
<frameDef>
<name>IPFrame</name>
<synopsis>An IP Packet</synopsis>
</frameDef>
</frameDefs>
<dataTypeDefs>
<dataTypeDef>
<name>frequencyInformationType</name>
<synopsis>
Information about a single CWDM frequency
</synopsis>
<struct>
<component componentID="1">
<name>LaserFrequency</name>
<synopsis>encoded frequency(channel)</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>FrequencyState</name>
<synopsis>state of this frequency</synopsis>
<typeRef>PortStatusValues</typeRef>
</component>
<component componentID="3">
<name>LaserPower</name>
<synopsis>current observed power</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>FrameRelayCircuits</name>
<synopsis>
Information about circuits on this Frequency
</synopsis>
<array>
<typeRef>frameCircuitsType</typeRef>
</array>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>frameCircuitsType</name>
<synopsis>
Information about a single Frame Relay Circuit
</synopsis>
<struct>
<component componentID="1">
<name>DLCI</name>
<synopsis>DLCI of the circuit</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>CircuitStatus</name>
<synopsis>state of the circuit</synopsis>
<typeRef>PortStatusValues</typeRef>
</component>
<component componentID="3">
<name>isLMI</name>
<synopsis>is this the LMI circuit</synopsis>
<typeRef>boolean</typeRef>
</component>
<component componentID="4">
<name>associatedPort</name>
<synopsis>
which input / output port is associated
with this circuit
</synopsis>
<typeRef>uint32</typeRef>
<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>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>PortStatusValues</name>
<synopsis>
The possible values of status. Used for both
administrative and operational status
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>Disabled </name>
<synopsis>the component is disabled</synopsis>
</specialValue>
<specialValue value="1">
<name>Enabled</name>
<synopsis>FE is operatively enabled</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
</dataTypeDefs>
<metadataDefs>
<metadataDef>
<name>DLCI</name>
<synopsis>The DLCI the frame arrived on</synopsis>
<metadataID>12</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>LaserChannel</name>
<synopsis>The index of the laser channel</synopsis>
<metadataID>34</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
</metadataDefs>
<LFBClassDefs>
<!-- dummy classid, but needs to be a valid value -->
<LFBClassDef LFBClassID="255">
<name>FrameLaserLFB</name>
<synopsis>Fictional LFB for Demonstrations</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="true">
<name>LMIfromFE</name>
<synopsis>
Ports for LMI traffic, for transmission
</synopsis>
<expectation>
<frameExpected>
<ref>FRFrame</ref>
</frameExpected>
<metadataExpected>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataExpected>
</expectation>
</inputPort>
<inputPort>
<name>DatafromFE</name>
<synopsis>
Ports for data to be sent on circuits
</synopsis>
<expectation>
<frameExpected>
<ref>IPFrame</ref>
</frameExpected>
<metadataExpected>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>LMItoFE</name>
<synopsis>
Ports for LMI traffic for processing
</synopsis>
<product>
<frameProduced>
<ref>FRFrame</ref>
</frameProduced>
<metadataProduced>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="true">
<name>DatatoFE</name>
<synopsis>
Ports for Data traffic for processing
Ports for LMI traffic, for transmission
</synopsis>
<expectation>
<frameExpected>
<ref>FRFrame</ref>
</frameExpected>
<metadataExpected>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataExpected>
</expectation>
</inputPort>
<inputPort>
<name>DatafromFE</name>
<synopsis>
Ports for data to be sent on circuits
</synopsis>
<expectation>
<frameExpected>
<ref>IPFrame</ref>
</frameExpected>
<metadataExpected>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>LMItoFE</name>
<synopsis>
Ports for LMI traffic for processing
</synopsis>
<product>
<frameProduced>
<ref>FRFrame</ref>
</frameProduced>
<metadataProduced>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="true">
<name>DatatoFE</name>
<synopsis>
Ports for Data traffic for processing
</synopsis>
<product>
<frameProduced>
<ref>IPFrame</ref>
</frameProduced>
<metadataProduced>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>AdminPortState</name>
<synopsis>is this port allowed to function</synopsis>
<typeRef>PortStatusValues</typeRef>
</component>
<component access="read-write" componentID="2">
<name>FrequencyInformation</name>
<synopsis>
table of information per CWDM frequency
</synopsis>
<array type="variable-size">
<typeRef>frequencyInformationType</typeRef>
</array>
</component>
</components>
<capabilities>
<capability componentID="31">
<name>OperationalState</name>
<synopsis>
whether the port over all is operational
</synopsis>
<typeRef>PortStatusValues</typeRef>
</capability>
<capability componentID="32">
<name>MaximumFrequencies</name>
<synopsis>
how many laser frequencies are there
</synopsis>
<typeRef>uint16</typeRef>
</capability>
<capability componentID="33">
<name>MaxTotalCircuits</name>
<synopsis>
Total supportable Frame Relay Circuits, across
all laser frequencies
</synopsis>
<product>
<frameProduced>
<ref>IPFrame</ref>
</frameProduced>
<metadataProduced>
<ref>DLCI</ref>
<ref>LaserChannel</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>AdminPortState</name>
<synopsis>is this port allowed to function</synopsis>
<typeRef>PortStatusValues</typeRef>
</component>
<component access="read-write" componentID="2">
<name>FrequencyInformation</name>
<synopsis>
table of information per CWDM frequency
</synopsis>
<array type="variable-size">
<typeRef>frequencyInformationType</typeRef>
</array>
</component>
</components>
<capabilities>
<capability componentID="31">
<name>OperationalState</name>
<synopsis>
whether the port over all is operational
</synopsis>
<typeRef>PortStatusValues</typeRef>
</capability>
<capability componentID="32">
<name>MaximumFrequencies</name>
<synopsis>
how many laser frequencies are there
</synopsis>
<typeRef>uint16</typeRef>
</capability>
<capability componentID="33">
<name>MaxTotalCircuits</name>
<synopsis>
Total supportable Frame Relay Circuits, across
all laser frequencies
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
<events baseID="61">
<event eventID="1">
<name>FrequencyState</name>
<synopsis>
The state of a frequency has changed
</synopsis>
<eventTarget>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrequencyState</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<!-- report the new state -->
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrequencyState</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>CreatedFrequency</name>
<synopsis>A new frequency has appeared</synopsis>
<eventTarget>
<eventField>FrequencyInformation></eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserFrequency</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="3">
<name>DeletedFrequency</name>
<synopsis>
A frequency Table entry has been deleted
</synopsis>
<eventTarget>
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
<events baseID="61">
<event eventID="1">
<name>FrequencyState</name>
<synopsis>
The state of a frequency has changed
</synopsis>
<eventTarget>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrequencyState</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<!-- report the new state -->
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrequencyState</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>CreatedFrequency</name>
<synopsis>A new frequency has appeared</synopsis>
<eventTarget>
<eventField>FrequencyInformation></eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserFrequency</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="3">
<name>DeletedFrequency</name>
<synopsis>
A frequency Table entry has been deleted
</synopsis>
<eventTarget>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
</eventTarget>
<eventDeleted/>
</event>
<event eventID="4">
<name>PowerProblem</name>
<synopsis>
there are problems with the laser power level
</synopsis>
<eventTarget>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserPower</eventField>
</eventTarget>
<eventLessThan/>
<eventReports>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserPower</eventField>
</eventReport>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserFrequency</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="5">
<name>FrameCircuitChanged</name>
<synopsis>
the state of an Fr circuit on a frequency
has changed
</synopsis>
<eventTarget>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrameRelayCircuits</eventField>
<eventSubscript>FrameCircuitIndex</eventSubscript>
<eventField>CircuitStatus</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrameRelayCircuits</eventField>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
</eventTarget>
<eventDeleted/>
</event>
<event eventID="4">
<name>PowerProblem</name>
<synopsis>
there are problems with the laser power level
</synopsis>
<eventTarget>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserPower</eventField>
</eventTarget>
<eventLessThan/>
<eventReports>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserPower</eventField>
</eventReport>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>LaserFrequency</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="5">
<name>FrameCircuitChanged</name>
<synopsis>
the state of an Fr circuit on a frequency
has changed
</synopsis>
<eventTarget>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrameRelayCircuits</eventField>
<eventSubscript>FrameCircuitIndex</eventSubscript>
<eventField>CircuitStatus</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrameRelayCircuits</eventField>
<eventSubscript>FrameCircuitIndex</eventSubscript>
<eventField>CircuitStatus</eventField>
</eventReport>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrameRelayCircuits</eventField>
<eventSubscript>FrameCircuitIndex</eventSubscript>
<eventField>DLCI</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
<eventSubscript>FrameCircuitIndex</eventSubscript>
<eventField>CircuitStatus</eventField>
</eventReport>
<eventReport>
<eventField>FrequencyInformation</eventField>
<eventSubscript>_FrequencyIndex_</eventSubscript>
<eventField>FrameRelayCircuits</eventField>
<eventSubscript>FrameCircuitIndex</eventSubscript>
<eventField>DLCI</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
This LFB is designed to handle data packets coming in from or going out to the external world. It is not a full port, and it lacks many useful statistics, but it serves to show many of the relevant behaviors. The following paragraphs describe a potential operational device and how it might use this LFB definition.
该LFB设计用于处理从外部世界传入或传出的数据包。它不是一个完整的端口，并且缺少许多有用的统计数据，但它可以显示许多相关的行为。以下段落描述了一个潜在的操作设备及其如何使用LFB定义。
Packets arriving without error from the physical interface come in on a frame relay DLCI on a laser channel. These two values are used by the LFB to look up the handling for the packet. If the handling indicates that the packet is LMI, then the output index is used to select an LFB port from the LMItoFE port group. The packet is sent as a full frame relay frame (without any bit or byte stuffing) on the selected port. The laser channel and DLCI are sent as metadata, even though the DLCI is also still in the packet.
从物理接口无误到达的数据包通过激光信道上的帧中继DLCI进入。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帧中继类型指示符的好数据包作为IP数据包发送到DatatoFE端口组中的端口，使用表中基于激光信道和DLCI的相同索引字段。频道和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
到达输入端口的数据包以激光通道和帧中继DLCI作为元数据到达。因此，可以使用单个输入端口。通过定义的结构（与输出结构平行），通道和DLCI的选择可能受到到达输入端口组（LMI vs.data）和端口的限制
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.
指数作为替代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 = SET
T = PATH-DATA
Path: flags = none, length = 4, path = 2, channel, 4, entryIdx
DataRaw: DLCI, Enabled(1), false, out-idx
which would establish the DLCI as enabled, with traffic going to a specific entry of the output port group DatatoFE. (The CE would ensure that the output port is connected to the right place before issuing this request.)
这将使DLCI建立为启用状态，通信量将流向输出端口组DatatoFE的特定条目。（在发出此请求之前，CE将确保输出端口连接到正确的位置。）
The response would confirm the creation of the specified entry. This table is structured to use separate internal indices and DLCIs. An alternative design could have used the DLCI as index, trading off complexities.
响应将确认指定条目的创建。此表的结构使用单独的内部索引和DLCI。另一种设计可以使用DLCI作为索引，权衡复杂性。
One could also imagine that the FE has an LMI LFB. Such an LFB would be connected to the LMItoFE and LMIfromFE port groups. It would process LMI information. It might be the LFB's job to set up the frame relay circuits. The LMI LFB would have an alias entry that points to the frame relay circuits table it manages, so that it can manipulate those entities.
也可以想象FE具有LMI LFB。这种LFB将连接到LMItoFE和LMIfromFE端口组。它将处理LMI信息。LFB的工作可能是设置帧中继电路。LMI LFB将有一个别名条目，指向它所管理的帧中继电路表，以便它可以操作这些实体。
The LFB will receive invalid packets over the wire. Many of these will simply result in incrementing counters. The LFB designer might also specify some error rate measures. This puts more work on the FE, but allows for more meaningful alarms.
LFB将通过线路接收无效数据包。其中许多操作只会导致计数器递增。LFB设计器还可以指定一些错误率度量。这将在FE上投入更多的工作，但允许更多有意义的报警。
There may be some error conditions that should cause parts of the packet to be sent to the CE. The error itself is not something that can cause an event in the LFB. There are two ways this can be handled.
可能存在一些错误情况，这些错误情况会导致部分数据包被发送到CE。错误本身不会导致LFB中发生事件。有两种方法可以解决这个问题。
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定义为具有两个顶级组件。一个反映了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.
帧中继电路信息包含DLCI、工作电路状态、该电路是否将被视为承载LMI信息以及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。可以说，DLCI是冗余的，因为CE可能根据电路索引知道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)
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，则会导致报告。（据推测，行政长官知道权力的等级，并选择了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点附近振荡，你可能会收到很多通知。（如果它在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)
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，微小的变化可能会使它在9到10之间来回翻转。滞后级别为1将抑制这种情况。许多其他事件的振荡范围更广，因此可以使用更大的滞后设置。
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: The URI for this namespace is
urn:ietf:params:xml:ns:forces:lfbmodel:1.0
Registrant Contact: IESG
注册联系人：IESG
XML: none, this is an XML namespace
XML：无，这是一个XML名称空间
In order to have well defined ForCES LFB Classes, and well defined identifiers for those classes, IANA has created a registry of LFB class names, corresponding class identifiers, and the document that defines the LFB class. The registry policy is simply first come,
为了拥有定义良好的ForCES LFB类和这些类的定义良好的标识符，IANA创建了LFB类名称、相应类标识符和定义LFB类的文档的注册表。注册表策略只是先到先得，
first served (FCFS) with regard to LFB class names. With regard to LFB class identifiers, identifiers less than 65536 are reserved for assignment by IETF Standards-Track RFCs. Identifiers equal to or above 65536, in the 32-bit class ID space, are available for assignment on a first come, first served basis. All registry entries must be documented in a stable, publicly available form.
关于LFB类名的优先服务（FCFS）。关于LFB类标识符，小于65536的标识符保留供IETF标准跟踪RFC分配。在32位类ID空间中，等于或高于65536的标识符可根据先到先得的原则进行分配。所有注册表项必须以稳定、公开的形式记录。
Since this registry provides for FCFS allocation of a portion of the class identifier space, it is necessary to define rules for naming classes that are using that space. As these can be defined by anyone, the needed rule is to keep the FCFS class names from colliding with IETF-defined class names. Therefore, all FCFS class names MUST start with the string "Ext-".
由于此注册表提供了一部分类标识符空间的FCFS分配，因此有必要定义命名使用该空间的类的规则。因为任何人都可以定义，所以需要的规则是防止FCFS类名与IETF定义的类名冲突。因此，所有FCFS类名必须以字符串“Ext-”开头。
Table 1 tabulates the above information.
表1列出了上述信息。
IANA has created a registry of ForCES LFB Class Names and the corresponding ForCES LFB Class Identifiers, with the location of the definition of the ForCES LFB Class, in accordance with the rules in the following table.
IANA已根据下表中的规则创建了一个部队LFB类名称和相应部队LFB类标识符的注册表，其中包含部队LFB类定义的位置。
+----------------+------------+---------------+---------------------+
| LFB Class Name | LFB Class | Place Defined | Description |
| | Identifier | | |
+----------------+------------+---------------+---------------------+
| Reserved | 0 | RFC 5812 | Reserved |
| | | | -------- |
| FE Object | 1 | RFC 5812 | Defines ForCES |
| | | | Forwarding Element |
| | | | information |
| FE Protocol | 2 | [2] | Defines parameters |
| Object | | | for the ForCES |
| | | | protocol operation |
| | | | -------- |
| IETF defined | 3-65535 | Standards | Reserved for IETF |
| LFBs | | Track RFCs | defined RFCs |
| | | | -------- |
| ForCES LFB | >65535 | Any Publicly | First Come, First |
| Class names | | Available | Served for any use |
| beginning EXT- | | Document | |
+----------------+------------+---------------+---------------------+
+----------------+------------+---------------+---------------------+
| LFB Class Name | LFB Class | Place Defined | Description |
| | Identifier | | |
+----------------+------------+---------------+---------------------+
| Reserved | 0 | RFC 5812 | Reserved |
| | | | -------- |
| FE Object | 1 | RFC 5812 | Defines ForCES |
| | | | Forwarding Element |
| | | | information |
| FE Protocol | 2 | [2] | Defines parameters |
| Object | | | for the ForCES |
| | | | protocol operation |
| | | | -------- |
| IETF defined | 3-65535 | Standards | Reserved for IETF |
| LFBs | | Track RFCs | defined RFCs |
| | | | -------- |
| ForCES LFB | >65535 | Any Publicly | First Come, First |
| Class names | | Available | Served for any use |
| beginning EXT- | | Document | |
+----------------+------------+---------------+---------------------+
Table 1
表1
The following are the authors who were instrumental in the creation of earlier releases of this document.
以下是在创建本文档早期版本过程中发挥作用的作者。
Ellen Delganes, Intel Corp. Lily Yang, Intel Corp. Ram Gopal, Nokia Research Center Alan DeKok, Infoblox, Inc. Zsolt Haraszti, Clovis Solutions
Ellen Delganes、Intel Corp.Lily Yang、Intel Corp.Ram Gopal、诺基亚研究中心Alan DeKok、Infoblox，Inc.Zsolt Haraszti、Clovis Solutions
Many of the colleagues in our companies and participants in the ForCES mailing list have provided invaluable input into this work. Particular thanks to Evangelos Haleplidis for help getting the XML right.
我们公司的许多同事和部队邮件列表的参与者为这项工作提供了宝贵的投入。特别感谢Evangelos Haleplidis帮助正确使用XML。
The FE model describes the representation and organization of data sets and components in the FEs. The ForCES framework document [RFC3746] provides a comprehensive security analysis for the overall ForCES architecture. For example, the ForCES protocol entities must be authenticated per the ForCES requirements before they can access the information elements described in this document via ForCES. Access to the information contained in the FE model is accomplished via the ForCES protocol, which is defined in separate documents, and thus the security issues will be addressed there.
FE模型描述FEs中数据集和组件的表示和组织。部队框架文件[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]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010.
[RFC5810]Doria，A.，Ed.，Hadi Salim，J.，Ed.，Haas，R.，Ed.，Khosravi，H.，Ed.，Wang，W.，Ed.，Dong，L.，Gopal，R.，和J.Halpern，“转发和控制元素分离（部队）协议规范”，RFC 58102010年3月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[Schema1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, http://www.w3.org/TR/xmlshcema-1/, May 2001.
[Schema1]Thompson，H.，Beech，D.，Maloney，M.，和N.Mendelsohn，“XML模式第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]Biron，P.和A.Malhotra，“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.Anderson，“IP控制和转发分离的要求”，RFC 3654，2003年11月。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004.
[RFC3746]Yang，L.，Dantu，R.，Anderson，T.，和R.Gopal，“转发和控制单元分离（部队）框架”，RFC 37462004年4月。
[RFC3317] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie, "Differentiated Services Quality of Service Policy Information Base", RFC 3317, March 2003.
[RFC3317]Chan，K.，Sahita，R.，Hahn，S.，和K.McCloghrie，“差异化服务质量服务政策信息库”，RFC 33172003年3月。
[RFC3318] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, "Framework Policy Information Base", RFC 3318, March 2003.
[RFC3318]Sahita，R.，Hahn，S.，Chan，K.，和K.McCloghrie，“框架政策信息库”，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.Schoenwaeld，“关于信息模型和数据模型之间的差异”，RFC 3444，2003年1月。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470]Hollenbeck，S.，Rose，M.，和L.Masinter，“IETF协议中可扩展标记语言（XML）的使用指南”，BCP 70，RFC 3470，2003年1月。
[UNICODE] Davis, M. and M. Suignard, "UNICODE Security Considerations", http://www.unicode.org/reports/tr36/tr36-3.html , July 2005.
[UNICODE]Davis，M.和M.Suignard，“UNICODE安全注意事项”，http://www.unicode.org/reports/tr36/tr36-3.html ，2005年7月。
Authors' Addresses
作者地址
Joel Halpern Self P.O. Box 6049 Leesburg, VA 20178 USA
美国弗吉尼亚州利斯堡市Joel Halpern Self邮政信箱6049号，邮编20178
Phone: +1 703 371 3043
EMail: jmh@joelhalpern.com
Phone: +1 703 371 3043
EMail: jmh@joelhalpern.com
Jamal Hadi Salim Znyx Networks Ottawa, Ontario Canada
加拿大安大略省渥太华Jamal Hadi Salim Znyx网络公司
EMail: hadi@mojatatu.com
EMail: hadi@mojatatu.com