Internet Engineering Task Force (IETF) A. Doria, Ed.
Request for Comments: 5810 Lulea University of Technology
Category: Standards Track J. Hadi Salim, Ed.
ISSN: 2070-1721 Znyx
R. Haas, Ed.
IBM
H. Khosravi, Ed.
Intel
W. Wang, Ed.
L. Dong
Zhejiang Gongshang University
R. Gopal
Nokia
J. Halpern
March 2010
Internet Engineering Task Force (IETF) A. Doria, Ed.
Request for Comments: 5810 Lulea University of Technology
Category: Standards Track J. Hadi Salim, Ed.
ISSN: 2070-1721 Znyx
R. Haas, Ed.
IBM
H. Khosravi, Ed.
Intel
W. Wang, Ed.
L. Dong
Zhejiang Gongshang University
R. Gopal
Nokia
J. Halpern
March 2010
Forwarding and Control Element Separation (ForCES) Protocol Specification
转发和控制元素分离（ForCES）协议规范
Abstract
摘要
This document specifies the Forwarding and Control Element Separation (ForCES) protocol. The ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC 3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML).
本文件规定了转发和控制元素分离（ForCES）协议。ForCES协议用于ForCES网元（ForCES NE）中控制元件（CE）和转发元件（FEs）之间的通信。本规范旨在满足RFC 3654中定义的部队协议要求。除了ForCES协议外，本规范还定义了传输映射层（TML）的要求。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5810.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5810.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................5
2. Terminology and Conventions .....................................6
2.1. Requirements Language ......................................6
2.2. Other Notation .............................................6
2.3. Integers ...................................................6
3. Definitions .....................................................6
4. Overview .......................................................10
4.1. Protocol Framework ........................................11
4.1.1. The PL .............................................13
4.1.2. The TML ............................................14
4.1.3. The FEM/CEM Interface ..............................14
4.2. ForCES Protocol Phases ....................................15
4.2.1. Pre-association ....................................16
4.2.2. Post-association ...................................18
4.3. Protocol Mechanisms .......................................19
4.3.1. Transactions, Atomicity, Execution, and Responses ..19
4.3.2. Scalability ........................................25
4.3.3. Heartbeat Mechanism ................................26
4.3.4. FE Object and FE Protocol LFBs .....................27
4.4. Protocol Scenarios ........................................27
4.4.1. Association Setup State ............................27
4.4.2. Association Established State or Steady State ......29
5. TML Requirements ...............................................31
5.1. TML Parameterization ......................................34
6. Message Encapsulation ..........................................35
6.1. Common Header .............................................35
6.2. Type Length Value (TLV) Structuring .......................40
6.2.1. Nested TLVs ........................................41
6.2.2. Scope of the T in TLV ..............................41
6.3. ILV .......................................................41
6.4. Important Protocol Encapsulations .........................42
6.4.1. Paths ..............................................42
6.4.2. Keys ...............................................42
6.4.3. DATA TLVs ..........................................43
6.4.4. Addressing LFB Entities ............................43
7. Protocol Construction ..........................................44
7.1. Discussion on Encoding ....................................48
7.1.1. Data Packing Rules .................................48
7.1.2. Path Flags .........................................49
7.1.3. Relation of Operational Flags with Global
Message Flags ......................................49
7.1.4. Content Path Selection .............................49
7.1.5. LFBselect-TLV ......................................49
7.1.6. OPER-TLV ...........................................50
7.1.7. RESULT TLV .........................................52
7.1.8. DATA TLV ...........................................55
1. Introduction ....................................................5
2. Terminology and Conventions .....................................6
2.1. Requirements Language ......................................6
2.2. Other Notation .............................................6
2.3. Integers ...................................................6
3. Definitions .....................................................6
4. Overview .......................................................10
4.1. Protocol Framework ........................................11
4.1.1. The PL .............................................13
4.1.2. The TML ............................................14
4.1.3. The FEM/CEM Interface ..............................14
4.2. ForCES Protocol Phases ....................................15
4.2.1. Pre-association ....................................16
4.2.2. Post-association ...................................18
4.3. Protocol Mechanisms .......................................19
4.3.1. Transactions, Atomicity, Execution, and Responses ..19
4.3.2. Scalability ........................................25
4.3.3. Heartbeat Mechanism ................................26
4.3.4. FE Object and FE Protocol LFBs .....................27
4.4. Protocol Scenarios ........................................27
4.4.1. Association Setup State ............................27
4.4.2. Association Established State or Steady State ......29
5. TML Requirements ...............................................31
5.1. TML Parameterization ......................................34
6. Message Encapsulation ..........................................35
6.1. Common Header .............................................35
6.2. Type Length Value (TLV) Structuring .......................40
6.2.1. Nested TLVs ........................................41
6.2.2. Scope of the T in TLV ..............................41
6.3. ILV .......................................................41
6.4. Important Protocol Encapsulations .........................42
6.4.1. Paths ..............................................42
6.4.2. Keys ...............................................42
6.4.3. DATA TLVs ..........................................43
6.4.4. Addressing LFB Entities ............................43
7. Protocol Construction ..........................................44
7.1. Discussion on Encoding ....................................48
7.1.1. Data Packing Rules .................................48
7.1.2. Path Flags .........................................49
7.1.3. Relation of Operational Flags with Global
Message Flags ......................................49
7.1.4. Content Path Selection .............................49
7.1.5. LFBselect-TLV ......................................49
7.1.6. OPER-TLV ...........................................50
7.1.7. RESULT TLV .........................................52
7.1.8. DATA TLV ...........................................55
7.1.9. SET and GET Relationship ...........................56
7.2. Protocol Encoding Visualization ...........................56
7.3. Core ForCES LFBs ..........................................59
7.3.1. FE Protocol LFB ....................................60
7.3.2. FE Object LFB ......................................63
7.4. Semantics of Message Direction ............................63
7.5. Association Messages ......................................64
7.5.1. Association Setup Message ..........................64
7.5.2. Association Setup Response Message .................66
7.5.3. Association Teardown Message .......................68
7.6. Configuration Messages ....................................69
7.6.1. Config Message .....................................69
7.6.2. Config Response Message ............................71
7.7. Query Messages ............................................73
7.7.1. Query Message ......................................73
7.7.2. Query Response Message .............................75
7.8. Event Notification Message ................................77
7.9. Packet Redirect Message ...................................79
7.10. Heartbeat Message ........................................82
8. High Availability Support ......................................83
8.1. Relation with the FE Protocol .............................83
8.2. Responsibilities for HA ...................................86
9. Security Considerations ........................................87
9.1. No Security ...............................................87
9.1.1. Endpoint Authentication ............................88
9.1.2. Message Authentication .............................88
9.2. ForCES PL and TML Security Service ........................88
9.2.1. Endpoint Authentication Service ....................88
9.2.2. Message Authentication Service .....................89
9.2.3. Confidentiality Service ............................89
10. Acknowledgments ...............................................89
11. References ....................................................89
11.1. Normative References .....................................89
11.2. Informative References ...................................90
Appendix A. IANA Considerations ..................................91
A.1. Message Type Namespace ....................................91
A.2. Operation Selection .......................................92
A.3. Header Flags ..............................................93
A.4. TLV Type Namespace ........................................93
A.5. RESULT-TLV Result Values ..................................94
A.6. Association Setup Response ................................94
A.7. Association Teardown Message ..............................95
Appendix B. ForCES Protocol LFB Schema ...........................96
B.1. Capabilities .............................................102
B.2. Components ...............................................102
Appendix C. Data Encoding Examples ..............................103
Appendix D. Use Cases ...........................................107
7.1.9. SET and GET Relationship ...........................56
7.2. Protocol Encoding Visualization ...........................56
7.3. Core ForCES LFBs ..........................................59
7.3.1. FE Protocol LFB ....................................60
7.3.2. FE Object LFB ......................................63
7.4. Semantics of Message Direction ............................63
7.5. Association Messages ......................................64
7.5.1. Association Setup Message ..........................64
7.5.2. Association Setup Response Message .................66
7.5.3. Association Teardown Message .......................68
7.6. Configuration Messages ....................................69
7.6.1. Config Message .....................................69
7.6.2. Config Response Message ............................71
7.7. Query Messages ............................................73
7.7.1. Query Message ......................................73
7.7.2. Query Response Message .............................75
7.8. Event Notification Message ................................77
7.9. Packet Redirect Message ...................................79
7.10. Heartbeat Message ........................................82
8. High Availability Support ......................................83
8.1. Relation with the FE Protocol .............................83
8.2. Responsibilities for HA ...................................86
9. Security Considerations ........................................87
9.1. No Security ...............................................87
9.1.1. Endpoint Authentication ............................88
9.1.2. Message Authentication .............................88
9.2. ForCES PL and TML Security Service ........................88
9.2.1. Endpoint Authentication Service ....................88
9.2.2. Message Authentication Service .....................89
9.2.3. Confidentiality Service ............................89
10. Acknowledgments ...............................................89
11. References ....................................................89
11.1. Normative References .....................................89
11.2. Informative References ...................................90
Appendix A. IANA Considerations ..................................91
A.1. Message Type Namespace ....................................91
A.2. Operation Selection .......................................92
A.3. Header Flags ..............................................93
A.4. TLV Type Namespace ........................................93
A.5. RESULT-TLV Result Values ..................................94
A.6. Association Setup Response ................................94
A.7. Association Teardown Message ..............................95
Appendix B. ForCES Protocol LFB Schema ...........................96
B.1. Capabilities .............................................102
B.2. Components ...............................................102
Appendix C. Data Encoding Examples ..............................103
Appendix D. Use Cases ...........................................107
Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework. While there may be multiple protocols used within the overall ForCES architecture, the terms "ForCES protocol" and "protocol" as used in this document refer to the protocol used to standardize the information exchange between Control Elements (CEs) and Forwarding Elements (FEs) only.
转发和控制元素分离（ForCES）定义了一个体系结构框架和相关协议，以标准化ForCES网元（ForCES NE）中控制平面和转发平面之间的信息交换。RFC 3654定义了部队需求，RFC 3746定义了部队框架。虽然在整个部队体系结构中可能使用多个协议，但本文件中使用的术语“部队协议”和“协议”仅指用于标准化控制元件（CE）和转发元件（FEs）之间信息交换的协议。
The ForCES FE model [RFC5812] presents a formal way to define FE Logical Function Blocks (LFBs) using XML. LFB configuration components, capabilities, and associated events are defined when the LFB is formally created. The LFBs within the FE are accordingly controlled in a standardized way by the ForCES protocol.
ForCES FE模型[RFC5812]提供了一种使用XML定义FE逻辑功能块（LFB）的形式化方法。LFB配置组件、功能和相关事件在正式创建LFB时定义。FE内的LFB由ForCES协议以标准化方式进行相应控制。
This document defines the ForCES protocol specifications. The ForCES protocol works in a master-slave mode in which FEs are slaves and CEs are masters. The protocol includes commands for transport of LFB configuration information, association setup, status, event notifications, etc.
本文件定义了ForCES协议规范。ForCES协议在主-从模式下工作，其中FEs是从设备，CE是主设备。该协议包括用于传输LFB配置信息、关联设置、状态、事件通知等的命令。
Section 3 provides a glossary of terminology used in the specification.
第3节提供了规范中使用的术语表。
Section 4 provides an overview of the protocol, including a discussion on the protocol framework and descriptions of the Protocol Layer (PL), a Transport Mapping Layer (TML), and the ForCES protocol mechanisms. Section 4.4 describes several protocol scenarios and includes message exchange descriptions.
第4节概述了协议，包括对协议框架的讨论以及协议层（PL）、传输映射层（TML）和ForCES协议机制的描述。第4.4节描述了几种协议场景，包括消息交换描述。
While this document does not define the TML, Section 5 details the services that a TML MUST provide (TML requirements).
虽然本文件没有定义TML，但第5节详细说明了TML必须提供的服务（TML要求）。
The ForCES protocol defines a common header for all protocol messages. The header is defined in Section 6.1, while the protocol messages are defined in Section 7.
ForCES协议为所有协议消息定义了一个公共头。标题在第6.1节中定义，而协议消息在第7节中定义。
Section 8 describes the protocol support for high-availability mechanisms including redundancy and fail over.
第8节描述了对高可用性机制的协议支持，包括冗余和故障转移。
Section 9 defines the security mechanisms provided by the PL and TML.
第9节定义了PL和TML提供的安全机制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In Table 1 and Table 2, the following notation is used to indicate multiplicity:
在表1和表2中，以下符号用于表示多重性：
(value)+ .... means "1 or more instances of value"
(value)+ .... means "1 or more instances of value"
(value)* .... means "0 or more instances of value"
(value)* .... means "0 or more instances of value"
All integers are to be coded as unsigned binary integers of appropriate length.
所有整数均应编码为适当长度的无符号二进制整数。
This document follows the terminology defined by the ForCES requirements in [RFC3654] and by the ForCES framework in [RFC3746]. The definitions be are repeated below for clarity.
本文件遵循[RFC3654]中部队要求和[RFC3746]中部队框架定义的术语。为了清楚起见，下面重复这些定义。
Addressable Entity (AE):
可寻址实体（AE）：
A physical device that is directly addressable given some interconnect technology. For example, on IP networks, it is a device that can be reached using an IP address; and on a switch fabric, it is a device that can be reached using a switch fabric port number.
一种物理设备，通过某种互连技术可以直接寻址。例如，在IP网络上，它是可以使用IP地址访问的设备；在交换机结构上，它是一种可以使用交换机结构端口号访问的设备。
Control Element (CE):
控制元件（CE）：
A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs on how to process packets. CEs handle functionality such as the execution of control and signaling protocols.
一种逻辑实体，实现强制协议，并使用它指示一个或多个FEs如何处理数据包。CEs处理控制和信令协议的执行等功能。
CE Manager (CEM):
行政总裁经理（CEM）：
A logical entity responsible for generic CE management tasks. It is particularly used during the pre-association phase to determine with which FE(s) a CE should communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs.
负责通用CE管理任务的逻辑实体。它特别用于在预关联阶段确定CE应与哪些FE通信。此过程称为FE发现，可能涉及CE经理了解可用FE的能力。
Data Path:
数据路径：
A conceptual path taken by packets within the forwarding plane inside an FE.
FE内转发平面内的数据包采用的概念路径。
Forwarding Element (FE):
转发元素（FE）：
A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per-packet processing and handling as directed/controlled by one or more CEs via the ForCES protocol.
实现ForCES协议的逻辑实体。FEs使用底层硬件，按照一个或多个CE通过ForCES协议的指示/控制，提供每包处理和处理。
FE Model:
有限元模型：
A model that describes the logical processing functions of an FE. The FE model is defined using Logical Function Blocks (LFBs).
描述FE逻辑处理功能的模型。FE模型使用逻辑功能块（LFB）定义。
FE Manager (FEM):
FE经理（FEM）：
A logical entity responsible for generic FE management tasks. It is used during the pre-association phase to determine with which CE(s) an FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. An FE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which CE(s) to use. Being a logical entity, an FE manager might be physically combined with any of the other logical entities such as FEs.
负责一般FE管理任务的逻辑实体。它在预关联阶段用于确定FE应与哪些CE通信。此过程称为CE发现，可能涉及FE经理学习可用CE的能力。FE经理可以使用从静态配置到预关联阶段协议（见下文）的任何方法来确定要使用的CE。作为逻辑实体，FE管理器可以与任何其他逻辑实体（如FEs）进行物理组合。
ForCES Network Element (NE):
部队网元（NE）：
An entity composed of one or more CEs and one or more FEs. To entities outside an NE, the NE represents a single point of management. Similarly, an NE usually hides its internal organization from external entities.
由一个或多个CE和一个或多个FE组成的实体。对于网元之外的实体，网元表示单个管理点。类似地，网元通常对外部实体隐藏其内部组织。
High Touch Capability:
高触控能力：
This term will be used to apply to the capabilities found in some forwarders to take action on the contents or headers of a packet based on content other than what is found in the IP header. Examples of these capabilities include quality of service (QoS) policies, virtual private networks, firewall, and L7 content recognition.
该术语将用于应用于某些转发器中的功能，即基于IP报头中的内容以外的内容对数据包的内容或报头采取操作。这些功能的示例包括服务质量（QoS）策略、虚拟专用网络、防火墙和L7内容识别。
Inter-FE Topology:
内部FE拓扑：
See FE Topology.
请参见FE拓扑。
Intra-FE Topology:
内部FE拓扑：
See LFB Topology.
请参见LFB拓扑。
LFB (Logical Function Block):
LFB（逻辑功能块）：
The basic building block that is operated on by the ForCES protocol. The LFB is a well-defined, logically separable functional block that resides in an FE and is controlled by the CE via the ForCES protocol. The LFB may reside at the FE's data path and process packets or may be purely an FE control or configuration entity that is operated on by the CE. Note that the LFB is a functionally accurate abstraction of the FE's processing capabilities, but not a hardware-accurate representation of the FE implementation.
由ForCES协议操作的基本构建块。LFB是一个定义良好、逻辑上可分离的功能块，位于FE中，由CE通过ForCES协议控制。LFB可以驻留在FE的数据路径上并处理分组，或者可以是由CE操作的纯粹FE控制或配置实体。请注意，LFB是FE处理能力的功能精确抽象，但不是FE实现的硬件精确表示。
FE Topology:
FE拓扑：
A representation of how the multiple FEs within a single NE are interconnected. Sometimes this is called inter-FE topology, to be distinguished from intra-FE topology (i.e., LFB topology).
表示单个网元内多个FE的互连方式。有时这被称为内部FE拓扑，以区别于内部FE拓扑（即LFB拓扑）。
LFB Class and LFB Instance:
LFB类和LFB实例：
LFBs are categorized by LFB classes. An LFB instance represents an LFB class (or type) existence. There may be multiple instances of the same LFB class (or type) in an FE. An LFB class is represented by an LFB class ID, and an LFB instance is represented by an LFB instance ID. As a result, an LFB class ID associated with an LFB instance ID uniquely specifies an LFB existence.
LFB按LFB类进行分类。LFB实例表示LFB类（或类型）的存在。FE中可能存在同一LFB类（或类型）的多个实例。LFB类由LFB类ID表示，LFB实例由LFB实例ID表示。因此，与LFB实例ID关联的LFB类ID唯一地指定LFB的存在。
LFB Meta Data:
LFB元数据：
Meta data is used to communicate per-packet state from one LFB to another, but is not sent across the network. The FE model defines how such meta data is identified, produced, and consumed by the LFBs. It defines the functionality but not how meta data is encoded within an implementation.
元数据用于从一个LFB到另一个LFB的每个数据包状态的通信，但不会通过网络发送。FE模型定义了LFB如何识别、生成和使用这些元数据。它定义了功能，但没有定义元数据在实现中的编码方式。
LFB Component:
LFB组件：
Operational parameters of the LFBs that must be visible to the CEs are conceptualized in the FE model as the LFB components. The LFB components include, for example, flags, single parameter arguments, complex arguments, and tables that the CE can read and/or write via the ForCES protocol (see below).
对于CEs必须可见的LFB操作参数，在FE模型中被概念化为LFB组件。LFB组件包括，例如，标志、单参数参数参数、复杂参数以及CE可以通过ForCES协议读取和/或写入的表（见下文）。
LFB Topology:
LFB拓扑：
Representation of how the LFB instances are logically interconnected and placed along the data path within one FE. Sometimes it is also called intra-FE topology, to be distinguished from inter-FE topology.
表示LFB实例如何在一个FE内沿数据路径进行逻辑互连和放置。有时也称为内部FE拓扑，以区别于内部FE拓扑。
Pre-association Phase:
会前阶段：
The period of time during which an FE manager and a CE manager are determining which FE(s) and CE(s) should be part of the same network element.
FE管理器和CE管理器确定哪些FE和CE应属于同一网元的时间段。
Post-association Phase:
结社后阶段：
The period of time during which an FE knows which CE is to control it and vice versa. This includes the time during which the CE and FE are establishing communication with one another.
FE知道哪个CE控制它的时间段，反之亦然。这包括CE和FE彼此建立通信的时间。
ForCES Protocol:
部队议定书：
While there may be multiple protocols used within the overall ForCES architecture, the terms "ForCES protocol" and "protocol" refer to the Fp reference points in the ForCES framework in [RFC3746]. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or communication between FE and CE managers. Basically, the ForCES protocol works in a master-slave mode in which FEs are slaves and CEs are masters. This document defines the specifications for this ForCES protocol.
虽然在整个部队体系结构中可能使用多个协议，但术语“部队协议”和“协议”指的是[RFC3746]中部队框架中的Fp参考点。本协议不适用于CE-to-CE通信、FE-to-FE通信或FE与CE经理之间的通信。基本上，ForCES协议在主-从模式下工作，其中FEs是从机，ce是主机。本文件定义了本协议的规范。
ForCES Protocol Layer (ForCES PL):
强制协议层（强制PL）：
A layer in the ForCES protocol architecture that defines the ForCES protocol messages, the protocol state transfer scheme, and the ForCES protocol architecture itself (including requirements of ForCES TML as shown below). Specifications of ForCES PL are defined by this document.
ForCES协议体系结构中的一层，定义ForCES协议消息、协议状态传输方案和ForCES协议体系结构本身（包括ForCES TML的要求，如下所示）。力PL的规格由本文件定义。
ForCES Protocol Transport Mapping Layer (ForCES TML):
ForCES协议传输映射层（ForCES TML）：
A layer in ForCES protocol architecture that uses the capabilities of existing transport protocols to specifically address protocol message transportation issues, such as how the protocol messages are mapped to different transport media (like TCP, IP, ATM, Ethernet, etc.), and how to achieve and implement reliability, multicast, ordering, etc. The ForCES TML specifications are detailed in separate ForCES documents, one for each TML.
一种层内协议体系结构，它使用现有传输协议的功能来专门解决协议消息传输问题，例如协议消息如何映射到不同的传输介质（如TCP、IP、ATM、以太网等），以及如何实现和实现可靠性、多播、排序，部队TML规范在单独的部队文件中详细说明，每个TML一份。
The reader is referred to the framework document [RFC3746], and in particular, Sections 3 and 4, for an architectural overview and an explanation of how the ForCES protocol fits in. There may be some content overlap between the framework document and this section in order to provide clarity. This document is authoritative on the protocol, whereas [RFC3746] is authoritative on the architecture.
读者可参考框架文件[RFC3746]，特别是第3节和第4节，以了解体系结构概述和对ForCES协议如何适用的解释。为了清晰起见，框架文档和本节之间可能存在一些内容重叠。本文件对协议具有权威性，而[RFC3746]对体系结构具有权威性。
Figure 1 below is reproduced from the framework document for clarity. It shows an NE with two CEs and two FEs.
为清晰起见，以下图1摘自框架文件。它显示了一个具有两个CE和两个FEs的NE。
---------------------------------------
| ForCES Network Element |
-------------- Fc | -------------- -------------- |
| CE Manager |---------+-| CE 1 |------| CE 2 | |
-------------- | | | Fr | | |
| | -------------- -------------- |
| Fl | | | Fp / |
| | Fp| |----------| / |
| | | |/ |
| | | | |
| | | Fp /|----| |
| | | /--------/ | |
-------------- Ff | -------------- -------------- |
| FE Manager |---------+-| FE 1 | Fi | FE 2 | |
-------------- | | |------| | |
| -------------- -------------- |
| | | | | | | | | |
----+--+--+--+----------+--+--+--+-----
| | | | | | | |
| | | | | | | |
Fi/f Fi/f
---------------------------------------
| ForCES Network Element |
-------------- Fc | -------------- -------------- |
| CE Manager |---------+-| CE 1 |------| CE 2 | |
-------------- | | | Fr | | |
| | -------------- -------------- |
| Fl | | | Fp / |
| | Fp| |----------| / |
| | | |/ |
| | | | |
| | | Fp /|----| |
| | | /--------/ | |
-------------- Ff | -------------- -------------- |
| FE Manager |---------+-| FE 1 | Fi | FE 2 | |
-------------- | | |------| | |
| -------------- -------------- |
| | | | | | | | | |
----+--+--+--+----------+--+--+--+-----
| | | | | | | |
| | | | | | | |
Fi/f Fi/f
Fp: CE-FE interface Fi: FE-FE interface Fr: CE-CE interface Fc: Interface between the CE manager and a CE Ff: Interface between the FE manager and an FE Fl: Interface between the CE manager and the FE manager Fi/f: FE external interface
Fp:CE-FE接口Fi:FE-FE接口Fr:CE-CE接口Fc:CE管理器和CE Ff之间的接口：FE管理器和FE Fl之间的接口：CE管理器和FE管理器之间的接口Fi/f:FE外部接口
Figure 1: ForCES Architectural Diagram
图1:ForCES体系结构图
The ForCES protocol domain is found in the Fp reference points. The Protocol Element configuration reference points, Fc and Ff, also play a role in the booting up of the ForCES protocol. The protocol element configuration (indicated by reference points Fc, Ff, and Fl in [RFC3746]) is out of scope of the ForCES protocol but is touched on in this document in discussion of FEM and CEM since it is an integral part of the protocol pre-association phase.
ForCES协议域位于Fp参考点中。协议元素配置参考点Fc和Ff也在ForCES协议的启动中发挥作用。协议元素配置（由[RFC3746]中的参考点Fc、Ff和Fl表示）不在ForCES协议的范围内，但在本文件FEM和CEM的讨论中涉及，因为它是协议预关联阶段的一个组成部分。
Figure 2 below shows further breakdown of the Fp interfaces by means of the example of an MPLS QoS-enabled Network Element.
下面的图2显示了通过启用MPLS QoS的网元示例对Fp接口的进一步细分。
-------------------------------------------------
| | | | | | |
|OSPF |RIP |BGP |RSVP |LDP |. . . |
| | | | | | |
------------------------------------------------- CE
| ForCES Interface |
-------------------------------------------------
^ ^
| |
ForCES | |data
control | |packets
messages| |(e.g., routing packets)
| |
v v
-------------------------------------------------
| ForCES Interface |
------------------------------------------------- FE
| | | | | | |
|LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . |
| | | | |fier | |
-------------------------------------------------
-------------------------------------------------
| | | | | | |
|OSPF |RIP |BGP |RSVP |LDP |. . . |
| | | | | | |
------------------------------------------------- CE
| ForCES Interface |
-------------------------------------------------
^ ^
| |
ForCES | |data
control | |packets
messages| |(e.g., routing packets)
| |
v v
-------------------------------------------------
| ForCES Interface |
------------------------------------------------- FE
| | | | | | |
|LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . |
| | | | |fier | |
-------------------------------------------------
Figure 2: Examples of CE and FE Functions
图2:CE和FE函数示例
The ForCES interface shown in Figure 2 constitutes two pieces: the PL and the TML.
图2所示的ForCES接口由两部分组成：PL和TML。
This is depicted in Figure 3 below.
下面的图3对此进行了描述。
+------------------------------------------------
| CE PL |
+------------------------------------------------
| CE TML |
+------------------------------------------------
^
|
ForCES | (i.e., ForCES data + control
PL | packets )
messages |
over |
specific |
TML |
encaps |
and |
transport |
|
v
+------------------------------------------------
| FE TML |
+------------------------------------------------
| FE PL |
+------------------------------------------------
+------------------------------------------------
| CE PL |
+------------------------------------------------
| CE TML |
+------------------------------------------------
^
|
ForCES | (i.e., ForCES data + control
PL | packets )
messages |
over |
specific |
TML |
encaps |
and |
transport |
|
v
+------------------------------------------------
| FE TML |
+------------------------------------------------
| FE PL |
+------------------------------------------------
Figure 3: ForCES Interface
图3:ForCES接口
The PL is in fact the ForCES protocol. Its semantics and message layout are defined in this document. The TML layer is necessary to connect two ForCES PLs as shown in Figure 3 above. The TML is out of scope for this document but is within scope of ForCES. This document defines requirements the PL needs the TML to meet.
PL实际上是ForCES协议。其语义和消息布局在本文档中定义。TML层是连接两个力PLs所必需的，如上图3所示。TML不在本文件范围内，但在部队范围内。本文件定义了PL需要TML满足的要求。
Both the PL and the TML are standardized by the IETF. While only one PL is defined, different TMLs are expected to be standardized. To interoperate, the TML at the CE and FE are expected to conform to the same definition.
PL和TML均由IETF标准化。虽然只定义了一个PL，但不同的TML有望标准化。为了互操作，CE和FE的TML应符合相同的定义。
On transmit, the PL delivers its messages to the TML. The local TML delivers the message to the destination TML. On receive, the TML delivers the message to its destination PL.
在传输时，PL将其消息传递给TML。本地TML将消息传递到目标TML。接收时，TML将消息传递到其目标PL。
The PL is common to all implementations of ForCES and is standardized by the IETF as defined in this document. The PL is responsible for associating an FE or CE to an NE. It is also responsible for tearing
PL是所有部队实施的通用标准，并由本文件中定义的IETF标准化。PL负责将FE或CE与NE关联。它也负责撕裂
down such associations. An FE uses the PL to transmit various subscribed-to events to the CE PL as well as to respond to various status requests issued from the CE PL. The CE configures both the FE and associated LFBs' operational parameters using the PL. In addition, the CE may send various requests to the FE to activate or deactivate it, reconfigure its HA parameterization, subscribe to specific events, etc. More details can be found in Section 7.
打倒这样的联想。FE使用PL向CE PL发送各种订阅事件，并响应CE PL发出的各种状态请求。CE使用PL配置FE和相关LFB的操作参数。此外，CE可向FE发送各种请求以激活或停用它，重新配置其HA参数化、订阅特定事件等。更多详细信息请参见第7节。
The TML transports the PL messages. The TML is where the issues of how to achieve transport-level reliability, congestion control, multicast, ordering, etc. are handled. It is expected that more than one TML will be standardized. The various possible TMLs could vary their implementations based on the capabilities of underlying media and transport. However, since each TML is standardized, interoperability is guaranteed as long as both endpoints support the same TML. All ForCES protocol layer implementations MUST be portable across all TMLs, because all TMLs MUST have the top-edge semantics defined in this document.
TML传输PL消息。TML是处理如何实现传输级可靠性、拥塞控制、多播、排序等问题的地方。预计不止一个TML将标准化。各种可能的TML可以根据底层媒体和传输的能力而改变其实现。但是，由于每个TML都是标准化的，只要两个端点都支持相同的TML，就可以保证互操作性。所有ForCES协议层实现必须可移植到所有TML，因为所有TML必须具有本文档中定义的顶部边缘语义。
The FEM and CEM components, although valuable in the setup and configurations of both the PL and TML, are out of scope of the ForCES protocol. The best way to think of them is as configurations/ parameterizations for the PL and TML before they become active (or even at runtime based on implementation). In the simplest case, the FE or CE reads a static configuration file. RFC 3746 has a more detailed description on how the FEM and CEM could be used. The pre-association phase, where the CEM and FEM can be used, are described briefly in Section 4.2.1.
FEM和CEM组件虽然在PL和TML的设置和配置中都很有价值，但不在ForCES协议的范围内。最好的方法是在PL和TML激活之前（甚至在运行时基于实现）将其视为PL和TML的配置/参数化。在最简单的情况下，FE或CE读取静态配置文件。RFC 3746对如何使用FEM和CEM有更详细的描述。第4.2.1节简要描述了可使用CEM和FEM的预关联阶段。
An example of typical things the FEM/CEM could configure would be TML-specific parameterizations such as:
FEM/CEM可以配置的典型事物的一个例子是TML特定的参数化，例如：
a. How the TML connection should happen (for example, what IP addresses to use, transport modes, etc.)
a. TML连接应该如何发生（例如，使用什么IP地址、传输模式等）
b. The ID for the FE (FEID) or CE (CEID) (which would also be issued during the pre-association phase)
b. FE（FEID）或CE（CEID）的ID（也将在关联前阶段发布）
c. Security parameterization such as keys, etc.
c. 安全参数化，如密钥等。
d. Connection association parameters
d. 连接关联参数
An example of connection association parameters might be:
连接关联参数的一个示例可能是：
o simple parameters: send up to 3 association messages every 1 second
o 简单参数：每1秒最多发送3条关联消息
o complex parameters: send up to 4 association messages with increasing exponential timeout
o 复杂参数：最多发送4条关联消息，超时时间呈指数增长
ForCES, in relation to NEs, involves two phases: the pre-association phase where configuration/initialization/bootup of the TML and PL layer happens, and the post-association phase where the ForCES protocol operates to manipulate the parameters of the FEs.
与网元相关的ForCES包括两个阶段：TML和PL层配置/初始化/启动的关联前阶段，以及ForCES协议操作以操纵FEs参数的关联后阶段。
CE sends Association Setup
+---->--->------------>---->---->---->------->----+
| Y
^ |
| Y
+---+-------+ +-------------+
|FE pre- | | FE post- |
|association| CE sends Association Teardown | association |
|phase |<------- <------<-----<------<-------+ phase |
| | | |
+-----------+ +-------------+
^ Y
| |
+-<---<------<-----<------<----<---------<------+
FE loses association
CE sends Association Setup
+---->--->------------>---->---->---->------->----+
| Y
^ |
| Y
+---+-------+ +-------------+
|FE pre- | | FE post- |
|association| CE sends Association Teardown | association |
|phase |<------- <------<-----<------<-------+ phase |
| | | |
+-----------+ +-------------+
^ Y
| |
+-<---<------<-----<------<----<---------<------+
FE loses association
Figure 4: The FE Protocol Phases
图4：FE协议阶段
In the mandated case, once associated, the FE may forward packets depending on the configuration of its specific LFBs. An FE that is associated to a CE will continue sending packets until it receives an Association Teardown Message or until it loses association. An unassociated FE MAY continue sending packets when it has a high availability capability. The extra details are explained in Section 8 and not discussed here to allow for a clear explanation of the basics.
在强制情况下，一旦关联，FE可以根据其特定lfb的配置转发分组。与CE关联的FE将继续发送数据包，直到收到关联解除消息或失去关联。无关联FE在具有高可用性能力时可以继续发送数据包。额外的细节在第8节中进行了解释，这里不进行讨论，以便对基本原理进行清晰的解释。
The FE state transitions are controlled by means of the FE Object LFB FEState component, which is defined in [RFC5812], Section 5.1, and also explained in Section 7.3.2.
FE状态转换通过FE对象LFB FEState组件控制，该组件在[RFC5812]第5.1节中定义，并在第7.3.2节中解释。
The FE initializes in the FEState OperDisable. When the FE is ready to process packets in the data path, it transitions itself to the OperEnable state.
FE在FEState OperDisable中初始化。当FE准备好处理数据路径中的数据包时，它会将自身转换为OperEnable状态。
The CE may decide to pause the FE after it already came up as OperEnable. It does this by setting the FEState to AdminDisable. The FE stays in the AdminDisable state until it is explicitly configured by the CE to transition to the OperEnable state.
行政长官可能会决定暂停FE，因为它已经成为Operable。它通过将FEState设置为AdminDisable来实现这一点。FE保持在AdminDisable状态，直到CE显式地将其配置为转换到Operable状态。
When the FE loses its association with the CE, it may go into the pre-association phase depending on the programmed policy. For the FE to properly complete the transition to the AdminDisable state, it MUST stop packet forwarding and this may impact multiple LFBS. How this is achieved is outside the scope of this specification.
当FE失去与CE的关联时，它可能会进入关联前阶段，具体取决于编程策略。FE要正确完成到AdminDisable状态的转换，必须停止数据包转发，这可能会影响多个LFB。如何实现这一点超出了本规范的范围。
The ForCES interface is configured during the pre-association phase. In a simple setup, the configuration is static and is typically read from a saved configuration file. All the parameters for the association phase are well known after the pre-association phase is complete. A protocol such as DHCP may be used to retrieve the configuration parameters instead of reading them from a static configuration file. Note, this will still be considered static pre-association. Dynamic configuration may also happen using the Fc, Ff, and Fl reference points (refer to [RFC3746]). Vendors may use their own proprietary service discovery protocol to pass the parameters. Essentially, only guidelines are provided here and the details are left to the implementation.
ForCES接口在预关联阶段进行配置。在简单的设置中，配置是静态的，通常从保存的配置文件中读取。在预关联阶段完成后，关联阶段的所有参数都是众所周知的。可以使用诸如DHCP之类的协议来检索配置参数，而不是从静态配置文件中读取它们。注意，这仍将被视为静态预关联。也可使用Fc、Ff和Fl参考点进行动态配置（参考[RFC3746]）。供应商可以使用自己的专有服务发现协议来传递参数。基本上，这里只提供了指南，细节留给实现。
The following are scenarios reproduced from the framework document to show a pre-association example.
以下是从框架文档中复制的场景，以显示预关联示例。
<----Ff ref pt---> <--Fc ref pt------->
FE Manager FE CE Manager CE
| | | |
| | | |
(security exchange) (security exchange)
1|<------------>| authentication 1|<----------->|authentication
| | | |
(FE ID, components) (CE ID, components)
2|<-------------| request 2|<------------|request
| | | |
3|------------->| response 3|------------>|response
(corresponding CE ID) (corresponding FE ID)
| | | |
| | | |
<----Ff ref pt---> <--Fc ref pt------->
FE Manager FE CE Manager CE
| | | |
| | | |
(security exchange) (security exchange)
1|<------------>| authentication 1|<----------->|authentication
| | | |
(FE ID, components) (CE ID, components)
2|<-------------| request 2|<------------|request
| | | |
3|------------->| response 3|------------>|response
(corresponding CE ID) (corresponding FE ID)
| | | |
| | | |
Figure 5: Examples of a Message Exchange over the Ff and Fc Reference Points
图5:Ff和Fc参考点上的消息交换示例
<-----------Fl ref pt--------------> |
<-----------Fl ref pt--------------> |
FE Manager FE CE Manager CE
| | | |
| | | |
(security exchange) | |
1|<------------------------------>| |
| | | |
(a list of CEs and their components) |
2|<-------------------------------| |
| | | |
(a list of FEs and their components) |
3|------------------------------->| |
| | | |
| | | |
FE Manager FE CE Manager CE
| | | |
| | | |
(security exchange) | |
1|<------------------------------>| |
| | | |
(a list of CEs and their components) |
2|<-------------------------------| |
| | | |
(a list of FEs and their components) |
3|------------------------------->| |
| | | |
| | | |
Figure 6: Example of a Message Exchange over the Fl Reference Point
图6:Fl参考点上的消息交换示例
Before the transition to the association phase, the FEM will have established contact with a CEM component. Initialization of the ForCES interface will have completed, and authentication as well as capability discovery may be complete. Both the FE and CE would have the necessary information for connecting to each other for configuration, accounting, identification, and authentication purposes. To summarize, at the completion of this stage both sides have all the necessary protocol parameters such as timers, etc. The Fl reference point may continue to operate during the association phase and may be used to force a disassociation of an FE or CE. The specific interactions of the CEM and the FEM that are part of the
在过渡到关联阶段之前，FEM将与CEM部件建立接触。部队接口的初始化将完成，身份验证和能力发现可能完成。FE和CE都将具有必要的信息，以便相互连接以进行配置、记帐、标识和身份验证。总之，在该阶段完成时，双方都拥有所有必要的协议参数，如定时器等。Fl参考点可在关联阶段继续运行，并可用于强制FE或CE解除关联。CEM和FEM之间的特定相互作用是
pre-association phase are out of scope; for this reason, these details are not discussed any further in this specification. The reader is referred to the framework document [RFC3746] for a slightly more detailed discussion.
关联前阶段超出范围；因此，本规范不再进一步讨论这些细节。读者可参考框架文件[RFC3746]进行更详细的讨论。
In this phase, the FE and CE components communicate with each other using the ForCES protocol (PL over TML) as defined in this document. There are three sub-phases:
在此阶段，FE和CE组件使用本文件中定义的ForCES协议（PL over TML）相互通信。分为三个子阶段：
o Association Setup Stage
o 协会成立阶段
o Established Stage
o 建立阶段
o Association Lost Stage
o 联想缺失期
The FE attempts to join the NE. The FE may be rejected or accepted. Once granted access into the NE, capabilities exchange happens with the CE querying the FE. Once the CE has the FE capability information, the CE can offer an initial configuration (possibly to restore state) and can query certain components within either an LFB or the FE itself.
FE试图加入NE。FE可能被拒绝或接受。一旦授予对网元的访问权，CE查询FE时就会进行能力交换。一旦CE获得FE能力信息，CE可以提供初始配置（可能恢复状态），并可以查询LFB或FE本身中的某些组件。
More details are provided in Section 4.4.
更多详情见第4.4节。
On successful completion of this stage, the FE joins the NE and is moved to the Established Stage.
成功完成此阶段后，FE加入NE并移动到已建立阶段。
In this stage, the FE is continuously updated or queried. The FE may also send asynchronous event notifications to the CE or synchronous heartbeat notifications if programmed to do so. This stage continues until a termination occurs, either due to loss of connectivity or due to a termination initiated by either the CE or the FE.
在此阶段，FE将不断更新或查询。FE还可以向CE发送异步事件通知，或者发送同步心跳通知（如果已编程）。此阶段将继续，直到由于连接中断或由于CE或FE发起的终止而发生终止。
Refer to the section on protocol scenarios, Section 4.4, for more details.
有关更多详细信息，请参阅协议场景部分第4.4节。
In this stage, both or either the CE or FE declare the other side is no longer associated. The disconnection could be initiated by either party for administrative purposes but may also be driven by operational reasons such as loss of connectivity.
在此阶段，CE或FE双方或其中一方声明另一方不再关联。任何一方都可以出于管理目的启动断开连接，但也可能是由于操作原因，如连接中断。
A core LFB known as the FE Protocol Object (FEPO) is defined (refer to Appendix B and Section 7.3.1). FEPO defines various timers that can be used in conjunction with a traffic-sensitive heartbeat mechanism (Section 4.3.3) to detect loss of connectivity.
定义了称为FE协议对象（FEPO）的核心LFB（参考附录B和第7.3.1节）。FEPO定义了各种定时器，可与流量敏感心跳机制（第4.3.3节）结合使用，以检测连接丢失。
The loss of connectivity between TMLs does not indicate a loss of association between respective PL layers. If the TML cannot repair the transport loss before the programmed FEPO timer thresholds associated with the FE is exceeded, then the association between the respective PL layers will be lost.
TML之间的连接丢失并不表示各个PL层之间的关联丢失。如果TML无法在超过与FE相关的编程FEPO定时器阈值之前修复传输损耗，则各PL层之间的关联将丢失。
FEPO defines several policies that can be programmed to define behavior upon a detected loss of association. The FEPO's programmed CE failover policy (refer to Sections 8, 7.3.1, 4.3.3, and B) defines what takes place upon loss of association.
FEPO定义了几个策略，这些策略可以编程来定义检测到的关联丢失时的行为。FEPO的编程CE故障切换策略（参考第8、7.3.1、4.3.3和B节）定义了失去关联时发生的情况。
For this version of the protocol (as defined in this document), the FE, upon re-association, MUST discard any state it has as invalid and retrieve new state. This approach is motivated by a desire for simplicity (as opposed to efficiency).
对于该版本的协议（如本文件所定义），FE在重新关联后必须放弃其作为无效状态的任何状态，并检索新状态。这种方法的动机是简单（而不是效率）。
Various semantics are exposed to the protocol users via the PL header including transaction capabilities, atomicity of transactions, two-phase commits, batching/parallelization, high availability, and failover as well as command pipelines.
通过PL头向协议用户公开各种语义，包括事务功能、事务原子性、两阶段提交、批处理/并行化、高可用性、故障切换以及命令管道。
The EM (Execution Mode) flag, AT (Atomic Transaction) flag, and TP (Transaction Phase) flag as defined in the common header (Section 6.1) are relevant to these mechanisms.
公共标头（第6.1节）中定义的EM（执行模式）标志、AT（原子事务）标志和TP（事务阶段）标志与这些机制相关。
In the master-slave relationship, the CE instructs one or more FEs on how to execute operations and how to report the results.
在主从关系中，CE指示一个或多个FEs如何执行操作以及如何报告结果。
This section details the different modes of execution that a CE can order the FE(s) to perform, as defined in Section 4.3.1.1. It also describes the different modes a CE can ask the FE(s) to use for formatting the responses after processing the operations as requested. These modes relate to the transactional two-phase commit operations.
本节详细说明了CE可命令FE执行的不同执行模式，如第4.3.1.1节所定义。它还描述了CE可以要求FE在处理请求的操作后使用的不同模式来格式化响应。这些模式与事务性两阶段提交操作相关。
There are 3 execution modes that can be requested for a batch of operations spanning one or more LFB selectors (refer to Section 7.1.5) in one protocol message. The EM flag defined in the common header (Section 6.1) selects the execution mode for a protocol message, as below:
在一条协议消息中，跨越一个或多个LFB选择器（参考第7.1.5节）的一批操作可以请求3种执行模式。公共标头（第6.1节）中定义的EM标志选择协议消息的执行模式，如下所示：
a. execute-all-or-none
a. 要么全部执行，要么不执行
b. continue-execute-on-failure
b. 失败时继续执行
c. execute-until-failure
c. 执行直到失败
When set to this mode of execution, independent operations in a message MAY be targeted at one or more LFB selectors within an FE. All these operations are executed serially, and the FE MUST have no execution failure for any of the operations. If any operation fails to execute, then all the previous ones that have been executed prior to the failure will need to be undone. That is, there is rollback for this mode of operation.
当设置为该执行模式时，消息中的独立操作可针对FE中的一个或多个LFB选择器。所有这些操作都是串行执行的，FE必须没有任何操作的执行失败。如果任何操作未能执行，则需要撤消失败之前执行的所有操作。也就是说，此操作模式存在回滚。
Refer to Section 4.3.1.2.2 for how this mode is used in cases of transactions. In such a case, no operation is executed unless a commit is issued by the CE.
有关在交易情况下如何使用此模式，请参阅第4.3.1.2.2节。在这种情况下，除非CE发出提交，否则不会执行任何操作。
Care should be taken on how this mode is used because a mis-configuration could result in traffic losses. To add certainty to the success of an operation, one should use this mode in a transactional operation as described in Section 4.3.1.2.2
应注意如何使用此模式，因为错误配置可能导致交通损失。为确保操作成功，应在第4.3.1.2.2节所述的事务性操作中使用该模式
If several independent operations are targeted at one or more LFB selectors, execution continues for all operations at the FE even if one or more operations fail.
如果多个独立操作针对一个或多个LFB选择器，则即使一个或多个操作失败，FE上的所有操作仍将继续执行。
In this mode, all operations are executed on the FE sequentially until the first failure. The rest of the operations are not executed but operations already completed are not undone. That is, there is no rollback in this mode of operation.
在此模式下，所有操作都会在FE上按顺序执行，直到出现第一次故障。其余操作不会执行，但已完成的操作不会撤消。也就是说，在这种操作模式下没有回滚。
A transaction is defined as a collection of one or more ForCES operations within one or more PL messages that MUST meet the ACIDity properties [ACID], defined as:
事务被定义为一个或多个PL消息中的一个或多个强制操作的集合，必须满足酸度属性[ACID]，定义为：
Atomicity: In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are.
原子性：在涉及两个或多个离散信息的事务中，要么提交所有信息，要么不提交任何信息。
Consistency: A transaction either creates a new and valid state of data or, if any failure occurs, returns all data to the state it was in before the transaction was started.
一致性：事务创建新的有效数据状态，或者，如果发生任何故障，将所有数据返回到事务启动前的状态。
Isolation: A transaction in process and not yet committed MUST remain isolated from any other transaction.
隔离：正在处理但尚未提交的事务必须与任何其他事务保持隔离。
Durability: Committed data is saved by the system such that, even in the event of a failure and a system restart, the data is available in its correct state.
持久性：提交的数据由系统保存，这样即使在发生故障和系统重新启动时，数据也能以正确的状态使用。
There are cases where the CE knows exact memory and implementation details of the FE such as in the case of an FE-CE pair from the same vendor where the FE-CE pair is tightly coupled. In such a case, the transactional operations may be simplified further by extra computation at the CE. This view is not discussed further other than to mention that it is not disallowed.
存在CE知道FE的确切存储器和实现细节的情况，例如来自同一供应商的FE-CE对的情况，其中FE-CE对紧密耦合。在这种情况下，可以通过CE处的额外计算来进一步简化事务操作。这个观点没有被进一步讨论，只是提到它不是不被允许的。
As defined above, a transaction is always atomic and MAY be
如上所述，事务始终是原子的，可以是
a. Within an FE alone Example: updating multiple tables that are dependent on each other. If updating one fails, then any that were already updated MUST be undone.
a. 在单独的FE示例中：更新相互依赖的多个表。如果更新失败，则必须撤消所有已更新的。
b. Distributed across the NE Example: updating table(s) that are inter-dependent across several FEs (such as L3 forwarding-related tables).
b. 跨网元分布示例：更新跨多个FE相互依赖的表（如L3转发相关表）。
By use of the execution mode, as defined in Section 4.3.1.1, the protocol has provided a mechanism for transactional operations within one stand-alone message. The 'execute-all-or-none' mode can meet the ACID requirements.
通过使用第4.3.1.1节中定义的执行模式，协议为一条独立消息中的事务操作提供了一种机制。“执行全部或无”模式可满足ACID要求。
For transactional operations of multiple messages within one FE or across FEs, a classical transactional protocol known as two-phase commit (2PC) [2PCREF] is supported by the protocol to achieve the transactional operations utilizing Config messages (Section 7.6.1).
对于一个FE内或跨FE的多条消息的事务操作，协议支持称为两阶段提交（2PC）[2PCREF]的经典事务协议，以利用配置消息实现事务操作（第7.6.1节）。
The COMMIT and TRCOMP operations in conjunction with the AT and the TP flags in the common header (Section 6.1) are provided for 2PC-based transactional operations spanning multiple messages.
COMMIT和TRCOMP操作以及公共头中的AT和TP标志（第6.1节）用于跨多条消息的基于2PC的事务操作。
The AT flag, when set, indicates that this message belongs to an Atomic Transaction. All messages for a transaction operation MUST have the AT flag set. If not set, it means that the message is a stand-alone message and does not participate in any transaction operation that spans multiple messages.
设置AT标志时，表示此消息属于原子事务。事务操作的所有消息都必须设置AT标志。如果未设置，则表示该消息是独立消息，不参与跨多个消息的任何事务操作。
The TP flag indicates the Transaction Phase to which this message belongs. There are 4 possible phases for a transactional operation known as:
TP标志指示此消息所属的事务阶段。事务操作有4个可能的阶段，称为：
SOT (Start of Transaction)
SOT（交易开始）
MOT (Middle of Transaction)
MOT（交易中）
EOT (End of Transaction)
EOT（交易结束）
ABT (Abort)
ABT（中止）
The COMMIT operation is used by the CE to signal to the FE(s) to commit a transaction. When used with an ABT TP flag, the COMMIT operation signals the FE(s) to roll back (i.e., un-COMMIT) a previously committed transaction.
CE使用提交操作向FE发送提交事务的信号。当与ABT TP标志一起使用时，提交操作向FE发送信号，以回滚（即取消提交）先前提交的事务。
The TRCOMP operation is a small addition to the classical 2PC approach. TRCOMP is sent by the CE to signal to the FE(s) that the transaction they have COMMITed is now over. This allows the FE(s) an opportunity to clear state they may have kept around to perform a roll back (if it became necessary).
TRCOMP操作是对经典2PC方法的一个小补充。CE发送TRCOMP，以向FE发出信号，表明其已提交的交易现已结束。这使FE有机会清除其可能保留的状态，以执行回滚（如果必要）。
A transaction operation is started with a message in which the TP flag is set to Start of Transaction (SOT). Multi-part messages, after the first one, are indicated by the Middle of Transaction (MOT) flag. All messages from the CE MUST set the AlwaysACK flag (Section 6) to solicit responses from the FE(s).
通过将TP标志设置为事务开始（SOT）的消息启动事务操作。第一条消息之后的多部分消息由中间事务（MOT）标志指示。来自CE的所有消息必须设置AlwaysACK标志（第6节），以征求FE的响应。
Before the CE issues a commit (described further below), the FE MUST only validate that the operation can be executed but not execute it.
在CE发出提交（下文将进一步描述）之前，FE必须仅验证操作是否可以执行，而不是执行。
Any failure notified by an FE causes the CE to abort the transaction on all FEs involved in the transaction. This is achieved by sending a Config message with an ABT flag and a COMMIT operation.
FE通知的任何故障都会导致CE中止事务中涉及的所有FE上的事务。这是通过发送带有ABT标志和提交操作的配置消息来实现的。
If there are no failures by any participating FE, the transaction commitment phase is signaled from the CE to the FE by an End of Transaction (EOT) configuration message with a COMMIT operation.
如果任何参与的FE没有出现故障，则通过带有提交操作的事务结束（EOT）配置消息将事务提交阶段从CE通知FE。
The FE MUST respond to the CE's EOT message. There are two possible failure scenarios in which the CE MUST abort the transaction (as described above):
FE必须响应CE的EOT消息。CE必须中止事务的两种可能的故障情况（如上所述）：
a. If any participating FE responds with a failure message in relation to the transaction.
a. 如果任何参与的FE响应与交易相关的故障消息。
b. If no response is received from a participating FE within a specified timeout.
b. 如果在指定的超时时间内未收到来自参与FE的响应。
If all participating FEs respond with a success indicator within the expected time, then the CE MUST issue a TRCOMP operation to all participating FEs. An FE MUST NOT respond to a TRCOMP.
如果所有参与FEs在预期时间内响应成功指标，则CE必须向所有参与FEs发出TRCOMP操作。FE不得响应TRCOMP。
Note that a transactional operation is generically atomic; therefore, it requires that the execution modes of all messages in a transaction operation should always be kept the same and be set to 'execute-all-or-none'. If the EM flag is set to other execution modes, it will result in a transaction failure.
请注意，事务操作通常是原子操作；因此，它要求事务操作中所有消息的执行模式始终保持不变，并设置为“全部执行或无执行”。如果EM标志设置为其他执行模式，则会导致事务失败。
As noted above, a transaction may span multiple messages. It is up to the CE to keep track of the different outstanding messages making up a transaction. As an example, the correlator field could be used to mark transactions and a sequence field to label the different messages within the same atomic transaction, but this is out of scope and up to implementations.
如上所述，一个事务可能跨越多个消息。CE负责跟踪组成事务的不同未完成消息。例如，correlator字段可用于标记事务，sequence字段可用于标记同一原子事务中的不同消息，但这超出了范围，取决于实现。
Any of the participating FEs or the CE or the associations between them may fail after the EOT Response message has been sent by the FE but before the CE has received all the responses, e.g., if the EOT response never reaches the CE.
在FE发送EOT响应消息之后，但在CE接收到所有响应之前，任何参与的FE或CE或它们之间的关联都可能失败，例如，如果EOT响应从未到达CE。
In this protocol revision, as indicated in Section 4.2.2.3, an FE losing an association would be required to get entirely new state from the newly associated CE upon a re-association. Although this approach is simplistic and provides likeliness of losing data path
在本协议修订版中，如第4.2.2.3节所述，失去关联的FE需要在重新关联时从新关联的CE获得全新的状态。尽管这种方法过于简单，并且提供了丢失数据路径的可能性
traffic, it is a design choice to avoid the additional complexity of managing graceful restarts. The HA mechanisms (Section 8) are provided to allow for a continuous operation in case of FE failures.
流量，这是一种设计选择，以避免管理正常重启的额外复杂性。HA机制（第8节）用于在FE故障时允许连续运行。
Flexibility is provided on how to react when an FE loses association. This is dictated by the CE failover policy (refer to Section 8 and Section 7.3).
在FE失去关联时如何反应方面提供了灵活性。这由CE故障切换策略决定（请参阅第8节和第7.3节）。
This section illustrates an example of how a successful two-phase commit between a CE and an FE would look in the simple case.
本节举例说明了在简单情况下，CE和FE之间成功的两阶段提交是如何进行的。
FE PL CE PL
铁磷矿
| |
| (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (2) ACKnowledge |
|----------------------------------------------------->|
| |
| (3) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (4) ACKnowledge |
|----------------------------------------------------->|
| |
| (5) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (6) ACKnowledge |
|----------------------------------------------------->|
. .
. .
. .
. .
| |
| (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT |
|<-----------------------------------------------------|
| |
| (N+1)Config-response, ACKnowledge, OP=COMMIT-RESPONSE|
|----------------------------------------------------->|
| |
| (N+2) Config, OP=TRCOMP |
|<-----------------------------------------------------|
| |
| (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (2) ACKnowledge |
|----------------------------------------------------->|
| |
| (3) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (4) ACKnowledge |
|----------------------------------------------------->|
| |
| (5) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (6) ACKnowledge |
|----------------------------------------------------->|
. .
. .
. .
. .
| |
| (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT |
|<-----------------------------------------------------|
| |
| (N+1)Config-response, ACKnowledge, OP=COMMIT-RESPONSE|
|----------------------------------------------------->|
| |
| (N+2) Config, OP=TRCOMP |
|<-----------------------------------------------------|
Figure 7: Example of a Two-Phase Commit
图7：两阶段提交的示例
For the scenario illustrated above:
对于上述场景：
o In step 1, the CE issues a Config message with an operation of choice like a DEL or SET. The transaction flags are set to indicate a Start of Transaction (SOT), Atomic Transaction (AT), and execute-all-or-none.
o 在步骤1中，CE发出一条配置消息，其中包含一个可选择的操作，如DEL或SET。事务标志设置为指示事务开始（SOT）、原子事务（AT）和执行全部或无。
o The FE validates that it can execute the request successfully and then issues an acknowledgment back to the CE in step 2.
o FE验证它是否可以成功执行请求，然后在步骤2中向CE发回确认。
o In step 3, the same sort of construct as in step 1 is repeated by the CE with the transaction flag changed to Middle of Transaction (MOT).
o 在步骤3中，CE重复步骤1中相同类型的构造，将事务标志更改为事务中间（MOT）。
o The FE validates that it can execute the request successfully and then issues an acknowledgment back to the CE in step 4.
o FE验证它是否可以成功执行请求，然后在步骤4中向CE发回确认。
o The CE-FE exchange continues in the same manner until all the operations and their parameters are transferred to the FE. This happens in step (N-1).
o CE-FE交换继续以相同的方式进行，直到所有操作及其参数转移到FE。这在步骤（N-1）中发生。
o In step N, the CE issues a commit. A commit is a Config message with an operation of type COMMIT. The transaction flag is set to End of Transaction (EOT). Essentially, this is an "empty" message asking the FE to execute all the operations it has gathered since the beginning of the transaction (message #1).
o 在步骤N中，CE发出提交。提交是一个具有提交类型操作的配置消息。事务标志设置为事务结束（EOT）。本质上，这是一条“空”消息，要求FE执行自事务开始以来收集的所有操作（消息#1）。
o The FE at this point executes the full transaction. It then issues an acknowledgment back to the CE in step (N+1) that contains a COMMIT-RESPONSE.
o 此时FE执行完整事务。然后，在步骤（N+1）中，它向CE发回一个包含提交响应的确认。
o The CE in this case has the simple task of issuing a TRCOMP operation to the FE in step (N+2).
o 在这种情况下，CE的简单任务是在步骤（N+2）中向FE发出TRCOMP操作。
It is desirable that the PL not become the bottleneck when larger bandwidth pipes become available. To pick a hypothetical example in today's terms, if a 100-Gbps pipe is available and there is sufficient work, then the PL should be able to take advantage of this and use all of the 100-Gbps pipe. Two mechanisms have been provided to achieve this. The first one is batching and the second one is a command pipeline.
当更大带宽的管道可用时，希望PL不会成为瓶颈。在今天的术语中选择一个假设的例子，如果100 Gbps管道可用并且有足够的工作，那么PL应该能够利用这一点并使用所有100 Gbps管道。为此提供了两种机制。第一个是批处理，第二个是命令管道。
Batching is the ability to send multiple commands (such as Config) in one Protocol Data Unit (PDU). The size of the batch will be affected by, among other things, the path MTU. The commands may be part of the same transaction or may be part of unrelated transactions that are independent of each other.
批处理是在一个协议数据单元（PDU）中发送多个命令（如Config）的能力。批处理的大小将受到路径MTU等因素的影响。这些命令可以是同一事务的一部分，也可以是相互独立的不相关事务的一部分。
Command pipelining allows for pipelining of independent transactions that do not affect each other. Each independent transaction could consist of one or more batches.
命令管道化允许对相互不影响的独立事务进行管道化。每个独立事务可以由一个或多个批组成。
There are several batching levels at different protocol hierarchies.
在不同的协议层次结构中有几个批处理级别。
o Multiple PL PDUs can be aggregated under one TML message.
o 可以在一条TML消息下聚合多个PL PDU。
o Multiple LFB classes and instances (as indicated in the LFB selector) can be addressed within one PL PDU.
o 可以在一个PL PDU中寻址多个LFB类和实例（如LFB选择器中所示）。
o Multiple operations can be addressed to a single LFB class and instance.
o 可以将多个操作寻址到单个LFB类和实例。
The protocol allows any number of messages to be issued by the CE before the corresponding acknowledgments (if requested) have been returned by the FE. Hence, pipelining is inherently supported by the protocol. Matching responses with requests messages can be done using the correlator field in the message header.
协议允许在FE返回相应的确认（如果请求）之前，CE发出任意数量的消息。因此，协议本身就支持流水线。可以使用消息头中的correlator字段将响应与请求消息进行匹配。
Heartbeats (HBs) between FEs and CEs are traffic sensitive. An HB is sent only if no PL traffic is sent between the CE and FE within a configured interval. This has the effect of reducing the amount of HB traffic in the case of busy PL periods.
FEs和CEs之间的心跳（HBs）对流量敏感。仅当在配置的间隔内CE和FE之间未发送PL通信时，才会发送HB。这具有在繁忙PL时段减少HB通信量的效果。
An HB can be sourced by either the CE or FE. When sourced by the CE, a response can be requested (similar to the ICMP ping protocol). The FE can only generate HBs in the case of being configured to do so by the CE. Refer to Section 7.3.1 and Section 7.10 for details.
HB可由CE或FE采购。当CE发出消息时，可以请求响应（类似于ICMP ping协议）。FE只能在CE配置为生成HBs的情况下生成HBs。详见第7.3.1节和第7.10节。
All PL messages operate on LFB constructs, as this provides more flexibility for future enhancements. This means that maintenance and configurability of FEs, NE, and the ForCES protocol itself MUST be expressed in terms of this LFB architecture. For this reason, special LFBs are created to accommodate this need.
所有PL消息都在LFB构造上操作，因为这为将来的增强提供了更大的灵活性。这意味着FEs、NE和ForCES协议本身的维护和可配置性必须用LFB体系结构表示。因此，创建特殊LFB以满足此需求。
In addition, this shows how the ForCES protocol itself can be controlled by the very same type of structures (LFBs) it uses to control functions such as IP forwarding, filtering, etc.
此外，这显示了ForCES协议本身如何由它用来控制诸如IP转发、过滤等功能的同一类型的结构（lfb）控制。
To achieve this, the following specialized LFBs are introduced:
为此，引入了以下专用LFB：
o FE Protocol LFB, which is used to control the ForCES protocol.
o FE协议LFB，用于控制ForCES协议。
o FE Object LFB, which is used to control components relative to the FE itself. Such components include FEState [RFC5812], vendor, etc.
o FE对象LFB，用于控制相对于FE本身的组件。此类组件包括FEState[RFC5812]、供应商等。
These LFBs are detailed in Section 7.3.
这些LFB详见第7.3节。
This section provides a very high level description of sample message sequences between a CE and an FE. For protocol message encoding refer to Section 6.1, and for the semantics of the protocol refer to Section 4.3.
本节对CE和FE之间的示例消息序列进行了非常高级的描述。协议消息编码参考第6.1节，协议语义参考第4.3节。
The associations among CEs and FEs are initiated via the Association Setup message from the FE. If a Setup Request is granted by the CE, a successful Setup Response message is sent to the FE. If CEs and FEs are operating in an insecure environment, then the security associations have to be established between them before any association messages can be exchanged. The TML MUST take care of establishing any security associations.
CE和FE之间的关联通过FE发出的关联设置消息启动。如果CE批准了设置请求，则会向FE发送成功的设置响应消息。如果CE和FEs在不安全的环境中运行，则必须在它们之间建立安全关联，然后才能交换任何关联消息。TML必须注意建立任何安全协会。
This is typically followed by capability query, topology query, etc. When the FE is ready to start processing the data path, it sets the FEO FEState component to OperEnable (refer to [RFC5812] for details) and reports it to the CE as such when it is first queried. Typically, the FE is expected to be ready to process the data path before it associates, but there may be rare cases where it needs time do some pre-processing -- in such a case, the FE will start in the OperDisable state and when it is ready will transition to the OperEnable state. An example of an FE starting in OperDisable then
随后通常是能力查询、拓扑查询等。当FE准备开始处理数据路径时，它会将FEO FEState组件设置为OperEnable（有关详细信息，请参阅[RFC5812]），并在第一次查询时将其报告给CE。通常情况下，FE在关联之前准备好处理数据路径，但在少数情况下可能需要时间进行一些预处理——在这种情况下，FE将在OperDisable状态下启动，准备就绪后将转换到OperEnable状态。FE在OperDisable中启动的示例
transitioning to OperEnable is illustrated in Figure 8. The CE could at any time also disable the FE's data path operations by setting the FEState to AdminDisable. The FE MUST NOT process packets during this state unless the CE sets the state back to OperEnable. These sequences of messages are illustrated in Figure 8 below.
转换到Operable如图8所示。CE还可以通过将FEState设置为AdminDisable，随时禁用FE的数据路径操作。除非CE将状态设置回OperEnable，否则FE不得在此状态期间处理数据包。这些消息序列如下图8所示。
FE PL CE PL
铁磷矿
| |
| Asso Setup Req |
|---------------------->|
| |
| Asso Setup Resp |
|<----------------------|
| |
| LFBx Query capability |
|<----------------------|
| |
| LFBx Query Resp |
|---------------------->|
| |
| FEO Query (Topology) |
|<----------------------|
| |
| FEO Query Resp |
|---------------------->|
| |
| FEO OperEnable Event |
|---------------------->|
| |
| Config FEO Adminup |
|<----------------------|
| |
| FEO Config-Resp |
|---------------------->|
| |
| |
| Asso Setup Req |
|---------------------->|
| |
| Asso Setup Resp |
|<----------------------|
| |
| LFBx Query capability |
|<----------------------|
| |
| LFBx Query Resp |
|---------------------->|
| |
| FEO Query (Topology) |
|<----------------------|
| |
| FEO Query Resp |
|---------------------->|
| |
| FEO OperEnable Event |
|---------------------->|
| |
| Config FEO Adminup |
|<----------------------|
| |
| FEO Config-Resp |
|---------------------->|
| |
Figure 8: Message Exchange between CE and FE to Establish an NE Association
图8：CE和FE之间的消息交换以建立NE关联
On successful completion of this state, the FE joins the NE.
成功完成此状态后，FE加入NE。
In this state, the FE is continuously updated or queried. The FE may also send asynchronous event notifications to the CE, synchronous Heartbeat messages, or Packet Redirect message to the CE. This continues until a termination (or deactivation) is initiated by either the CE or FE. Figure 9 below, helps illustrate this state.
在此状态下，FE将不断更新或查询。FE还可以向CE发送异步事件通知、同步心跳消息或向CE发送分组重定向消息。这将持续到CE或FE启动终止（或停用）为止。下面的图9有助于说明这种状态。
FE PL CE PL
铁磷矿
| |
| Heartbeat |
|<---------------------------->|
| |
| Heartbeat |
|----------------------------->|
| |
| Config-set LFBy (Event sub.) |
|<-----------------------------|
| |
| Config Resp LFBy |
|----------------------------->|
| |
| Config-set LFBx Component |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
|Config-Query LFBz (Stats) |
|<--------------------------- -|
| |
| Query Resp LFBz |
|----------------------------->|
| |
| FE Event Report |
|----------------------------->|
| |
| Config-Del LFBx Component |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
| Packet Redirect LFBx |
|----------------------------->|
| |
| Heartbeat |
|<-----------------------------|
. .
. .
| |
| |
| Heartbeat |
|<---------------------------->|
| |
| Heartbeat |
|----------------------------->|
| |
| Config-set LFBy (Event sub.) |
|<-----------------------------|
| |
| Config Resp LFBy |
|----------------------------->|
| |
| Config-set LFBx Component |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
|Config-Query LFBz (Stats) |
|<--------------------------- -|
| |
| Query Resp LFBz |
|----------------------------->|
| |
| FE Event Report |
|----------------------------->|
| |
| Config-Del LFBx Component |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
| Packet Redirect LFBx |
|----------------------------->|
| |
| Heartbeat |
|<-----------------------------|
. .
. .
| |
Figure 9: Message Exchange between CE and FE during Steady-State Communication
图9：稳态通信期间CE和FE之间的消息交换
Note that the sequence of messages shown in the figure serve only as examples and the message exchange sequences could be different from what is shown in the figure. Also, note that the protocol scenarios described in this section do not include all the different message exchanges that would take place during failover. That is described in the HA section (Section 8).
请注意，图中所示的消息序列仅用作示例，消息交换序列可能与图中所示不同。此外，请注意，本节中描述的协议场景不包括故障切换期间发生的所有不同消息交换。医管局部分（第8节）对此进行了描述。
The requirements below are expected to be met by the TML. This text does not define how such mechanisms are delivered. As an example, the mechanisms to meet the requirements could be defined to be delivered via hardware or between 2 or more TML software processes on different CEs or FEs in protocol-level schemes.
TML预计将满足以下要求。本文未定义此类机制的交付方式。例如，满足需求的机制可以定义为通过硬件或在协议级方案中的不同CE或FEs上的2个或多个TML软件进程之间交付。
Each TML MUST describe how it contributes to achieving the listed ForCES requirements. If for any reason a TML does not provide a service listed below, a justification needs to be provided.
每个TML必须说明其如何有助于实现列出的部队要求。如果出于任何原因，TML不提供下列服务，则需要提供理由。
Implementations that support the ForCES protocol specification MUST implement [RFC5811]. Note that additional TMLs might be specified in the future, and if a new TML defined in the future that meets the requirements listed here proves to be better, then the "MUST implement TML" may be redefined.
支持ForCES协议规范的实现必须实现[RFC5811]。请注意，将来可能会指定其他TML，如果将来定义的新TML满足此处列出的要求，则“必须实现TML”可能会重新定义。
1. Reliability
1. 可靠性
Various ForCES messages will require varying degrees of reliable delivery via the TML. It is the TML's responsibility to provide these shades of reliability and describe how the different ForCES messages map to reliability.
各种部队信息需要通过TML进行不同程度的可靠传递。TML有责任提供这些可靠性等级，并描述不同部队信息如何映射到可靠性。
The most common level of reliability is what we refer to as strict or robust reliability in which we mean no losses, corruption, or re-ordering of information being transported while ensuring message delivery in a timely fashion.
最常见的可靠性级别是我们所说的严格或稳健的可靠性，在这种可靠性中，我们意味着在确保消息及时传递的同时，不会丢失、损坏或重新排序正在传输的信息。
Payloads such as configuration from a CE and its response from an FE are mission critical and must be delivered in a robust reliable fashion. Thus, for information of this sort, the TML MUST either provide built-in protocol mechanisms or use a reliable transport protocol for achieving robust/strict reliability.
来自CE的配置及其来自FE的响应等有效负载是任务关键型的，必须以稳健可靠的方式交付。因此，对于此类信息，TML必须提供内置的协议机制或使用可靠的传输协议来实现健壮/严格的可靠性。
Some information or payloads, such as redirected packets or packet sampling, may not require robust reliability (can tolerate some degree of losses). For information of this sort, the TML could define to use a mechanism that is not strictly reliable (while conforming to other TML requirements such as congestion control).
某些信息或有效载荷，如重定向数据包或数据包采样，可能不需要可靠的可靠性（可以承受一定程度的损失）。对于此类信息，TML可以定义使用不严格可靠的机制（同时符合其他TML要求，如拥塞控制）。
Some information or payloads, such as heartbeat packets, may prefer timeliness over reliable delivery. For information of this sort, the TML could define to use a mechanism that is not strictly reliable (while conforming to other TML requirements such as congestion control).
一些信息或有效载荷，如心跳数据包，可能更喜欢及时性而不是可靠的传递。对于此类信息，TML可以定义使用不严格可靠的机制（同时符合其他TML要求，如拥塞控制）。
2. Security
2. 安全
TML provides security services to the ForCES PL. Because a ForCES PL is used to operate an NE, attacks designed to confuse, disable, or take information from a ForCES-based NE may be seen as a prime objective during a network attack.
TML向部队PL提供安全服务。由于部队PL用于操作网元，因此，在网络攻击期间，旨在混淆、禁用或获取基于部队的网元信息的攻击可能被视为主要目标。
An attacker in a position to inject false messages into a PL stream can affect either the FE's treatment of the data path (for example, by falsifying control data reported as coming from the CE) or the CE itself (by modifying events or responses reported as coming from the FE). For this reason, CE and FE node authentication and TML message authentication are important.
能够将虚假消息注入PL流的攻击者可以影响FE对数据路径的处理（例如，通过伪造报告来自CE的控制数据）或CE本身（通过修改报告来自FE的事件或响应）。因此，CE和FE节点身份验证以及TML消息身份验证非常重要。
The PL messages may also contain information of value to an attacker, including information about the configuration of the network, encryption keys, and other sensitive control data, so care must be taken to confine their visibility to authorized users.
PL消息还可能包含对攻击者有价值的信息，包括有关网络配置、加密密钥和其他敏感控制数据的信息，因此必须注意将其可见性限制在授权用户的范围内。
* The TML MUST provide a mechanism to authenticate ForCES CEs and FEs, in order to prevent the participation of unauthorized CEs and unauthorized FEs in the control and data path processing of a ForCES NE.
* TML必须提供验证部队CE和FEs的机制，以防止未经授权的CE和FEs参与部队NE的控制和数据路径处理。
* The TML SHOULD provide a mechanism to ensure message authentication of PL data transferred from the CE to FE (and vice versa), in order to prevent the injection of incorrect data into PL messages.
* TML应提供一种机制，以确保对从CE传输到FE的PL数据进行消息认证（反之亦然），以防止向PL消息中注入不正确的数据。
* The TML SHOULD provide a mechanism to ensure the confidentiality of data transferred from the ForCES PL, in order to prevent disclosure of PL-level information transported via the TML.
* TML应提供一种机制，确保从部队PL传输的数据的机密性，以防止通过TML传输的PL级信息泄露。
The TML SHOULD provide these services by employing TLS or IPsec.
TML应该通过使用TLS或IPsec来提供这些服务。
3. Congestion control
3. 拥塞控制
The transport congestion control scheme used by the TML needs to be defined. The congestion control mechanism defined by the TML MUST prevent transport congestive collapse [RFC2914] on either the FE or CE side.
需要定义TML使用的交通拥堵控制方案。TML定义的拥塞控制机制必须防止FE或CE侧的传输拥塞崩溃[RFC2914]。
4. Uni/multi/broadcast addressing/delivery, if any
4. 单/多/广播寻址/传送（如有）
If there is any mapping between PL- and TML-level uni/multi/ broadcast addressing, it needs to be defined.
如果PL级和TML级单/多/广播寻址之间存在任何映射，则需要对其进行定义。
5. HA decisions
5. 医管局的决定
It is expected that availability of transport links is the TML's responsibility. However, based upon its configuration, the PL may wish to participate in link failover schemes and therefore the TML MUST support this capability.
预计运输链路的可用性是TML的责任。然而，根据其配置，PL可能希望参与链路故障切换方案，因此TML必须支持此功能。
Please refer to Section 8 for details.
详情请参阅第8节。
6. Encapsulations used
6. 使用的封装
Different types of TMLs will encapsulate the PL messages on different types of headers. The TML needs to specify the encapsulation used.
不同类型的TML将在不同类型的头上封装PL消息。TML需要指定所使用的封装。
7. Prioritization
7. 优先次序
It is expected that the TML will be able to handle up to 8 priority levels needed by the PL and will provide preferential treatment.
预计TML将能够处理PL所需的多达8个优先级，并将提供优惠待遇。
While the TML needs to define how this is achieved, it should be noted that the requirement for supporting up to 8 priority levels does not mean that the underlying TML MUST be capable of providing up to 8 actual priority levels. In the event that the underlying TML layer does not have support for 8 priority levels, the supported priority levels should be divided between the available TML priority levels. For example, if the TML only supports 2 priority levels, 0-3 could go in one TML priority level, while 4-7 could go in the other.
虽然TML需要定义如何实现这一点，但应注意，支持多达8个优先级的要求并不意味着基础TML必须能够提供多达8个实际优先级。如果底层TML层不支持8个优先级，则支持的优先级应在可用TML优先级之间划分。例如，如果TML仅支持2个优先级，则0-3可以进入一个TML优先级，而4-7可以进入另一个优先级。
The TML MUST NOT re-order config packets with the same priority.
TML不得重新排序具有相同优先级的配置数据包。
8. Node Overload Prevention
8. 节点过载预防
The TML MUST define mechanisms it uses to help prevent node overload.
TML必须定义用于帮助防止节点过载的机制。
Overload results in starvation of node compute cycles and/or bandwidth resources, which reduces the operational capacity of a ForCES NE. NE node overload could be deliberately instigated by a hostile node to attack a ForCES NE and create a denial of service (DoS). It could also be created by a variety of other reasons such as large control protocol updates (e.g., BGP flaps), which consequently cause a high frequency of CE to FE table updates, HA failovers, or component failures, which migrate an FE or CE load overwhelming the new CE or FE, etc. Although the environments under which SIP and ForCES operate are different, [RFC5390] provides a good guide to generic node requirements one needs to guard for.
过载会导致节点计算周期和/或带宽资源不足，从而降低网元的操作能力。恶意节点可能故意煽动网元节点过载，以攻击一个网元并创建拒绝服务（DoS）。它也可能是由多种其他原因造成的，例如大型控制协议更新（例如，BGP襟翼），这会导致频繁的CE-to-FE表更新、HA故障切换或组件故障，从而迁移FE或CE负载，压倒新的CE或FE，等等。尽管SIP和ForCES运行的环境不同，[RFC5390]提供了一个很好的指南，说明需要防范的通用节点需求。
A ForCES node CPU may be overwhelmed because the incoming packet rate is higher than it can keep up with -- in such a case, a node's transport queues grow and transport congestion subsequently follows. A ForCES node CPU may also be adversely overloaded with very few packets, i.e., no transport congestion at all (e.g., a in a DoS attack against a table hashing algorithm that overflows the table and/or keeps the CPU busy so it does not process other tasks). The TML node overload solution specified MUST address both types of node overload scenarios.
由于传入的数据包速率高于它所能跟上的速度，强制节点CPU可能会被压垮——在这种情况下，节点的传输队列会增加，随后会出现传输拥塞。ForCES节点CPU也可能因极少的数据包而严重过载，即根本没有传输拥塞（例如，针对表哈希算法的DoS攻击中的数据包溢出表和/或使CPU处于繁忙状态，因此不会处理其他任务）。指定的TML节点重载解决方案必须解决这两种类型的节点重载场景。
It is expected that it should be possible to use a configuration reference point, such as the FEM or the CEM, to configure the TML.
预计可以使用配置参考点（如FEM或CEM）来配置TML。
Some of the configured parameters may include:
一些配置参数可能包括：
o PL ID
o PL ID
o Connection Type and associated data. For example, if a TML uses IP/TCP/UDP, then parameters such as TCP and UDP port and IP addresses need to be configured.
o 连接类型和关联数据。例如，如果TML使用IP/TCP/UDP，则需要配置TCP和UDP端口以及IP地址等参数。
o Number of transport connections
o 传输连接数
o Connection capability, such as bandwidth, etc.
o 连接能力，如带宽等。
o Allowed/supported connection QoS policy (or congestion control policy)
o 允许/支持的连接QoS策略（或拥塞控制策略）
All PL PDUs start with a common header Section 6.1 followed by one or more TLVs Section 6.2, which may nest other TLVs Section 6.2.1. All fields are in network byte order.
所有PL PDU都以公共标题第6.1节开始，然后是一个或多个TLV第6.2节，这可能嵌套其他TLV第6.2.1节。所有字段均按网络字节顺序排列。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| rsvd | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[63:32] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[31:0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| rsvd | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[63:32] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[31:0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Common Header
图10：公共标题
The message is 32-bit aligned.
消息是32位对齐的。
Version (4 bits): Version number. Current version is 1.
版本（4位）：版本号。当前版本为1。
rsvd (4 bits): Unused at this point. A receiver should not interpret this field. Senders MUST set it to zero and receivers MUST ignore this field.
rsvd（4位）：此时未使用。接收者不应解释此字段。发送方必须将其设置为零，接收方必须忽略此字段。
Message Type (8 bits): Commands are defined in Section 7.
消息类型（8位）：命令在第7节中定义。
Length (16 bits): length of header + the rest of the message in DWORDS (4-byte increments).
长度（16位）：报头的长度+消息的其余部分（以DWORD为单位）（以4字节为增量）。
Source ID (32 bits):
源ID（32位）：
Dest ID (32 bits):
目标ID（32位）：
* Each of the source and destination IDs are 32-bit IDs that are unique NE-wide and that identify the termination points of a ForCES PL message.
* 每个源ID和目标ID都是32位ID，在整个网元范围内是唯一的，用于标识ForCES PL消息的终止点。
* IDs allow multi/broad/unicast addressing with the following approach:
* IDs允许使用以下方法进行多/宽/单播寻址：
a. A split address space is used to distinguish FEs from CEs. Even though in a large NE there are typically two or more orders of magnitude of more FEs than CEs, the address space is split uniformly for simplicity.
a. 分割地址空间用于区分FEs和CEs。即使在大型网元中，FEs通常比CEs多两个或两个以上数量级，为了简单起见，地址空间被均匀分割。
b. The address space allows up to 2^30 (over a billion) CEs and the same amount of FEs.
b. 地址空间最多允许2^30（超过十亿）个CE和相同数量的FEs。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TS | sub-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TS | sub-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ForCES ID Format
图11：部队ID格式
c. The 2 most significant bits called Type Switch (TS) are used to split the ID space as follows:
c. 称为类型开关（TS）的2个最高有效位用于按如下方式分割ID空间：
TS Corresponding ID range Assignment
-- ---------------------- ----------
0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30)
0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30)
0b10 0x80000000 to 0xBFFFFFFF reserved
0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16)
0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved
0b11 0xFFFFFFFD all CEs broadcast
0b11 0xFFFFFFFE all FEs broadcast
0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast
TS Corresponding ID range Assignment
-- ---------------------- ----------
0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30)
0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30)
0b10 0x80000000 to 0xBFFFFFFF reserved
0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16)
0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved
0b11 0xFFFFFFFD all CEs broadcast
0b11 0xFFFFFFFE all FEs broadcast
0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast
Figure 12: Type Switch ID Space
图12：类型开关ID空间
* Multicast or broadcast IDs are used to group endpoints (such as CEs and FEs). As an example, one could group FEs in some functional group, by assigning a multicast ID. Likewise, subgroups of CEs that act, for instance, in a back-up mode may be assigned a multicast ID to hide them from the FE.
* 多播或广播ID用于对端点（如CE和FEs）进行分组。例如，可以通过分配多播ID将FEs分组到某个功能组中。类似地，例如，在备份模式中起作用的ce的子组可以被分配多播ID以对FE隐藏它们。
+ Multicast IDs can be used for both source or destination IDs.
+ 多播ID可用于源ID或目标ID。
+ Broadcast IDs can be used only for destination IDs.
+ 广播ID只能用于目标ID。
* This document does not discuss how a particular multicast ID is associated to a given group though it could be done via configuration process. The list of IDs an FE owns or is part of are listed on the FE Object LFB.
* 本文档不讨论特定多播ID如何与给定组关联，尽管可以通过配置过程来实现。FE拥有或是其一部分的ID列表列在FE对象LFB上。
Correlator (64 bits):
相关器（64位）：
This field is set by the CE to correlate ForCES Request messages with the corresponding Response messages from the FE. Essentially, it is a cookie. The correlator is handled transparently by the FE, i.e., for a particular Request message the FE MUST assign the same correlator value in the corresponding Response message. In the case where the message from the CE does not elicit a response, this field may not be useful.
CE将此字段设置为将强制请求消息与FE的相应响应消息关联起来。本质上，它是一块饼干。FE透明地处理相关器，即，对于特定的请求消息，FE必须在相应的响应消息中分配相同的相关器值。如果来自CE的消息未引发响应，则此字段可能不有用。
The correlator field could be used in many implementations in specific ways by the CE. For example, the CE could split the correlator into a 32-bit transactional identifier and 32-bit message sequence identifier. Another example is a 64-bit pointer to a context block. All such implementation-specific uses of the correlator are outside the scope of this specification.
correlator字段可以由CE以特定的方式在许多实现中使用。例如，CE可以将相关器拆分为32位事务标识符和32位消息序列标识符。另一个示例是指向上下文块的64位指针。correlator的所有这些特定于实现的用途都不在本规范的范围内。
It should be noted that the correlator is transmitted on the network as if it were a 64-bit unsigned integer with the leftmost or most significant octet (bits 63-56) transmitted first.
应该注意的是，相关器在网络上传输时，就好像它是一个64位无符号整数，其中最左边或最重要的八位字节（位63-56）首先传输一样。
Whenever the correlator field is not relevant, because no message is expected, the correlator field is set to 0.
每当correlator字段不相关时（因为不需要任何消息），correlator字段将设置为0。
Flags (32 bits): Identified so far:
标志（32位）：到目前为止已识别：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | |
|ACK| Pri |Rsr |EM |A|TP | Reserved |
| | | vd. | |T| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | |
|ACK| Pri |Rsr |EM |A|TP | Reserved |
| | | vd. | |T| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Header Flags
图13：标题标志
- ACK: ACK indicator (2 bits)
- 确认：确认指示器（2位）
The ACK indicator flag is only used by the CE when sending a Config message (Section 7.6.1) or an HB message (Section 7.10) to indicate to the message receiver whether or not a response is required by the sender. Note that for all other messages than the Config message or the HB message this flag MUST be ignored.
ACK指示符标志仅由CE在发送配置消息（第7.6.1节）或HB消息（第7.10节）时使用，以指示消息接收方发送方是否需要响应。请注意，对于配置消息或HB消息以外的所有其他消息，必须忽略此标志。
The flag values are defined as follows:
标志值定义如下：
'NoACK' (0b00) - to indicate that the message receiver MUST NOT send any Response message back to this message sender.
“NoACK”（0b00）-表示消息接收方不得将任何响应消息发送回此消息发送方。
'SuccessACK'(0b01) - to indicate that the message receiver MUST send a Response message back only when the message has been successfully processed by the receiver.
“SuccessACK”（0b01）-表示只有在接收方成功处理消息时，消息接收方才必须发回响应消息。
'FailureACK'(0b10) - to indicate that the message receiver MUST send a Response message back only when there is failure by the receiver in processing (executing) the message. In other words, if the message can be processed successfully, the sender will not expect any response from the receiver.
“FailureACK”（0b10）-表示只有当接收方在处理（执行）消息时出现故障时，消息接收方才必须发回响应消息。换句话说，如果消息能够成功处理，发送方将不会期望接收方做出任何响应。
'AlwaysACK' (0b11) - to indicate that the message receiver MUST send a Response message.
“AlwaysACK”（0b11）-指示消息接收方必须发送响应消息。
Note that in above definitions, the term success implies a complete execution without any failure of the message. Anything else than a complete successful execution is defined as a failure for the message processing. As a result, for the execution modes (defined in Section 4.3.1.1) like execute-all-or-none, execute-until-failure, and continue-execute-on-failure, if any single operation among several operations in the same message fails, it will be treated as a failure and result in a response if the ACK indicator has been set to 'FailureACK' or 'AlwaysACK'.
请注意，在上述定义中，术语success意味着在消息没有任何失败的情况下完成执行。如果执行不完全成功，则定义为消息处理失败。因此，对于执行模式（在第4.3.1.1节中定义），如执行全部或无、执行直到失败，以及在失败时继续执行，如果同一消息中的多个操作中的任何单个操作失败，则将被视为失败，并且如果ACK指示符设置为“FailureACK”或“AlwaysACK”，则会产生响应。
Also note that, other than in Config and HB messages, requirements for responses of messages are all given in a default way rather than by ACK flags. The default requirements of these messages and the expected responses are summarized below. Detailed descriptions can be found in the individual message definitions:
还要注意的是，除了Config和HB消息之外，消息响应的要求都是以默认方式给出的，而不是通过ACK标志给出的。这些消息的默认要求和预期响应总结如下。详细说明可在各个消息定义中找到：
+ Association Setup message always expects a response.
+ 关联设置消息始终需要响应。
+ Association Teardown Message, and Packet Redirect message, never expect responses.
+ 关联拆卸消息和数据包重定向消息永远不需要响应。
+ Query message always expects a response.
+ 查询消息始终需要响应。
+ Response message never expects further responses.
+ 响应消息从不要求进一步的响应。
- Pri: Priority (3 bits)
- 优先级：优先级（3位）
ForCES protocol defines 8 different levels of priority (0-7). The priority level can be used to distinguish between different protocol message types as well as between the same message type. The higher the priority value, the more important the PDU is. For example, the REDIRECT packet message could have different priorities to distinguish between routing protocol packets and ARP packets being redirected from FE to CE. The normal priority level is 1. The different priorities imply messages could be re-ordered; however, re-ordering is undesirable when it comes to a set of messages within a transaction and caution should be exercised to avoid this.
ForCES协议定义了8种不同的优先级（0-7）。优先级可用于区分不同协议消息类型以及相同消息类型。优先级值越高，PDU越重要。例如，重定向分组消息可以具有不同的优先级来区分路由协议分组和从FE重定向到CE的ARP分组。正常优先级为1。不同的优先级意味着消息可以重新排序；但是，当涉及到事务中的一组消息时，重新排序是不可取的，应谨慎避免这种情况。
- EM: Execution Mode (2 bits)
- EM：执行模式（2位）
There are 3 execution modes; refer to Section 4.3.1.1 for details.
有3种执行模式；详见第4.3.1.1节。
Reserved..................... (0b00)
Reserved..................... (0b00)
`execute-all-or-none` ....... (0b01)
`execute-all-or-none` ....... (0b01)
`execute-until-failure` ..... (0b10)
`execute-until-failure` ..... (0b10)
`continue-execute-on-failure` (0b11)
`失败时继续执行“”（0b11）
- AT: Atomic Transaction (1 bit)
- AT：原子事务（1位）
This flag indicates if the message is a stand-alone message or one of multiple messages that belong to 2PC transaction operations. See Section 4.3.1.2.2 for details.
此标志指示消息是独立消息还是属于2PC事务操作的多条消息之一。详见第4.3.1.2.2节。
Stand-alone message ......... (0b0)
Stand-alone message ......... (0b0)
2PC transaction message ..... (0b1)
2PC transaction message ..... (0b1)
- TP: Transaction Phase (2 bits)
- TP：事务阶段（2位）
A message from the CE to the FE within a transaction could be indicative of the different phases the transaction is in. Refer to Section 4.3.1.2.2 for details.
在交易中，从CE到FE的消息可以指示交易所处的不同阶段。详见第4.3.1.2.2节。
SOT (start of transaction) ..... (0b00)
SOT (start of transaction) ..... (0b00)
MOT (middle of transaction) .... (0b01)
MOT (middle of transaction) .... (0b01)
EOT (end of transaction) ........(0b10)
EOT (end of transaction) ........(0b10)
ABT (abort) .....................(0b11)
ABT (abort) .....................(0b11)
TLVs are extensively used by the ForCES protocol. TLVs have some very nice properties that make them a good candidate for encoding the XML definitions of the LFB class model. These are:
部队协议广泛使用TLV。TLV有一些非常好的属性，使其成为编码LFB类模型的XML定义的很好候选。这些是：
o Providing for binary type-value encoding that is close to the XML string tag-value scheme.
o 提供接近XML字符串标记值方案的二进制类型值编码。
o Allowing for fast generalized binary-parsing functions.
o 允许快速的通用二进制解析函数。
o Allowing for forward and backward tag compatibility. This is equivalent to the XML approach, i.e., old applications can ignore new TLVs and newer applications can ignore older TLVs.
o 允许向前和向后标记兼容性。这相当于XML方法，即旧的应用程序可以忽略新的TLV，而新的应用程序可以忽略旧的TLV。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Essentially the TLV Data) |
~ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Essentially the TLV Data) |
~ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: TLV Representation
图14：TLV表示
TLV Type (16):
TLV类型（16）：
The TLV type field is 2 octets, and semantically indicates the type of data encapsulated within the TLV.
TLV类型字段是2个八位字节，语义上表示TLV中封装的数据类型。
TLV Length (16):
TLV长度（16）：
The TLV length field is 2 octets, and includes the length of the TLV type (2 octets), TLV Length (2 octets), and the length of the TLV data found in the value field, in octets. Note that this length is the actual length of the value, before any padding for alignment is added.
TLV长度字段为2个八位字节，包括TLV类型的长度（2个八位字节）、TLV长度（2个八位字节）以及在值字段中找到的TLV数据的长度（以八位字节为单位）。请注意，此长度是添加对齐填充之前值的实际长度。
TLV Value (variable):
TLV值（变量）：
The TLV value field carries the data. For extensibility, the TLV value may in fact be a TLV. Padding is required when the length is not a multiple of 32 bits, and is the minimum number of octets required to bring the TLV to a multiple of 32 bits. The length of the value before padding is indicated by the TLV Length field.
TLV值字段携带数据。为了扩展性，TLV值实际上可能是一个TLV。当长度不是32位的倍数时，需要填充，填充是使TLV达到32位倍数所需的最小八位字节数。填充前值的长度由TLV长度字段指示。
Note: The value field could be empty, which implies the minimal length a TLV could be is 4 (length of "T" field and length of "L" field).
注意：值字段可以为空，这意味着TLV的最小长度可以是4（“T”字段的长度和“L”字段的长度）。
TLV values can be other TLVs. This provides the benefits of protocol flexibility (being able to add new extensions by introducing new TLVs when needed). The nesting feature also allows for a conceptual optimization with the XML LFB definitions to binary PL representation (represented by nested TLVs).
TLV值可以是其他TLV。这提供了协议灵活性的好处（能够在需要时通过引入新的TLV来添加新的扩展）。嵌套特性还允许使用XML LFB定义对二进制PL表示（由嵌套TLV表示）进行概念优化。
There are two global name scopes for the "Type" in the TLV. The first name scope is for OPER-TLVs and is defined in A.4 whereas the second name scope is outside OPER-TLVs and is defined in section A.2.
TLV中的“类型”有两个全局名称作用域。第一个名称范围用于操作TLV，在A.4中定义，而第二个名称范围在操作TLV之外，在A.2节中定义。
The ILV is a slight variation of the TLV. This sets the type ("T") to be a 32-bit local index that refers to a ForCES component ID (refer to Section 6.4.1).
ILV是TLV的微小变化。这将类型（“T”）设置为一个32位本地索引，该索引引用一个力组件ID（参考第6.4.1节）。
The ILV length field is a 4-octet integer, and includes the length of the ILV type (4 octets), ILV Length (4 octets), and the length of the ILV data found in the value field, in octets. Note that, as in the case of the TLV, this length is the actual length of the value, before any padding for alignment is added.
ILV长度字段是4个八位的整数，包括ILV类型的长度（4个八位）、ILV长度（4个八位）以及在值字段中找到的ILV数据的长度（以八位为单位）。请注意，与TLV的情况一样，此长度是添加任何对齐填充之前值的实际长度。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ILV Representation
图15:ILV表示法
It should be noted that the "I" values are of local scope and are defined by the data declarations from the LFB definition. Refer to Section 7.1.8 for discussions on usage of ILVs.
应该注意，“I”值是局部范围的，由LFB定义中的数据声明定义。有关ILV使用的讨论，请参阅第7.1.8节。
In this section, we review a few encapsulation concepts that are used by the ForCES protocol for its operations.
在本节中，我们将回顾ForCES协议在其操作中使用的一些封装概念。
We briefly re-introduce two concepts, paths, and keys, from the ForCES model [RFC5812] in order to provide context. The reader is referred to [RFC5812] for a lot of the finer details.
为了提供上下文，我们从ForCES模型[RFC5812]简要地重新介绍了两个概念，路径和键。读者可参考[RFC5812]了解更多更详细的信息。
For readability reasons, we introduce the encapsulation schemes that are used to carry content in a protocol message, namely, FULLDATA-TLV, SPARSEDATA-TLV, and RESULT-TLV.
出于可读性原因，我们介绍了用于在协议消息中承载内容的封装方案，即FULLDATA-TLV、SPARA-TLV和RESULT-TLV。
The ForCES model [RFC5812] defines an XML-based language that allows for a formal definition of LFBs. This is similar to the relationship between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB and ASN.1 being analogous to the XML model language). Any entity that the CE configures on an FE MUST be formally defined in an LFB. These entities could be scalars (e.g., a 32-bit IPv4 address) or vectors (such as a nexthop table). Each entity within the LFB is given a numeric 32-bit identifier known as a "component id". This scheme allows the component to be "addressed" in a protocol construct.
ForCES模型[RFC5812]定义了一种基于XML的语言，允许对LFB进行正式定义。这类似于ASN.1和SNMP MIB定义之间的关系（MIB类似于LFB，ASN.1类似于XML模型语言）。CE在FE上配置的任何实体必须在LFB中正式定义。这些实体可以是标量（例如32位IPv4地址）或向量（例如nexthop表）。LFB中的每个实体都有一个称为“组件id”的32位数字标识符。此方案允许在协议构造中“寻址”组件。
These addressable entities could be hierarchical (e.g., a table column or a cell within a table row). In order to address hierarchical data, the concept of a path is introduced by the model [RFC5812]. A path is a series of 32-bit component IDs that are typically presented in a dot-notation (e.g., 1.2.3.4). Section 7 formally defines how paths are used to reference data that is being encapsulated within a protocol message.
这些可寻址实体可以是分层的（例如，表列或表行中的单元格）。为了处理分层数据，模型[RFC5812]引入了路径的概念。路径是一系列32位组件ID，通常以点表示法表示（例如，1.2.3.4）。第7节正式定义了如何使用路径引用封装在协议消息中的数据。
The ForCES model [RFC5812] defines two ways to address table rows. The standard/common mechanism is to allow table rows to be referenced by a 32-bit index. The secondary mechanism is via keys that allow for content addressing. An example key is a multi-field content key that uses the IP address and prefix length to uniquely reference an IPv4 routing table row. In essence, while the common scheme to address a table row is via its table index, a table row's path could be derived from a key. The KEYINFO-TLV (Section 7) is used to carry the data that is used to do the lookup.
ForCES模型[RFC5812]定义了两种寻址表行的方法。标准/通用机制是允许表行被32位索引引用。第二种机制是通过允许内容寻址的键。示例键是一个多字段内容键，它使用IP地址和前缀长度唯一地引用IPv4路由表行。本质上，虽然处理表行的通用方案是通过表索引，但表行的路径可以从键派生。KEYINFO-TLV（第7节）用于携带用于查找的数据。
Data from or to the FE is carried in two types of TLVs: FULLDATA-TLV and SPARSEDATA-TLV. Responses to operations executed by the FE are carried in RESULT-TLVs.
FE的数据以两种类型的TLV传输：FULLDATA-TLV和SPARA-TLV。FE执行的操作响应在结果TLV中进行。
In FULLDATA-TLV, the data is encoded in such a way that a receiver of such data, by virtue of being armed with knowledge of the path and the LFB definition, can infer or correlate the TLV "Value" contents. This is essentially an optimization that helps reduce the amount of description required for the transported data in the protocol grammar. Refer to Appendix C for an example of FULLDATA-TLVs.
在FULLDATA-TLV中，数据被编码为这样一种方式，即借助于对路径和LFB定义的了解，此类数据的接收器可以推断或关联TLV“值”内容。这本质上是一种优化，有助于减少协议语法中传输数据所需的描述量。有关FULLDATA TLV的示例，请参阅附录C。
A number of operations in ForCES will need to reference optional data within larger structures. The SPARSEDATA-TLV encoding is provided to make it easier to encapsulate optionally appearing data components. Refer to Appendix C for an example of SPARSEDATA-TLV.
部队中的许多行动将需要参考较大结构中的可选数据。提供了SPARA-TLV编码，以便于封装可选出现的数据组件。有关SPARA-TLV的示例，请参阅附录C。
RESULT-TLVs carry responses back from the FE based on a config issued by the CE. Refer to Appendix C for examples of RESULT-TLVs and Section 7.1.7 for layout.
结果TLV根据CE发布的配置从FE带回响应。结果TLV示例见附录C，布局见第7.1.7节。
Section 6.4.1 and Section 6.4.2 discuss how to target an entity within an LFB. However, the addressing mechanism used requires that an LFB type and instance are selected first. The LFB selector is used to select an LFB type and instance being targeted. Section 7 goes into more details; for our purpose, we illustrate this concept using Figure 16 below. More examples of layouts can be found reading further into the text (example: Figure 22).
第6.4.1节和第6.4.2节讨论了如何针对LFB中的实体。但是，使用的寻址机制要求首先选择LFB类型和实例。LFB选择器用于选择目标LFB类型和实例。第7节更为详细；出于我们的目的，我们使用下面的图16来说明这个概念。更多的布局示例可以在本文中找到（示例：图22）。
main hdr (Message type: example "config")
|
|
|
+- T = LFBselect
|
+-- LFBCLASSID (unique per LFB defined)
|
|
+-- LFBInstance (runtime configuration)
|
+-- T = An operation TLV describes what we do to an entity
| //Refer to the OPER-TLV values enumerated below
| //the TLVs that can be used for operations
|
|
+--+-- one or more path encodings to target an entity
| // Refer to the discussion on keys and paths
|
|
+-- The associated data, if any, for the entity
// Refer to discussion on FULL/SPARSE DATA TLVs
main hdr (Message type: example "config")
|
|
|
+- T = LFBselect
|
+-- LFBCLASSID (unique per LFB defined)
|
|
+-- LFBInstance (runtime configuration)
|
+-- T = An operation TLV describes what we do to an entity
| //Refer to the OPER-TLV values enumerated below
| //the TLVs that can be used for operations
|
|
+--+-- one or more path encodings to target an entity
| // Refer to the discussion on keys and paths
|
|
+-- The associated data, if any, for the entity
// Refer to discussion on FULL/SPARSE DATA TLVs
Figure 16: Entity Addressing
图16：实体寻址
A protocol layer PDU consists of a common header (defined in Section 6.1 ) and a message body. The common header is followed by a message-type-specific message body. Each message body is formed from one or more top-level TLVs. A top-level TLV may contain one or more sub-TLVs; these sub-TLVs are described in this document as OPER-TLVs, because they describe an operation to be done.
协议层PDU由一个公共头（定义见第6.1节）和一个消息体组成。公共标头后面是消息类型特定的消息正文。每个消息体由一个或多个顶级TLV组成。顶级TLV可包含一个或多个子TLV；这些子TLV在本文档中被描述为OPER TLV，因为它们描述了要执行的操作。
+-------------+---------------+---------------------+---------------+
| Message | Top-Level TLV | OPER-TLV(s) | Reference |
| Name | | | |
+-------------+---------------+---------------------+---------------+
| Association | (LFBselect)* | REPORT | Section 7.5.1 |
| Setup | | | |
| Association | ASRresult-TLV | none | Section 7.5.2 |
| Setup | | | |
| Response | | | |
| Association | ASTreason-TLV | none | Section 7.5.3 |
| Teardown | | | |
| Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 |
| | | DEL | COMMIT | | |
| | | TRCOMP)+ | |
| Config | (LFBselect)+ | (SET-RESPONSE | | Section 7.6.2 |
| Response | | SET-PROP-RESPONSE | | |
| | | DEL-RESPONSE | | |
| | | COMMIT-RESPONSE)+ | |
| Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 |
| Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 |
| Response | | GET-PROP-RESPONSE)+ | |
| Event | LFBselect | REPORT | Section 7.8 |
| Notifi- | | | |
| cation | | | |
| Packet | REDIRECT-TLV | none | Section 7.9 |
| Redirect | | | |
| Heartbeat | none | none | Section 7.10 |
+-------------+---------------+---------------------+---------------+
+-------------+---------------+---------------------+---------------+
| Message | Top-Level TLV | OPER-TLV(s) | Reference |
| Name | | | |
+-------------+---------------+---------------------+---------------+
| Association | (LFBselect)* | REPORT | Section 7.5.1 |
| Setup | | | |
| Association | ASRresult-TLV | none | Section 7.5.2 |
| Setup | | | |
| Response | | | |
| Association | ASTreason-TLV | none | Section 7.5.3 |
| Teardown | | | |
| Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 |
| | | DEL | COMMIT | | |
| | | TRCOMP)+ | |
| Config | (LFBselect)+ | (SET-RESPONSE | | Section 7.6.2 |
| Response | | SET-PROP-RESPONSE | | |
| | | DEL-RESPONSE | | |
| | | COMMIT-RESPONSE)+ | |
| Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 |
| Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 |
| Response | | GET-PROP-RESPONSE)+ | |
| Event | LFBselect | REPORT | Section 7.8 |
| Notifi- | | | |
| cation | | | |
| Packet | REDIRECT-TLV | none | Section 7.9 |
| Redirect | | | |
| Heartbeat | none | none | Section 7.10 |
+-------------+---------------+---------------------+---------------+
Table 1
表1
The different messages are illustrated in Table 1. The different message type numerical values are defined in Appendix A.1. All the TLV values are defined in Appendix A.2.
不同的信息如表1所示。附录A.1中定义了不同的消息类型数值。附录A.2中定义了所有TLV值。
An LFBselect TLV (refer to Section 7.1.5) contains the LFB Classid and LFB instance being referenced as well as the OPER-TLV(s) being applied to that reference.
LFB选择TLV（参考第7.1.5节）包含被引用的LFB Classid和LFB实例以及应用于该引用的OPER-TLV。
Each type of OPER-TLV is constrained as to how it describes the paths and selectors of interest. The following BNF describes the basic structure of an OPER-TLV and Table 2 gives the details for each type.
每种类型的OPER-TLV都受到如何描述感兴趣的路径和选择器的限制。以下BNF描述了OPER-TLV的基本结构，表2给出了每种类型的详细信息。
OPER-TLV := 1*PATH-DATA-TLV
PATH-DATA-TLV := PATH [DATA]
PATH := flags IDcount IDs [SELECTOR]
SELECTOR := KEYINFO-TLV
DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV /
1*PATH-DATA-TLV
KEYINFO-TLV := KeyID FULLDATA-TLV
FULLDATA-TLV := encoded data component which may nest
further FULLDATA-TLVs
SPARSEDATA-TLV := encoded data that may have optionally
appearing components
RESULT-TLV := Holds result code and optional FULLDATA-TLV
OPER-TLV := 1*PATH-DATA-TLV
PATH-DATA-TLV := PATH [DATA]
PATH := flags IDcount IDs [SELECTOR]
SELECTOR := KEYINFO-TLV
DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV /
1*PATH-DATA-TLV
KEYINFO-TLV := KeyID FULLDATA-TLV
FULLDATA-TLV := encoded data component which may nest
further FULLDATA-TLVs
SPARSEDATA-TLV := encoded data that may have optionally
appearing components
RESULT-TLV := Holds result code and optional FULLDATA-TLV
Figure 17: BNF of OPER-TLV
图17:OPER-TLV的BNF
o PATH-DATA-TLV identifies the exact component targeted and may have zero or more paths associated with it. The last PATH-DATA-TLV in the case of nesting of paths via the DATA construct in the case of SET, SET-PROP requests, and GET-RESPONSE/GET-PROP-RESPONSE is terminated by encoded data or response in the form of either FULLDATA-TLV or SPARSEDATA-TLV or RESULT-TLV.
o PATH-DATA-TLV识别目标组件，可能有零条或多条与之关联的路径。在SET、SET-PROP请求和GET-RESPONSE/GET-PROP-RESPONSE情况下，通过数据结构嵌套路径的最后一个PATH-DATA-TLV由编码数据或FULLDATA-TLV或SPARA-TLV或RESULT-TLV形式的响应终止。
o PATH provides the path to the data being referenced.
o PATH提供被引用数据的路径。
* flags (16 bits) are used to further refine the operation to be applied on the path. More on these later.
* 标志（16位）用于进一步细化要应用于路径的操作。稍后将详细介绍这些。
* IDcount (16 bits): count of 32-bit IDs
* IDcount（16位）：32位ID的计数
* IDs: zero or more 32-bit IDs (whose count is given by IDcount) defining the main path. Depending on the flags, IDs could be field IDs only or a mix of field and dynamic IDs. Zero is used for the special case of using the entirety of the containing context as the result of the path.
* IDs：定义主路径的零个或多个32位ID（其计数由IDcount给出）。根据标志的不同，ID可以是字段ID，也可以是字段ID和动态ID的混合。零用于将整个包含上下文用作路径结果的特殊情况。
o SELECTOR is an optional construct that further defines the PATH. Currently, the only defined selector is the KEYINFO-TLV, used for selecting an array entry by the value of a key field. The presence of a SELECTOR is correct only when the flags also indicate its presence.
o 选择器是进一步定义路径的可选构造。目前，唯一定义的选择器是KEYINFO-TLV，用于通过键字段的值选择数组条目。只有当标志也指示选择器存在时，选择器的存在才是正确的。
o A KEYINFO-TLV contains information used in content keying.
o KEYINFO-TLV包含内容键控中使用的信息。
* A 32-bit KeyID is used in a KEYINFO-TLV. It indicates which key for the current array is being used as the content key for array entry selection.
* KEYINFO-TLV中使用32位KeyID。它指示当前数组的哪个键用作数组项选择的内容键。
* The key's data is the data to look for in the array, in the fields identified by the key field. The information is encoded according to the rules for the contents of a FULLDATA-TLV, and represents the field or fields that make up the key identified by the KeyID.
* 键的数据是要在数组中、由键字段标识的字段中查找的数据。该信息根据FULLDATA-TLV的内容规则进行编码，并表示组成由KeyID标识的密钥的一个或多个字段。
o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV, or 1 or more further PATH-DATA selections. FULLDATA-TLV and SPARSEDATA-TLV are only allowed on SET or SET-PROP requests, or on responses that return content information (GET-RESPONSE, for example). PATH-DATA may be included to extend the path on any request.
o 数据可能包含FULLDATA-TLV、SPARA-TLV、RESULT-TLV或1个或多个进一步的PATH-DATA选择。FULLDATA-TLV和SPARA-TLV仅允许用于SET或SET-PROP请求，或用于返回内容信息的响应（例如GET-RESPONSE）。可包括PATH-DATA以根据任何请求扩展路径。
* Note: Nested PATH-DATA-TLVs are supported as an efficiency measure to permit common subexpression extraction.
* 注意：嵌套路径数据TLV作为允许公共子表达式提取的有效措施受到支持。
* FULLDATA-TLV and SPARSEDATA-TLV contain "the data" whose path has been selected by the PATH. Refer to Section 7.1 for details.
* FULLDATA-TLV和SPARA-TLV包含路径已被路径选择的“数据”。有关详细信息，请参阅第7.1节。
* The following table summarizes the applicability and restrictions of the FULL/SPARSEDATA-TLVs and the RESULT-TLV to the OPER-TLVs.
* 下表总结了完整/完整TLV和结果TLV对操作TLV的适用性和限制。
+-------------------+-------------------------------+---------------+
| OPER-TLV | DATA TLV | RESULT-TLV |
+-------------------+-------------------------------+---------------+
| SET | | none |
| SET-PROP | (FULLDATA-TLV | | none |
| | SPARSEDATA-TLV)+ | |
| SET-RESPONSE | none | (RESULT-TLV)+ |
| SET-PROP-RESPONSE | none | (RESULT-TLV)+ |
| DEL | | none |
| DEL-RESPONSE | none | (RESULT-TLV)+ |
| GET | none | none |
| GET-PROP | none | none |
| GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| REPORT | (FULLDATA-TLV)+ | none |
| COMMIT | none | none |
| COMMIT-RESPONSE | none | (RESULT-TLV)+ |
| TRCOMP | none | none |
+-------------------+-------------------------------+---------------+
+-------------------+-------------------------------+---------------+
| OPER-TLV | DATA TLV | RESULT-TLV |
+-------------------+-------------------------------+---------------+
| SET | | none |
| SET-PROP | (FULLDATA-TLV | | none |
| | SPARSEDATA-TLV)+ | |
| SET-RESPONSE | none | (RESULT-TLV)+ |
| SET-PROP-RESPONSE | none | (RESULT-TLV)+ |
| DEL | | none |
| DEL-RESPONSE | none | (RESULT-TLV)+ |
| GET | none | none |
| GET-PROP | none | none |
| GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| REPORT | (FULLDATA-TLV)+ | none |
| COMMIT | none | none |
| COMMIT-RESPONSE | none | (RESULT-TLV)+ |
| TRCOMP | none | none |
+-------------------+-------------------------------+---------------+
Table 2
表2
o RESULT-TLV contains the indication of whether the individual SET or SET-PROP succeeded. RESULT-TLV is included on the assumption that individual parts of a SET request can succeed or fail separately.
o 结果-TLV包含单个SET或SET-PROP是否成功的指示。RESULT-TLV包含在集合请求的各个部分可以分别成功或失败的假设上。
In summary, this approach has the following characteristics:
总之，这种方法具有以下特点：
o There can be one or more LFB class ID and instance ID combinations targeted in a message (batch).
o 消息（批处理）中可以有一个或多个LFB类ID和实例ID组合。
o There can one or more operations on an addressed LFB class ID/ instance ID combination (batch).
o 可以对已寻址LFB类ID/实例ID组合（批处理）执行一个或多个操作。
o There can be one or more path targets per operation (batch).
o 每个操作（批处理）可以有一个或多个路径目标。
o Paths may have zero or more data values associated (flexibility and operation specific).
o 路径可能有零个或多个关联的数据值（灵活性和操作特定）。
It should be noted that the above is optimized for the case of a single LFB class ID and instance ID targeting. To target multiple instances within the same class, multiple LFBselects are needed.
应该注意的是，上面针对单个LFB类ID和实例ID目标的情况进行了优化。要针对同一类中的多个实例，需要多个LFB选择。
Section 6.4.3 discusses the two types of DATA encodings (FULLDATA-TLV and SPARSEDATA-TLV) and the justifications for their existence. In this section, we explain how they are encoded.
第6.4.3节讨论了两种类型的数据编码（FULLDATA-TLV和SPARA-TLV）及其存在的理由。在本节中，我们将解释它们是如何编码的。
The scheme for encoding data used in this document adheres to the following rules:
本文档中使用的数据编码方案遵循以下规则：
o The Value ("V" of TLV) of FULLDATA-TLV will contain the data being transported. This data will be as was described in the LFB definition.
o FULLDATA-TLV的值（“TLV的V”）将包含正在传输的数据。该数据将如LFB定义中所述。
o Variable-sized data within a FULLDATA-TLV will be encapsulated inside another FULLDATA-TLV inside the V of the outer TLV. For an example of such a setup, refer to Appendices C and D.
o FULLDATA-TLV内的可变大小数据将封装在外部TLV的V内的另一个FULLDATA-TLV内。有关此类设置的示例，请参阅附录C和D。
o In the case of FULLDATA-TLVs:
o 对于FULLDATA TLV：
* When a table is referred to in the PATH (IDs) of a PATH-DATA-TLV, then the FULLDATA-TLV's "V" will contain that table's row content prefixed by its 32-bit index/subscript. On the other
* 当在PATH-DATA-TLV的路径（ID）中引用表时，FULLDATA-TLV的“V”将包含该表的行内容，其前缀为32位索引/下标。另一方面
hand, the PATH may contain an index pointing to a row in table; in such a case, the FULLDATA-TLV's "V" will only contain the content with the index in order to avoid ambiguity.
另一方面，路径可能包含指向表中某一行的索引；在这种情况下，FULLDATA-TLV的“V”将仅包含带有索引的内容，以避免歧义。
Only bit 0, the SELECTOR Bit, is currently used in the path flags as illustrated in Figure 18.
如图18所示，路径标志中当前只使用了位0（选择器位）。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
|S| Reserved |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
|S| Reserved |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Path Flags
图18：路径标志
The semantics of the flag are defined as follows:
标志的语义定义如下：
o SELECTOR Bit: F_SELKEY(set to 1) indicates that a KEY Selector is present following this path information, and should be considered in evaluating the path content.
o 选择器位：F_SELKEY（设置为1）表示在该路径信息之后存在一个键选择器，在评估路径内容时应予以考虑。
Global flags, such as the execution mode and the atomicity indicators defined in the header, apply to all operations in a message. Global flags provide semantics that are orthogonal to those provided by the operational flags, such as the flags defined in path-data. The scope of operational flags is restricted to the operation.
全局标志（如头中定义的执行模式和原子性指示符）适用于消息中的所有操作。全局标志提供与操作标志（如路径数据中定义的标志）提供的语义正交的语义。操作标志的范围仅限于操作。
The KEYINFO-TLV describes the KEY as well as associated KEY data. KEYs, used for content searches, are restricted and described in the LFB definition.
KEYINFO-TLV描述了密钥以及相关的密钥数据。用于内容搜索的键在LFB定义中受到限制和描述。
The LFBselect TLV is an instance of a TLV as defined in Section 6.2. The definition is as follows:
LFBselect TLV是第6.2节中定义的TLV实例。定义如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFBselect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER-TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER-TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFBselect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER-TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER-TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: PL PDU Layout
图19:PL PDU布局
Type:
类型：
The type of the TLV is "LFBselect"
TLV的类型为“LFBselect”
Length:
长度：
Length of the TLV including the T and L fields, in octets.
TLV的长度，包括T和L字段，以八位字节为单位。
LFB Class ID:
LFB类ID：
This field uniquely recognizes the LFB class/type.
此字段唯一识别LFB类/类型。
LFB Instance ID:
LFB实例ID:
This field uniquely identifies the LFB instance.
此字段唯一标识LFB实例。
OPER-TLV:
OPER-TLV：
It describes an operation nested in the LFBselect TLV. Note that usually there SHOULD be at least one OPER-TLV present for an LFB select TLV.
它描述了LFBselect TLV中嵌套的操作。注意，通常LFB select TLV至少应有一个OPER-TLV。
The OPER-TLV is a place holder in the grammar for TLVs that define operations. The different types are defined in Table 3, below.
OPER-TLV是定义操作的TLV语法中的占位符。下表3中定义了不同的类型。
+-------------------+--------+--------------------------------------+
| OPER-TLV | TLV | Comments |
| | "Type" | |
+-------------------+--------+--------------------------------------+
| SET | 0x0001 | From CE to FE. Used to create or |
| | | add or update components |
| SET-PROP | 0x0002 | From CE to FE. Used to create or |
| | | add or update component properties |
| SET-RESPONSE | 0x0003 | From FE to CE. Used to carry |
| | | response of a SET |
| SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry |
| | | response of a SET-PROP |
| DEL | 0x0005 | From CE to FE. Used to delete or |
| | | remove an component |
| DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry |
| | | response of a DEL |
| GET | 0x0007 | From CE to FE. Used to retrieve an |
| | | component |
| GET-PROP | 0x0008 | From CE to FE. Used to retrieve an |
| | | component property |
| GET-RESPONSE | 0x0009 | From FE to CE. Used to carry |
| | | response of a GET |
| GET-PROP-RESPONSE | 0x000A | From FE to CE. Used to carry |
| | | response of a GET-PROP |
| REPORT | 0x000B | From FE to CE. Used to carry an |
| | | asynchronous event |
| COMMIT | 0x000C | From CE to FE. Used to issue a |
| | | commit in a 2PC transaction |
| COMMIT-RESPONSE | 0x000D | From FE to CE. Used to confirm a |
| | | commit in a 2PC transaction |
| TRCOMP | 0x000E | From CE to FE. Used to indicate |
| | | NE-wide success of 2PC transaction |
+-------------------+--------+--------------------------------------+
+-------------------+--------+--------------------------------------+
| OPER-TLV | TLV | Comments |
| | "Type" | |
+-------------------+--------+--------------------------------------+
| SET | 0x0001 | From CE to FE. Used to create or |
| | | add or update components |
| SET-PROP | 0x0002 | From CE to FE. Used to create or |
| | | add or update component properties |
| SET-RESPONSE | 0x0003 | From FE to CE. Used to carry |
| | | response of a SET |
| SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry |
| | | response of a SET-PROP |
| DEL | 0x0005 | From CE to FE. Used to delete or |
| | | remove an component |
| DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry |
| | | response of a DEL |
| GET | 0x0007 | From CE to FE. Used to retrieve an |
| | | component |
| GET-PROP | 0x0008 | From CE to FE. Used to retrieve an |
| | | component property |
| GET-RESPONSE | 0x0009 | From FE to CE. Used to carry |
| | | response of a GET |
| GET-PROP-RESPONSE | 0x000A | From FE to CE. Used to carry |
| | | response of a GET-PROP |
| REPORT | 0x000B | From FE to CE. Used to carry an |
| | | asynchronous event |
| COMMIT | 0x000C | From CE to FE. Used to issue a |
| | | commit in a 2PC transaction |
| COMMIT-RESPONSE | 0x000D | From FE to CE. Used to confirm a |
| | | commit in a 2PC transaction |
| TRCOMP | 0x000E | From CE to FE. Used to indicate |
| | | NE-wide success of 2PC transaction |
+-------------------+--------+--------------------------------------+
Table 3
表3
Different messages use OPER-TLV and define how they are used (refer to Table 1 and Table 2).
不同的消息使用OPER-TLV并定义如何使用它们（请参阅表1和表2）。
SET, SET-PROP, and GET/GET-PROP requests are issued by the CE and do not carry RESULT-TLVs. On the other hand, SET-RESPONSE, SET-PROP-RESPONSE, and GET-RESPONSE/GET-PROP-RESPONSE carry RESULT-TLVs.
SET、SET-PROP和GET/GET-PROP请求由CE发出，不携带结果TLV。另一方面，SET-RESPONSE、SET-PROP-RESPONSE和GET-RESPONSE/GET-PROP-RESPONSE携带结果TLV。
A GET-RESPONSE in response to a successful GET will have FULLDATA-TLVs added to the leaf paths to carry the requested data. For GET operations that fail, instead of the FULLDATA-TLV there will be a RESULT-TLV.
响应成功GET的GET响应将向叶路径添加FULLDATA TLV，以承载请求的数据。对于失败的GET操作，将出现RESULT-TLV，而不是FULLDATA-TLV。
For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA-TLV or SPARSEDATA-TLV in the original request will be replaced with a RESULT-TLV in the response. If the request set the FailureACK flag, then only those items that failed will appear in the response. If the request was for AlwaysACK, then all components of the request will appear in the response with RESULT-TLVs.
对于SET-RESPONSE/SET-PROP-RESPONSE，原始请求中的每个FULLDATA-TLV或SPARRA-TLV将替换为响应中的RESULT-TLV。如果请求设置了FailureACK标志，则只有失败的项目才会出现在响应中。如果请求是针对AlwaysACK的，那么请求的所有组件都将出现在响应中，并显示结果TLV。
Note that if a SET/SET-PROP request with a structure in a FULLDATA-TLV is issued, and some field in the structure is invalid, the FE will not attempt to indicate which field was invalid, but rather will indicate that the operation failed. Note further that if there are multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the FE can select which error it chooses to return. So if a FULLDATA-TLV for a SET/SET-PROP of a structure attempts to write one field that is read only, and attempts to set another field to an invalid value, the FE can return indication of either error.
请注意，如果发出FULLDATA-TLV中具有结构的SET/SET-PROP请求，并且结构中的某些字段无效，FE将不会尝试指示哪个字段无效，而是指示操作失败。进一步注意，如果单个叶PATH-DATA/FULLDATA-TLB中存在多个错误，FE可以选择返回哪个错误。因此，如果结构的SET/SET-PROP的FULLDATA-TLV试图写入一个只读字段，并试图将另一个字段设置为无效值，FE可以返回任一错误的指示。
A SET/SET-PROP operation on a variable-length component with a length of 0 for the item is not the same as deleting it. If the CE wishes to delete, then the DEL operation should be used whether the path refers to an array component or an optional structure component.
对项目长度为0的可变长度组件执行SET/SET-PROP操作与删除该组件不同。如果CE希望删除，则无论路径引用阵列组件还是可选结构组件，都应使用DEL操作。
The RESULT-TLV is an instance of TLV defined in Section 6.2. The definition is as follows:
结果-TLV是第6.2节中定义的TLV实例。定义如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = RESULT-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = RESULT-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: RESULT-TLV
图20：结果-TLV
Defined Result Values
定义的结果值
+-----------------------------+-----------+-------------------------+
| Result Value | Value | Definition |
+-----------------------------+-----------+-------------------------+
| E_SUCCESS | 0x00 | Success |
| E_INVALID_HEADER | 0x01 | Unspecified error with |
| | | header. |
| E_LENGTH_MISMATCH | 0x02 | Header length field |
| | | does not match actual |
| | | packet length. |
| E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch |
| | | in versions. |
| E_INVALID_DESTINATION_PID | 0x04 | Destination PID is |
| | | invalid for the message |
| | | receiver. |
| E_LFB_UNKNOWN | 0x05 | LFB Class ID is not |
| | | known by receiver. |
| E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known |
| | | by receiver but not |
| | | currently in use. |
| E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known |
| | | but the specified |
| | | instance of that class |
| | | does not exist. |
| E_INVALID_PATH | 0x08 | The specified path is |
| | | impossible. |
| E_COMPONENT_DOES_NOT_EXIST | 0x09 | The specified path is |
| | | possible but the |
| | | component does not |
| | | exist (e.g., attempt to |
| | | modify a table row that |
| | | has not been created). |
| E_EXISTS | 0x0A | The specified object |
| | | exists but it cannot |
| | | exist for the operation |
| | | to succeed (e.g., |
| | | attempt to add an |
| | | existing LFB instance |
| | | or array subscript). |
| E_NOT_FOUND | 0x0B | The specified object |
| | | does not exist but it |
| | | MUST exist for the |
| | | operation to succeed |
| | | (e.g., attempt to |
| | | delete a non-existing |
| | | LFB instance or array |
| | | subscript). |
+-----------------------------+-----------+-------------------------+
| Result Value | Value | Definition |
+-----------------------------+-----------+-------------------------+
| E_SUCCESS | 0x00 | Success |
| E_INVALID_HEADER | 0x01 | Unspecified error with |
| | | header. |
| E_LENGTH_MISMATCH | 0x02 | Header length field |
| | | does not match actual |
| | | packet length. |
| E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch |
| | | in versions. |
| E_INVALID_DESTINATION_PID | 0x04 | Destination PID is |
| | | invalid for the message |
| | | receiver. |
| E_LFB_UNKNOWN | 0x05 | LFB Class ID is not |
| | | known by receiver. |
| E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known |
| | | by receiver but not |
| | | currently in use. |
| E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known |
| | | but the specified |
| | | instance of that class |
| | | does not exist. |
| E_INVALID_PATH | 0x08 | The specified path is |
| | | impossible. |
| E_COMPONENT_DOES_NOT_EXIST | 0x09 | The specified path is |
| | | possible but the |
| | | component does not |
| | | exist (e.g., attempt to |
| | | modify a table row that |
| | | has not been created). |
| E_EXISTS | 0x0A | The specified object |
| | | exists but it cannot |
| | | exist for the operation |
| | | to succeed (e.g., |
| | | attempt to add an |
| | | existing LFB instance |
| | | or array subscript). |
| E_NOT_FOUND | 0x0B | The specified object |
| | | does not exist but it |
| | | MUST exist for the |
| | | operation to succeed |
| | | (e.g., attempt to |
| | | delete a non-existing |
| | | LFB instance or array |
| | | subscript). |
| E_READ_ONLY | 0x0C | Attempt to modify a |
| | | read-only value. |
| E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an |
| | | array with an unallowed |
| | | subscript. |
| E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a |
| | | parameter to a value |
| | | outside of its |
| | | allowable range. |
| E_CONTENTS_TOO_LONG | 0x0D | Attempt to write |
| | | contents larger than |
| | | the target object space |
| | | (i.e., exceeding a |
| | | buffer). |
| E_INVALID_PARAMETERS | 0x10 | Any other error with |
| | | data parameters. |
| E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not |
| | | acceptable. |
| E_INVALID_FLAGS | 0x12 | Message flags are not |
| | | acceptable for the |
| | | given message type. |
| E_INVALID_TLV | 0x13 | A TLV is not acceptable |
| | | for the given message |
| | | type. |
| E_EVENT_ERROR | 0x14 | Unspecified error while |
| | | handling an event. |
| E_NOT_SUPPORTED | 0x15 | Attempt to perform a |
| | | valid ForCES operation |
| | | that is unsupported by |
| | | the message receiver. |
| E_MEMORY_ERROR | 0x16 | A memory error occurred |
| | | while processing a |
| | | message (no error |
| | | detected in the message |
| | | itself). |
| E_INTERNAL_ERROR | 0x17 | An unspecified error |
| | | occurred while |
| | | processing a message |
| | | (no error detected in |
| | | the message itself). |
| - | 0x18-0xFE | Reserved |
| E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for |
| | | when the FE cannot |
| | | decide what went |
| | | wrong). |
+-----------------------------+-----------+-------------------------+
| E_READ_ONLY | 0x0C | Attempt to modify a |
| | | read-only value. |
| E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an |
| | | array with an unallowed |
| | | subscript. |
| E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a |
| | | parameter to a value |
| | | outside of its |
| | | allowable range. |
| E_CONTENTS_TOO_LONG | 0x0D | Attempt to write |
| | | contents larger than |
| | | the target object space |
| | | (i.e., exceeding a |
| | | buffer). |
| E_INVALID_PARAMETERS | 0x10 | Any other error with |
| | | data parameters. |
| E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not |
| | | acceptable. |
| E_INVALID_FLAGS | 0x12 | Message flags are not |
| | | acceptable for the |
| | | given message type. |
| E_INVALID_TLV | 0x13 | A TLV is not acceptable |
| | | for the given message |
| | | type. |
| E_EVENT_ERROR | 0x14 | Unspecified error while |
| | | handling an event. |
| E_NOT_SUPPORTED | 0x15 | Attempt to perform a |
| | | valid ForCES operation |
| | | that is unsupported by |
| | | the message receiver. |
| E_MEMORY_ERROR | 0x16 | A memory error occurred |
| | | while processing a |
| | | message (no error |
| | | detected in the message |
| | | itself). |
| E_INTERNAL_ERROR | 0x17 | An unspecified error |
| | | occurred while |
| | | processing a message |
| | | (no error detected in |
| | | the message itself). |
| - | 0x18-0xFE | Reserved |
| E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for |
| | | when the FE cannot |
| | | decide what went |
| | | wrong). |
+-----------------------------+-----------+-------------------------+
Table 4
表4
A FULLDATA-TLV has "T"= FULLDATA-TLV and a 16-bit length followed by the data value/contents. Likewise, a SPARSEDATA-TLV has "T" = SPARSEDATA-TLV, a 16-bit length, followed by the data value/contents. In the case of the SPARSEDATA-TLV, each component in the Value part of the TLV will be further encapsulated in an ILV.
FULLDATA-TLV的“T”=FULLDATA-TLV，长度为16位，后跟数据值/内容。类似地，SPARSTATLV具有“T”=SPARSTATLV，16位长度，后跟数据值/内容。对于A-TLV，TLV值部分中的每个组件将进一步封装在ILV中。
Below are the encoding rules for the FULLDATA-TLV and SPARSEDATA-TLVs. Appendix C is very useful in illustrating these rules:
以下是FULLDATA-TLV和SPARA-TLV的编码规则。附录C在说明这些规则时非常有用：
1. Both ILVs and TLVs MUST be 32-bit aligned. Any padding bits used for the alignment MUST be zero on transmission and MUST be ignored upon reception.
1. ILV和TLV都必须是32位对齐的。用于对齐的任何填充位在传输时必须为零，在接收时必须忽略。
2. FULLDATA-TLVs may be used at a particular path only if every component at that path level is present. In example 1(c) of Appendix C, this concept is illustrated by the presence of all components of the structure S in the FULLDATA-TLV encoding. This requirement holds regardless of whether the fields are fixed or variable length, mandatory or optional.
2. 只有当路径级别上的每个组件都存在时，才能在特定路径上使用FULLDATA TLV。在附录c的示例1（c）中，该概念通过FULLDATA-TLV编码中存在结构S的所有组件来说明。无论字段的长度是固定的还是可变的、强制的还是可选的，此要求都适用。
* If a FULLDATA-TLV is used, the encoder MUST lay out data for each component in the same order in which the data was defined in the LFB specification. This ensures the decoder is able to retrieve the data. To use the example 1 again in Appendix C, this implies the encoder/decoder is assumed to have knowledge of how structure S is laid out in the definition.
* 如果使用FULLDATA-TLV，编码器必须按照LFB规范中定义的数据顺序为每个组件布局数据。这确保解码器能够检索数据。为了再次使用附录C中的示例1，这意味着编码器/解码器假定了解结构S在定义中的布局方式。
* In the case of a SPARSEDATA-TLV, it does not need to be ordered since the "I" in the ILV uniquely identifies the component. Examples 1(a) and 1(b) in Appendix C illustrate the power of SPARSEDATA-TLV encoding.
* 对于a-TLV，无需订购，因为ILV中的“I”唯一标识组件。附录C中的示例1（a）和1（b）说明了a-TLV编码的威力。
3. Inside a FULLDATA-TLV
3. 在FULLDATA-TLV中
* The values for atomic, fixed-length fields are given without any TLV encapsulation.
* 原子、固定长度字段的值是在没有任何TLV封装的情况下给出的。
* The values for atomic, variable-length fields are given inside FULLDATA-TLVs.
* 原子可变长度字段的值在FULLDATA TLV中给出。
* The values for arrays are in the form of index/subscript, followed by value as stated in "Data Packing Rules" (Section 7.1.1) and demonstrated by the examples in the appendices.
* 数组的值以索引/下标的形式表示，后面是“数据打包规则”（第7.1.1节）中规定的值，并通过附录中的示例加以说明。
4. Inside a SPARSEDATA-TLV
4. 在Spara-TLV内
* The values of all fields MUST be given with ILVs (32-bit index, 32-bit length).
* 所有字段的值必须使用ILV（32位索引，32位长度）给出。
5. FULLDATA-TLVs cannot contain an ILV.
5. FULLDATA TLV不能包含ILV。
6. A FULLDATA-TLV can also contain a FULLDATA-TLV for variable-sized components. The decoding disambiguation is assumed from rule #3 above.
6. FULLDATA-TLV还可以包含用于可变尺寸组件的FULLDATA-TLV。解码消歧是根据上述规则#3假设的。
It is expected that a GET-RESPONSE would satisfy the following:
预计GET响应将满足以下要求：
o It would have exactly the same path definitions as those sent in the GET. The only difference is that a GET-RESPONSE will contain FULLDATA-TLVs.
o 它将具有与GET中发送的路径定义完全相同的路径定义。唯一的区别是GET-RESPONSE将包含FULLDATA tlv。
o It should be possible to take the same GET-RESPONSE and convert it to a SET successfully by merely changing the T in the operational TLV.
o 只需改变操作TLV中的T，就可以获得相同的GET响应并将其成功转换为集合。
o There are exceptions to this rule:
o 此规则有例外情况：
1. When a KEY selector is used with a path in a GET operation, that selector is not returned in the GET-RESPONSE; instead, the cooked result is returned. Refer to the examples using KEYS to see this.
1. 当在GET操作中将键选择器与路径一起使用时，该选择器不会在GET响应中返回；相反，将返回已处理的结果。请参阅使用键的示例以了解这一点。
2. When dumping a whole table in a GET, the GET-RESPONSE that merely edits the T to be SET will end up overwriting the table.
2. 在GET中转储整个表时，仅编辑要设置的T的GET响应将覆盖该表。
The figure below shows a general layout of the PL PDU. A main header is followed by one or more LFB selections each of which may contain one or more operations.
下图显示了PL PDU的总体布局。主报头后面是一个或多个LFB选择，每个LFB选择可能包含一个或多个操作。
main hdr (Config in this case)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID
| |
| |
| +-- LFBInstance
| |
| +-- T = SET
| | |
| | +-- // one or more path targets
| | // with their data here to be added
| |
| +-- T = DEL
| . |
| . +-- // one or more path targets to be deleted
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID
| |
| |
| +-- LFBInstance
| |
| + -- T= SET
| | .
| | .
| + -- T= DEL
| | .
| | .
| |
| + -- T= SET
| | .
| | .
|
|
+--- T = LFBselect
|
+-- LFBCLASSID
|
+-- LFBInstance
.
.
.
Figure 21: PL PDU Logical Layout
main hdr (Config in this case)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID
| |
| |
| +-- LFBInstance
| |
| +-- T = SET
| | |
| | +-- // one or more path targets
| | // with their data here to be added
| |
| +-- T = DEL
| . |
| . +-- // one or more path targets to be deleted
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID
| |
| |
| +-- LFBInstance
| |
| + -- T= SET
| | .
| | .
| + -- T= DEL
| | .
| | .
| |
| + -- T= SET
| | .
| | .
|
|
+--- T = LFBselect
|
+-- LFBCLASSID
|
+-- LFBInstance
.
.
.
Figure 21: PL PDU Logical Layout
The figure below shows a more detailed example of the general layout of the operation within a targeted LFB selection. The idea is to show the different nesting levels a path could take to get to the target path.
下图显示了目标LFB选择内操作总体布局的更详细示例。其思想是显示路径到达目标路径可能采用的不同嵌套级别。
T = SET
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| + -- T = KEYINFO-TLV
| | + -- KEY_ID
| | + -- KEY_DATA
| |
| + -- T = FULLDATA-TLV
| + -- data
|
|
T = SET
| |
| +- T = Path-data
| | |
| | + -- flags
| | + -- IDCount
| | + -- IDs
| | |
| | + -- T = FULLDATA-TLV
| | + -- data
| +- T = Path-data
| |
T = SET
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| + -- T = KEYINFO-TLV
| | + -- KEY_ID
| | + -- KEY_DATA
| |
| + -- T = FULLDATA-TLV
| + -- data
|
|
T = SET
| |
| +- T = Path-data
| | |
| | + -- flags
| | + -- IDCount
| | + -- IDs
| | |
| | + -- T = FULLDATA-TLV
| | + -- data
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| + -- T = FULLDATA-TLV
| + -- data
T = DEL
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
+ -- T = KEYINFO-TLV
| + -- KEY_ID
| + -- KEY_DATA
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
| + -- flags
| + -- IDCount
| + -- IDs
| |
| + -- T = FULLDATA-TLV
| + -- data
T = DEL
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
+ -- T = KEYINFO-TLV
| + -- KEY_ID
| + -- KEY_DATA
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
Figure 22: Sample Operation Layout
图22：示例操作布局
Appendix D shows a more concise set of use cases on how the data encoding is done.
附录D展示了一组关于如何进行数据编码的更简洁的用例。
There are two LFBs that are used to control the operation of the ForCES protocol and to interact with FEs and CEs:
有两个LFB用于控制ForCES协议的运行并与FEs和CEs交互：
o FE Protocol LFB
o FE协议LFB
o FE Object LFB
o FE对象LFB
Although these LFBs have the same form and interface as other LFBs, they are special in many respects. They have fixed well-known LFB Class and Instance IDs. They are statically defined (no dynamic instantiation allowed), and their status cannot be changed by the protocol: any operation to change the state of such LFBs (for instance, in order to disable the LFB) MUST result in an error. Moreover, these LFBs MUST exist before the first ForCES message can be sent or received. All components in these LFBs MUST have pre-defined default values. Finally, these LFBs do not have input or output ports and do not integrate into the intra-FE LFB topology.
尽管这些LFB与其他LFB具有相同的形式和接口，但它们在许多方面都是特殊的。它们固定了众所周知的LFB类和实例ID。它们是静态定义的（不允许动态实例化），协议无法更改它们的状态：任何更改此类LFB状态的操作（例如，为了禁用LFB）都必须导致错误。此外，在发送或接收第一个ForCES消息之前，这些lfb必须存在。这些LFB中的所有组件都必须具有预定义的默认值。最后，这些LFB没有输入或输出端口，也没有集成到FE内部LFB拓扑中。
The FE Protocol LFB is a logical entity in each FE that is used to control the ForCES protocol. The FE Protocol LFB Class ID is assigned the value 0x2. The FE Protocol LFB Instance ID is assigned the value 0x1. There MUST be one and only one instance of the FE Protocol LFB in an FE. The values of the components in the FE Protocol LFB have pre-defined default values that are specified here. Unless explicit changes are made to these values using Config messages from the CE, these default values MUST be used for correct operation of the protocol.
FE协议LFB是每个FE中用于控制ForCES协议的逻辑实体。FE协议LFB类ID被分配值0x2。FE协议LFB实例ID被分配值0x1。FE中必须有且只有一个FE协议LFB实例。FE协议LFB中组件的值具有此处指定的预定义默认值。除非使用来自CE的配置消息对这些值进行显式更改，否则这些默认值必须用于协议的正确操作。
The formal definition of the FE Protocol Object LFB can be found in Appendix B.
FE协议对象LFB的正式定义见附录B。
FE Protocol capabilities are read-only.
FE协议功能是只读的。
ForCES protocol version(s) supported by the FE.
强制FE支持的协议版本。
FE Protocol components (can be read and set).
FE协议组件（可读取和设置）。
Current running version of the ForCES protocol.
ForCES协议的当前运行版本。
FE unicast ID.
FE单播ID。
FE multicast ID(s) list - This is a list of multicast IDs to which the FE belongs. These IDs are configured by the CE.
FE多播ID列表-这是FE所属的多播ID列表。这些ID由CE配置。
CE heartbeat policy - This policy, along with the parameter 'CE Heartbeat Dead Interval (CE HDI)' as described below, defines the operating parameters for the FE to check the CE liveness. The policy values with meanings are listed as follows:
CE心跳策略-此策略以及下面描述的参数“CE心跳死间隔（CE HDI）”，定义FE检查CE活动性的操作参数。具有含义的策略值如下所示：
o 0 (default) - This policy specifies that the CE will send a Heartbeat message to the FE(s) whenever the CE reaches a time interval within which no other PL messages were sent from the CE to the FE(s); refer to Section 4.3.3 and Section 7.10 for details. The CE HDI component as described below is tied to this policy.
o 0（默认）-此策略指定每当CE达到没有从CE向FE发送其他PL消息的时间间隔时，CE将向FE发送心跳消息；详见第4.3.3节和第7.10节。如下所述的CE HDI组件与此策略相关联。
o 1 - The CE will not generate any HB messages. This actually means that the CE does not want the FE to check the CE liveness.
o 1-CE不会生成任何HB消息。这实际上意味着CE不希望FE检查CE活动性。
o Others - Reserved.
o 其他-保留。
CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses to check the CE liveness. If FE has not received any messages from CE within this time interval, FE deduces lost connectivity, which implies that the CE is dead or the association to the CE is lost. Default value is 30 s.
CE心跳死间隔（CE HDI）-FE用于检查CE活动性的时间间隔。如果FE在此时间间隔内未收到来自CE的任何消息，则FE推断连接丢失，这意味着CE已死亡或与CE的关联丢失。默认值为30秒。
FE heartbeat policy - This policy, along with the parameter 'FE Heartbeat Interval (FE HI)', defines the operating parameters for how the FE should behave so that the CE can deduce its liveness. The policy values and the meanings are:
FE心跳策略-此策略与参数“FE心跳间隔（FE HI）”一起定义FE应如何运行的操作参数，以便CE可以推断其活动性。政策价值和含义如下：
o 0 (default) - The FE should not generate any Heartbeat messages. In this scenario, the CE is responsible for checking FE liveness by setting the PL header ACK flag of the message it sends to AlwaysACK. The FE responds to the CE whenever the CE sends such Heartbeat Request messages. Refer to Section 7.10 and Section 4.3.3 for details.
o 0（默认）-FE不应生成任何心跳消息。在此场景中，CE负责通过设置发送给AlwaysACK的消息的PL header ACK标志来检查FE活动性。只要CE发送此类心跳请求消息，FE就会响应CE。详见第7.10节和第4.3.3节。
o 1 - This policy specifies that the FE MUST actively send a Heartbeat message if it reaches the time interval assigned by the FE HI as long as no other messages were sent from the FE to the CE during that interval as described in Section 4.3.3.
o 1-本政策规定，如果FE达到FE HI指定的时间间隔，则FE必须主动发送心跳消息，只要在该时间间隔内没有其他消息从FE发送到CE，如第4.3.3节所述。
o Others - Reserved.
o 其他-保留。
FE Heartbeat Interval (FE HI) - The time interval the FE should use to send HB as long as no other messages were sent from the FE to the CE during that interval as described in Section 4.3.3. The default value for an FE HI is 500 ms.
FE心跳间隔（FE HI）-FE应用于发送HB的时间间隔，前提是在该间隔期间，FE未向CE发送其他消息，如第4.3.3节所述。FE HI的默认值为500 ms。
Primary CEID - The CEID with which the FE is associated.
主CEID-与FE关联的CEID。
Last Primary CEID - The CEID of the last CE with which the FE associated. This CE ID is reported to the new Primary CEID.
Last Primary CEID—FE关联的最后一个CE的CEID。此CE ID将报告给新的主CEID。
The list of backup CEs an FE can use as backups. Refer to Section 8 for details.
FE可用作备份的备份CE列表。有关详细信息，请参阅第8节。
CE failover policy - This specifies the behavior of the FE when the association with the CE is lost. There is a very tight relation between CE failover policy and Section 7.3.1.1.2.8, Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an association is lost, depending on configuration, one of the policies listed below is activated.
CE故障切换策略—指定FE在与CE的关联丢失时的行为。CE故障切换策略与第7.3.1.1.2.8节、第7.3.1.1.2.10节、第7.3.1.1.2.12节和第8节之间的关系非常密切。当关联丢失时，根据配置，将激活下面列出的策略之一。
o 0 (default) - The FE should stop functioning immediately and transition to FE OperDisable.
o 0（默认）-FE应立即停止运行，并转换为FE OperDisable。
o 1 - The FE should continue running and do what it can even without an associated CE. This basically requires that the FE support CE Graceful restart (and defines such support in its capabilities). If the CEFTI expires before the FE re-associates with either the primary CEID (Section 7.3.1.1.2.8) or one of possibly several backup CEs (Section 7.3.1.1.2.10), the FE will go operationally down.
o 1-FE应继续运行，并在没有相关CE的情况下尽其所能。这基本上要求FE支持CE优雅重启（并在其功能中定义此类支持）。如果在FE重新关联主CEID（第7.3.1.1.2.8节）或可能的多个备用CE之一（第7.3.1.1.2.10节）之前，CEFTI到期，FE将停止运行。
o Others - Reserved.
o 其他-保留。
CE Failover Timeout Interval (CEFTI) - The time interval associated with the CE failover policy case '0' and '1'. The default value is set to 300 seconds. Note that it is advisable to set the CEFTI value much higher than the CE Heartbeat Dead Interval (CE HDI) since the effect of expiring this parameter is devastating to the operation of the FE.
CE故障转移超时间隔（CEFTI）—与CE故障转移策略案例“0”和“1”关联的时间间隔。默认值设置为300秒。请注意，建议将CEFTI值设置为远高于CE心跳死亡间隔（CE HDI），因为使该参数过期会对FE的运行造成破坏性影响。
FE restart policy - This specifies the behavior of the FE during an FE restart. The restart may be from an FE failure or other reasons that have made the FE down and then need to restart. The values are defined as follows:
FE重启策略-指定FE重启期间FE的行为。重新启动可能是由于FE故障或其他原因导致FE停机，然后需要重新启动。这些值的定义如下：
o 0(default)- Restart the FE from scratch. In this case, the FE should start from the pre-association phase.
o 0（默认）-从头开始重新启动FE。在这种情况下，FE应从关联前阶段开始。
o Others - Reserved for future use.
o 其他-保留供将来使用。
The FE Object LFB is a logical entity in each FE and contains components relative to the FE itself, and not to the operation of the ForCES protocol.
FE对象LFB是每个FE中的逻辑实体，包含与FE本身相关的组件，而不是与ForCES协议的操作相关的组件。
The formal definition of the FE Object LFB can be found in [RFC5812]. The model captures the high-level properties of the FE that the CE needs to know to begin working with the FE. The class ID for this LFB class is also assigned in [RFC5812]. The singular instance of this class will always exist, and will always have instance ID 0x1 within its class. It is common, although not mandatory, for a CE to fetch much of the component and capability information from this LFB instance when the CE begins controlling the operation of the FE.
FE对象LFB的正式定义见[RFC5812]。该模型捕获FE的高级属性，CE需要知道这些属性才能开始使用FE。该LFB类的类ID也在[RFC5812]中分配。此类的单一实例将始终存在，并且在其类中始终具有实例ID 0x1。当CE开始控制FE的操作时，CE从该LFB实例获取大部分组件和能力信息是常见的，尽管不是强制性的。
Recall: The PL provides a master(CE)-slave(FE) relationship. The LFBs reside at the FE and are controlled by CE.
回想一下：PL提供了主（CE）-从（FE）关系。LFB位于FE处，由CE控制。
When messages go from the CE, the LFB selector (class and instance) refers to the destination LFB selection that resides in the FE.
当消息从CE发出时，LFB选择器（类和实例）引用驻留在FE中的目标LFB选择。
When messages go from the FE to the CE, the LFB selector (class and instance) refers to the source LFB selection that resides in the FE.
当消息从FE发送到CE时，LFB选择器（类和实例）引用驻留在FE中的源LFB选择。
The ForCES Association messages are used to establish and tear down associations between FEs and CEs.
部队关联消息用于建立和解除FEs和CEs之间的关联。
This message is sent by the FE to the CE to set up a ForCES association between them.
FE将此消息发送给CE，以建立它们之间的力关联。
Message transfer direction: FE to CE
消息传输方向：FE到CE
Message header: The Message Type in the header is set to MessageType= 'AssociationSetup'. The ACK flag in the header MUST be ignored, and the Association Setup message always expects to get a response from the message receiver (CE), whether or not the setup is successful. The correlator field in the header is set, so that FE can correlate the response coming back from the CE correctly. The FE may set the source ID to 0 in the header to request that the CE should assign an FE ID for the FE in the Setup Response message.
消息标头：标头中的消息类型设置为MessageType='AssociationSetup'。必须忽略标头中的ACK标志，并且无论设置是否成功，关联设置消息始终期望从消息接收器（CE）获得响应。设置标头中的correlator字段，以便FE能够正确关联从CE返回的响应。FE可在报头中将源ID设置为0，以请求CE在设置响应消息中为FE分配FE ID。
Message body: The Association Setup message body optionally consists of zero, one, or two LFBselect TLVs, as described in Section 7.1.5. The Association Setup message only operates on the FE Object and FE Protocol LFBs; therefore, the LFB class ID in the LFBselect TLV only points to these two kinds of LFBs.
消息正文：如第7.1.5节所述，关联设置消息正文可选地由零个、一个或两个LFB选择TLV组成。关联设置消息仅在FE对象和FE协议LFB上运行；因此，LFBselect TLV中的LFB类ID仅指向这两种LFB。
The OPER-TLV in the LFBselect TLV is defined as a 'REPORT' operation. More than one component may be announced in this message using the REPORT operation to let the FE declare its configuration parameters in an unsolicited manner. These may contain components suggesting values such as the FE HB Interval or the FEID. The OPER-TLV used is defined below.
LFBselect TLV中的OPER-TLV定义为“报告”操作。可以使用报告操作在此消息中宣布多个组件，以便FE以未经请求的方式声明其配置参数。这些可能包含建议值的成分，如FE HB间期或FEID。使用的OPER-TLV定义如下。
OPER-TLV for Association Setup:
关联设置的OPER-TLV：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: OPER-TLV
图23:OPER-TLV
Type: Only one operation type is defined for the Association Setup message:
类型：关联设置消息只定义了一种操作类型：
Type = "REPORT" - This type of operation is for the FE to report something to the CE.
Type=“REPORT”-这种类型的操作是由FE向CE报告某事。
PATH-DATA-TLV for REPORT: This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA BNF definition. The PATH-DATA-TLV for the REPORT operation MAY contain FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV in the data format. The RESULT-TLV is defined in Section 7.1.7 and the FULLDATA-TLV is defined in Section 7.1.8.
报告的PATH-DATA-TLV：这通常是PATH-DATA BNF定义第7节中定义的PATH-DATA-TLV格式。报告操作的PATH-DATA-TLV可以包含FULLDATA-TLV，但不能包含数据格式的任何RESULT-TLV。结果-TLV在第7.1.7节中定义，完整数据-TLV在第7.1.8节中定义。
To better illustrate the above PDU format, a tree structure for the format is shown below:
为了更好地说明上述PDU格式，该格式的树结构如下所示：
main hdr (type = Association Setup)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID = FE object
| |
| |
| +-- LFBInstance = 0x1
|
+--- T = LFBselect
|
+-- LFBCLASSID = FE Protocol object
|
|
+-- LFBInstance = 0x1
|
+---OPER-TLV = REPORT
|
+-- Path-data to one or more components
main hdr (type = Association Setup)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID = FE object
| |
| |
| +-- LFBInstance = 0x1
|
+--- T = LFBselect
|
+-- LFBCLASSID = FE Protocol object
|
|
+-- LFBInstance = 0x1
|
+---OPER-TLV = REPORT
|
+-- Path-data to one or more components
Figure 24: PDU Format for Association Setup Message
图24：关联设置消息的PDU格式
This message is sent by the CE to the FE in response to the Setup message. It indicates to the FE whether or not the setup is successful, i.e., whether an association is established.
CE将此消息发送给FE，以响应设置消息。它向FE指示设置是否成功，即是否建立关联。
Message transfer direction:
消息传输方向：
CE to FE
行政长官转临时行政长官
Message header:
消息头：
The Message Type in the header is set to MessageType= 'AssociationSetupResponse'. The ACK flag in the header MUST be ignored, and the Setup Response message never expects to get any more responses from the message receiver (FE). The destination ID in the header will be set to the source ID in the corresponding Association Setup message, unless that source ID was 0. If the corresponding source ID was 0, then the CE will assign an FE ID value and use that value for the destination ID.
标头中的消息类型设置为MessageType='AssociationSetupResponse'。必须忽略标头中的ACK标志，并且设置响应消息永远不会期望从消息接收器（FE）获得更多响应。标头中的目标ID将设置为相应关联设置消息中的源ID，除非该源ID为0。如果对应的源ID为0，则CE将分配一个FE ID值，并将该值用于目标ID。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ASRresult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Setup Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ASRresult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Setup Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: ASResult OPER-TLV
图25:ASResult OPER-TLV
Type (16 bits):
类型（16位）：
The type of the TLV is "ASResult".
TLV的类型为“ASResult”。
Length (16 bits):
长度（16位）：
Length of the TLV including the T and L fields, in octets.
TLV的长度，包括T和L字段，以八位字节为单位。
Association Setup result (32 bits):
关联设置结果（32位）：
This indicates whether the Setup message was successful or whether the FE request was rejected by the CE. The defined values are:
这表示设置消息是否成功，或者FE请求是否被CE拒绝。定义的值为：
0 = success
0 = success
1 = FE ID invalid
1 = FE ID invalid
2 = permission denied
2 = permission denied
To better illustrate the above PDU format, a tree structure for the format is shown below:
为了更好地说明上述PDU格式，该格式的树结构如下所示：
main hdr (type = Association Setup Response)
|
|
+--- T = ASResult-TLV
main hdr (type = Association Setup Response)
|
|
+--- T = ASResult-TLV
Figure 26: PDU Format for Association Setup Response Message
图26：关联设置响应消息的PDU格式
This message can be sent by the FE or CE to any ForCES element to end its ForCES association with that element.
FE或CE可将此消息发送至任何ForCES元件，以结束其与该元件的力关联。
Message transfer direction:
消息传输方向：
CE to FE, or FE to CE (or CE to CE)
CE对FE或FE对CE（或CE对CE）
Message Header:
消息头：
The Message Type in the header is set to MessageType= "AssociationTeardown". The ACK flag MUST be ignored. The correlator field in the header MUST be set to zero and MUST be ignored by the receiver.
标题中的消息类型设置为MessageType=“AssociationEardown”。必须忽略ACK标志。标头中的correlator字段必须设置为零，并且必须被接收器忽略。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ASTreason | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Teardown Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ASTreason | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Teardown Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: ASTreason-TLV
图27:ASTreason TLV
Type (16 bits):
类型（16位）：
The type of the TLV is "ASTreason".
TLV的类型为“ASTreason”。
Length (16 bits):
长度（16位）：
Length of the TLV including the T and L fields, in octets.
TLV的长度，包括T和L字段，以八位字节为单位。
Teardown reason (32 bits):
拆卸原因（32位）：
This indicates the reason why the association is being terminated. Several reason codes are defined as follows.
这表示终止关联的原因。几个原因代码定义如下。
0 - normal teardown by administrator
0-管理员正常拆卸
1 - error - loss of heartbeats
1-错误-心跳丢失
2 - error - out of bandwidth
2-错误-带宽不足
3 - error - out of memory
3-错误-内存不足
4 - error - application crash
4-错误-应用程序崩溃
255 - error - other or unspecified
255-错误-其他或未指定
To better illustrate the above PDU format, a tree structure for the format is shown below:
为了更好地说明上述PDU格式，该格式的树结构如下所示：
main hdr (type = Association Teardown)
|
|
+--- T = ASTreason-TLV
main hdr (type = Association Teardown)
|
|
+--- T = ASTreason-TLV
Figure 28: PDU Format for Association Teardown Message
图28：关联拆卸消息的PDU格式
The ForCES Configuration messages are used by CE to configure the FEs in a ForCES NE and report the results back to the CE.
CE使用ForCES配置消息来配置ForCES NE中的FEs，并将结果报告回CE。
This message is sent by the CE to the FE to configure LFB components in the FE. This message is also used by the CE to subscribe/ unsubscribe to LFB events.
该消息由CE发送至FE，以配置FE中的LFB组件。CE还使用此消息订阅/取消订阅LFB事件。
As usual, a Config message is composed of a common header followed by a message body that consists of one or more TLV data formats. Detailed description of the message is as follows:
通常，配置消息由公共头和消息体组成，消息体由一种或多种TLV数据格式组成。该消息的详细说明如下：
Message transfer direction:
消息传输方向：
CE to FE
行政长官转临时行政长官
Message header:
消息头：
The Message Type in the header is set to MessageType= 'Config'. The ACK flag in the header can be set to any value defined in Section 6.1, to indicate whether or not a response from the FE is expected by the message.
标头中的消息类型设置为MessageType='Config'。报头中的ACK标志可设置为第6.1节中定义的任何值，以指示消息是否预期FE的响应。
OPER-TLV for Config:
用于配置的OPER-TLV：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OPER-TLV for Config
图29：配置的OPER-TLV
Type:
类型：
The operation type for Config message. Two types of operations for the Config message are defined:
配置消息的操作类型。为配置消息定义了两种类型的操作：
Type = "SET" - This operation is to set LFB components
Type=“SET”-此操作用于设置LFB组件
Type = "SET-PROP" - This operation is to set LFB component properties.
Type=“SET-PROP”-此操作用于设置LFB组件属性。
Type = "DEL" - This operation is to delete some LFB components.
Type=“DEL”-此操作用于删除一些LFB组件。
Type = "COMMIT" - This operation is sent to the FE to commit in a 2pc transaction. A COMMIT TLV is an empty TLV, i.e., it has no "V"alue. In other words, there is a length of 4 (which is for the header only).
Type=“COMMIT”-将此操作发送给FE，以便在2pc事务中提交。提交TLV是一个空TLV，即它没有“V”值。换句话说，长度为4（仅适用于标题）。
Type = "TRCOMP" - This operation is sent to the FE to mark the success from an NE perspective of a 2pc transaction. A TRCOMP TLV is an empty TLV, i.e., it has no "V"alue. In other words, there is a length of 4 (which is for the header only).
Type=“TRCOMP”-此操作发送给FE，以从2pc事务的NE角度标记成功。TRCOMP TLV是空TLV，即它没有“V”值。换句话说，长度为4（仅适用于标题）。
PATH-DATA-TLV:
PATH-DATA-TLV：
This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The restriction on the use of PATH-DATA-TLV for SET/SET-PROP operation is that it MUST contain either FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The restriction on the use of PATH-DATA-TLV for DEL operation is it MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The RESULT-TLV is defined in Section 7.1.7 and FULLDATA-TLVs and SPARSEDATA-TLVs are defined in Section 7.1.8.
这通常是PATH-DATA-TLV BNF定义第7节中定义的PATH-DATA-TLV格式。对SET/SET-PROP操作使用PATH-DATA-TLV的限制是，它必须包含FULLDATA-TLV或SPARA-TLV，但不得包含任何RESULT-TLV。对使用PATH-DATA-TLV进行DEL操作的限制是，它可能包含FULLDATA-TLV或SPARA-TLV，但不得包含任何RESULT-TLV。第7.1.7节中定义了结果TLV，第7.1.8节中定义了FULLDATA TLV和SPARStata TLV。
Note: For Event subscription, the events will be defined by the individual LFBs.
注意：对于事件订阅，事件将由单个LFB定义。
To better illustrate the above PDU format, a tree structure for the format is shown below:
为了更好地说明上述PDU格式，该格式的树结构如下所示：
main hdr (type = Config)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { SET }
| |
| +-- // one or more path targets
| // associated with FULLDATA-TLV or SPARSEDATA-TLV(s)
|
+-- T = operation { DEL }
| |
| +-- // one or more path targets
|
+-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV
.
.
main hdr (type = Config)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { SET }
| |
| +-- // one or more path targets
| // associated with FULLDATA-TLV or SPARSEDATA-TLV(s)
|
+-- T = operation { DEL }
| |
| +-- // one or more path targets
|
+-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV
.
.
Figure 30: PDU Format for Configuration Message
图30：配置消息的PDU格式
This message is sent by the FE to the CE in response to the Config message. It indicates whether or not the Config was successful on the FE and also gives a detailed response regarding the configuration result of each component.
FE向CE发送此消息以响应配置消息。它指示FE上的配置是否成功，并给出关于每个组件配置结果的详细响应。
Message transfer direction:
消息传输方向：
FE to CE
铁对铈
Message header:
消息头：
The Message Type in the header is set to MessageType= 'Config Response'. The ACK flag in the header is always ignored, and the Config Response message never expects to get any further response from the message receiver (CE).
标头中的消息类型设置为MessageType='Config Response'。报头中的ACK标志始终被忽略，配置响应消息从不期望从消息接收器（CE）获得任何进一步的响应。
OPER-TLV for Config Response:
配置响应的OPER-TLV：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: OPER-TLV for Config Response
图31：配置响应的OPER-TLV
Type: The operation type for Config Response message. Two types of operations for the Config Response message are defined:
类型：配置响应消息的操作类型。配置响应消息定义了两种类型的操作：
Type = "SET-RESPONSE" - This operation is for the response of the SET operation of LFB components.
Type=“SET-RESPONSE”-此操作用于LFB组件的设置操作的响应。
Type = "SET-PROP-RESPONSE" - This operation is for the response of the SET-PROP operation of LFB component properties.
Type=“SET-PROP-RESPONSE”-此操作用于响应LFB组件属性的SET-PROP操作。
Type = "DEL-RESPONSE" - This operation is for the response of the DELETE operation of LFB components.
Type=“DEL-RESPONSE”-此操作用于响应LFB组件的删除操作。
Type = "COMMIT-RESPONSE" - This operation is sent to the CE to confirm a commit success in a 2pc transaction. A COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating success or failure.
Type=“COMMIT-RESPONSE”-将此操作发送给CE，以确认2pc事务中的提交成功。提交-响应TLV必须包含指示成功或失败的RESULT-TLV。
PATH-DATA-TLV:
PATH-DATA-TLV：
This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The restriction on the use of PATH-DATA-TLV for SET-RESPONSE operation is that it MUST contain RESULT-TLV(s). The restriction on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also MUST contain RESULT-TLV(s). The RESULT-TLV is defined in Section 7.1.7.
这通常是PATH-DATA-TLV BNF定义第7节中定义的PATH-DATA-TLV格式。对使用PATH-DATA-TLV进行SET-RESPONSE操作的限制是，它必须包含RESULT-TLV。对DEL-RESPONSE操作使用PATH-DATA-TLV的限制是，它还必须包含RESULT-TLV。第7.1.7节定义了结果-TLV。
To better illustrate the above PDU format, a tree structure for the format is shown below:
为了更好地说明上述PDU格式，该格式的树结构如下所示：
main hdr (type = ConfigResponse)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { SET-RESPONSE }
| |
| +-- // one or more path targets
| // associated with FULL or SPARSEDATA-TLV(s)
|
+-- T = operation { DEL-RESPONSE }
| |
| +-- // one or more path targets
|
+-- T = operation { COMMIT-RESPONSE }
| |
| +-- RESULT-TLV
main hdr (type = ConfigResponse)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { SET-RESPONSE }
| |
| +-- // one or more path targets
| // associated with FULL or SPARSEDATA-TLV(s)
|
+-- T = operation { DEL-RESPONSE }
| |
| +-- // one or more path targets
|
+-- T = operation { COMMIT-RESPONSE }
| |
| +-- RESULT-TLV
Figure 32: PDU Format for Config Response Message
图32:Config响应消息的PDU格式
The ForCES Query messages are used by the CE to query LFBs in the FE for information like LFB components, capabilities, statistics, etc. Query messages include the Query message and the Query Response message.
CE使用强制查询消息查询FE中的LFB，以获取LFB组件、功能、统计信息等信息。查询消息包括查询消息和查询响应消息。
A Query message is composed of a common header and a message body that consists of one or more TLV data formats. Detailed description of the message is as follows:
查询消息由公共头和消息体组成，消息体由一种或多种TLV数据格式组成。该消息的详细说明如下：
Message transfer direction:
消息传输方向：
from CE to FE
从CE到FE
Message header:
消息头：
The Message Type in the header is set to MessageType= 'Query'. The ACK flag in the header is always ignored, and a full response for a Query message is always expected. The Correlator field in the header is set, so that the CE can locate the response back from FE correctly.
标头中的消息类型设置为MessageType='Query'。报头中的ACK标志始终被忽略，并且始终需要对查询消息进行完整响应。设置标头中的Correlator字段，以便CE能够正确定位FE返回的响应。
OPER-TLV for Query:
用于查询的OPER-TLV：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET/GET-PROP | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET/GET-PROP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET/GET-PROP | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET/GET-PROP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: TLV for Query
图33：查询的TLV
Type:
类型：
The operation type for query. Two operation types are defined:
查询的操作类型。定义了两种操作类型：
Type = "GET" - This operation is to request to get LFB components.
Type=“GET”-此操作用于请求获取LFB组件。
Type = "GET-PROP" - This operation is to request to get LFB component properties.
Type=“GET-PROP”-此操作用于请求获取LFB组件属性。
PATH-DATA-TLV for GET/GET-PROP:
GET/GET-PROP的PATH-DATA-TLV：
This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The restriction on the use of PATH-DATA-TLV for GET/GET-PROP operation is it MUST NOT contain any SPARSEDATA-TLV or FULLDATA- TLV and RESULT-TLV in the data format.
这通常是PATH-DATA-TLV BNF定义第7节中定义的PATH-DATA-TLV格式。对于GET/GET-PROP操作使用PATH-DATA-TLV的限制是，它不能包含数据格式中的任何SPARA-TLV或FULLDATA-TLV和RESULT-TLV。
To better illustrate the above PDU format, a tree structure for the format is shown below:
为了更好地说明上述PDU格式，该格式的树结构如下所示：
main hdr (type = Query)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { GET }
| |
| +-- // one or more path targets
|
+-- T = operation { GET }
. |
. +-- // one or more path targets
.
main hdr (type = Query)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { GET }
| |
| +-- // one or more path targets
|
+-- T = operation { GET }
. |
. +-- // one or more path targets
.
Figure 34: PDU Format for Query Message
图34：查询消息的PDU格式
When receiving a Query message, the receiver should process the message and come up with a query result. The receiver sends the query result back to the message sender by use of the Query Response message. The query result can be the information being queried if the query operation is successful, or can also be error codes if the query operation fails, indicating the reasons for the failure.
当接收到查询消息时，接收方应处理该消息并给出查询结果。接收方使用查询响应消息将查询结果发送回消息发送方。如果查询操作成功，则查询结果可以是正在查询的信息；如果查询操作失败，则查询结果也可以是错误代码，指明失败的原因。
A Query Response message is also composed of a common header and a message body consisting of one or more TLVs describing the query result. Detailed description of the message is as follows:
查询响应消息也由公共头和消息体组成，消息体由一个或多个描述查询结果的TLV组成。该消息的详细说明如下：
Message transfer direction:
消息传输方向：
from FE to CE
从FE到CE
Message header:
消息头：
The Message Type in the header is set to MessageType= 'QueryResponse'. The ACK flag in the header is ignored. As a response itself, the message does not expect a further response.
标头中的消息类型设置为MessageType='QueryResponse'。标头中的ACK标志将被忽略。作为响应本身，该消息不期望进一步的响应。
OPER-TLV for Query Response:
查询响应的OPER-TLV：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = GET-RESPONSE/GET-PROP-RESPONSE| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = GET-RESPONSE/GET-PROP-RESPONSE| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35: TLV for Query Response
图35：查询响应的TLV
Type:
类型：
The operation type for query response. One operation type is defined:
查询响应的操作类型。定义了一种操作类型：
Type = "GET-RESPONSE" - This operation is for the response of the GET operation of LFB components.
Type=“GET-RESPONSE”-此操作用于LFB组件的GET操作的响应。
Type = "GET-PROP-RESPONSE" - This operation is for the response of the GET-PROP operation of LFB components.
Type=“GET-PROP-RESPONSE”-此操作用于LFB组件的GET-PROP操作的响应。
PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE:
GET-RESPONSE/GET-PROP-RESPONSE的PATH-DATA-TLV：
This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The PATH-DATA- TLV for the GET-RESPONSE operation MAY contain SPARSEDATA-TLV, FULLDATA-TLV, and/or RESULT-TLV(s) in the data encoding. The RESULT-TLV is defined in Section 7.1.7 and the SPARSEDATA-TLVs and FULLDATA-TLVs are defined in Section 7.1.8.
这通常是PATH-DATA-TLV BNF定义第7节中定义的PATH-DATA-TLV格式。GET-RESPONSE操作的PATH-DATA-TLV在数据编码中可能包含A-TLV、FULLDATA-TLV和/或RESULT-TLV。第7.1.7节定义了结果TLV，第7.1.8节定义了SPARSTATLV和FULLDATA TLV。
To better illustrate the above PDU format, a tree structure for the format is shown below:
为了更好地说明上述PDU格式，该格式的树结构如下所示：
main hdr (type = QueryResponse)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { GET-RESPONSE }
| |
| +-- // one or more path targets
|
+-- T = operation { GET-PROP-RESPONSE }
. |
. +-- // one or more path targets
.
main hdr (type = QueryResponse)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { GET-RESPONSE }
| |
| +-- // one or more path targets
|
+-- T = operation { GET-PROP-RESPONSE }
. |
. +-- // one or more path targets
.
Figure 36: PDU Format for Query Response Message
图36：查询响应消息的PDU格式
Event Notification message is used by the FE to asynchronously notify the CE of events that happen in the FE.
FE使用事件通知消息异步通知CE FE中发生的事件。
All events that can be generated in an FE are subscribable by the CE. The CE can subscribe to an event via a Config message with the SET-PROP operation, where the included path specifies the event, as defined by the LFB Library and described by the FE Model.
可在FE中生成的所有事件均可由CE订阅。CE可以通过带有SET-PROP操作的配置消息订阅事件，其中包含的路径指定事件，如LFB库定义和FE模型所述。
As usual, an Event Notification message is composed of a common header and a message body that consists of one or more TLV data formats. Detailed description of the message is as follows:
通常，事件通知消息由公共头和消息体组成，消息体由一种或多种TLV数据格式组成。该消息的详细说明如下：
Message transfer direction:
消息传输方向：
FE to CE
铁对铈
Message header:
消息头：
The Message Type in the message header is set to MessageType = 'EventNotification'. The ACK flag in the header MUST be ignored by the CE, and the Event Notification message does not expect any response from the receiver.
消息头中的消息类型设置为MessageType='EventNotification'。CE必须忽略报头中的ACK标志，并且事件通知消息不期望来自接收器的任何响应。
OPER-TLV for Event Notification:
事件通知的OPER-TLV：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37: TLV for Event Notification
图37：事件通知的TLV
Type:
类型：
Only one operation type is defined for the Event Notification message:
仅为事件通知消息定义了一种操作类型：
Type = "REPORT" - This type of operation is for the FE to report something to the CE.
Type=“REPORT”-这种类型的操作是由FE向CE报告某事。
PATH-DATA-TLV for REPORT:
报告的PATH-DATA-TLV：
This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The PATH-DATA- TLV for the REPORT operation MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s) but MUST NOT contain any RESULT-TLV in the data format.
这通常是PATH-DATA-TLV BNF定义第7节中定义的PATH-DATA-TLV格式。报告操作的PATH-DATA-TLV可以包含FULLDATA-TLV或SPARA-TLV，但不能包含数据格式的任何RESULT-TLV。
To better illustrate the above PDU format, a tree structure for the format is shown below:
为了更好地说明上述PDU格式，该格式的树结构如下所示：
main hdr (type = Event Notification)
|
|
+--- T = LFBselect
|
+-- LFBCLASSID = target LFB class
|
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { REPORT }
| |
| +-- // one or more path targets
| // associated with FULL/SPARSE DATA TLV(s)
+-- T = operation { REPORT }
. |
. +-- // one or more path targets
. // associated with FULL/SPARSE DATA TLV(s)
main hdr (type = Event Notification)
|
|
+--- T = LFBselect
|
+-- LFBCLASSID = target LFB class
|
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { REPORT }
| |
| +-- // one or more path targets
| // associated with FULL/SPARSE DATA TLV(s)
+-- T = operation { REPORT }
. |
. +-- // one or more path targets
. // associated with FULL/SPARSE DATA TLV(s)
Figure 38: PDU Format for Event Notification Message
图38：事件通知消息的PDU格式
A Packet Redirect message is used to transfer data packets between the CE and FE. Usually, these data packets are control packets, but they may be just data path packets that need further (exception or high-touch) processing. It is also feasible that this message carries no data packets and rather just meta data.
数据包重定向消息用于在CE和FE之间传输数据包。通常，这些数据包是控制包，但它们可能只是需要进一步（异常或高接触）处理的数据路径包。该消息不携带数据包，而只携带元数据也是可行的。
The Packet Redirect message data format is formatted as follows:
数据包重定向消息数据格式的格式如下：
Message transfer direction:
消息传输方向：
CE to FE or FE to CE
CE对FE或FE对CE
Message header:
消息头：
The Message Type in the header is set to MessageType= 'PacketRedirect'.
标头中的消息类型设置为MessageType='PacketRedirect'。
Message body:
消息正文：
This consists of one or more TLVs that contain or describe the packet being redirected. The TLV is specifically a Redirect TLV (with the TLV Type="Redirect"). Detailed data format of a Redirect TLV for a Packet Redirect message is as follows:
这包括一个或多个TLV，其中包含或描述被重定向的数据包。TLV特别是重定向TLV（使用TLV Type=“Redirect”）。分组重定向报文的重定向TLV的详细数据格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Redirect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirect Data TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Redirect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirect Data TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 39: Redirect_Data TLV
图39：重定向_数据TLV
Meta Data TLV:
元数据TLV：
This is a TLV that specifies meta data associated with followed redirected data. The TLV is as follows:
这是一个TLV，指定与后续重定向数据关联的元数据。TLV如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = METADATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = METADATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 40: METADATA-TLV
图40:METADATA-TLV
Meta Data ILV:
元数据ILV：
This is an Identifier-Length-Value format that is used to describe one meta data. The ILV has the format as:
这是一种标识符长度值格式，用于描述一个元数据。ILV的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data Value |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data Value |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41: Meta Data ILV
图41：元数据ILV
where Meta Data ID is an identifier for the meta data, which is statically assigned by the LFB definition.
其中元数据ID是元数据的标识符，由LFB定义静态分配。
Redirect Data TLV:
重定向数据TLV：
This is a TLV describing one packet of data to be directed via the redirect operation. The TLV format is as follows:
这是一个TLV，描述通过重定向操作定向的一个数据包。TLV格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REDIRECTDATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirected Data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REDIRECTDATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirected Data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 42: Redirect Data TLV
图42：重定向数据TLV
Redirected Data:
重定向数据：
This field contains the packet that is to be redirected in network byte order. The packet should be 32 bits aligned as is the data for all TLVs. The meta data infers what kind of packet is carried in value field and therefore allows for easy decoding of data encapsulated.
此字段包含按网络字节顺序重定向的数据包。与所有TLV的数据一样，数据包应该是32位对齐的。元数据推断值字段中携带的数据包的类型，因此允许轻松解码封装的数据。
To better illustrate the above PDU format, a tree structure for the format is shown below:
为了更好地说明上述PDU格式，该格式的树结构如下所示：
main hdr (type = PacketRedirect)
|
|
+--- T = Redirect
. |
. +-- T = METADATA-TLV
| |
| +-- Meta Data ILV
| |
| +-- Meta Data ILV
| .
| .
|
+-- T = REDIRECTDATA-TLV
|
+-- // Redirected Data
main hdr (type = PacketRedirect)
|
|
+--- T = Redirect
. |
. +-- T = METADATA-TLV
| |
| +-- Meta Data ILV
| |
| +-- Meta Data ILV
| .
| .
|
+-- T = REDIRECTDATA-TLV
|
+-- // Redirected Data
Figure 43: PDU Format for Packet Redirect Message
图43：包重定向消息的PDU格式
The Heartbeat (HB) message is used for one ForCES element (FE or CE) to asynchronously notify one or more other ForCES elements in the same ForCES NE on its liveness. Section 4.3.3 describes the traffic-sensitive approach used.
心跳（HB）消息用于一个ForCES元素（FE或CE）异步通知同一ForCES NE中的一个或多个其他ForCES元素其活动性。第4.3.3节描述了使用的交通敏感方法。
A Heartbeat message is sent by a ForCES element periodically. The parameterization and policy definition for heartbeats for an FE are managed as components of the FE Protocol Object LFB, and can be set by CE via a Config message. The Heartbeat message is a little different from other protocol messages in that it is only composed of a common header, with the message body left empty. A detailed description of the message is as follows:
ForCES元素定期发送心跳消息。FE心跳的参数化和策略定义作为FE协议对象LFB的组件进行管理，并可由CE通过配置消息进行设置。Heartbeat消息与其他协议消息稍有不同，因为它只由一个公共头组成，消息体保留为空。该消息的详细说明如下：
Message transfer direction:
消息传输方向：
FE to CE or CE to FE
FE对CE或CE对FE
Message header:
消息头：
The Message Type in the message header is set to MessageType = 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. The ACK flag in the header MUST be set to either 'NoACK' or 'AlwaysACK' when the HB is sent.
消息头中的消息类型设置为MessageType='Heartbeat'。第4.3.3节描述了使用的HB机制。发送HB时，报头中的ACK标志必须设置为“NoACK”或“AlwaysACK”。
* When set to 'NoACK', the HB is not soliciting for a response.
* 当设置为“NoACK”时，HB不会请求响应。
* When set to 'AlwaysACK', the HB Message sender is always expecting a response from its receiver. According to the HB policies defined in Section 7.3.1, only the CE can send such an HB message to query FE liveness. For simplicity and because of the minimal nature of the HB message, the response to an HB message is another HB message, i.e., no specific HB Response message is defined. Whenever an FE receives an HB message marked with 'AlwaysACK' from the CE, the FE MUST send an HB message back immediately. The HB message sent by the FE in response to the 'AlwaysACK' MUST modify the source and destination IDs so that the ID of the FE is the source ID and the CE ID of the sender is the destination ID, and MUST change the ACK information to 'NoACK'. A CE MUST NOT respond to an HB message with 'AlwaysACK' set.
* 当设置为“AlwaysACK”时，HB消息发送方总是希望其接收方做出响应。根据第7.3.1节中定义的HB策略，只有CE可以发送此类HB消息来查询FE活跃度。为简单起见，由于HB消息的最小性质，对HB消息的响应是另一个HB消息，即未定义特定的HB响应消息。每当FE从CE收到标有“AlwaysACK”的HB消息时，FE必须立即将HB消息发回。FE为响应“AlwaysACK”而发送的HB消息必须修改源和目标ID，以便FE的ID为源ID，发送方的CE ID为目标ID，并且必须将ACK信息更改为“NoACK”。CE不得响应设置了“AlwaysACK”的HB消息。
* When set to anything else other than 'NoACK' or 'AlwaysACK', the HB message is treated as if it was a 'NoACK'.
* 当设置为“NoACK”或“AlwaysACK”以外的任何其他值时，HB消息将被视为“NoACK”。
The correlator field in the HB message header SHOULD be set accordingly when a response is expected so that a receiver can correlate the response correctly. The correlator field MAY be ignored if no response is expected.
当预期响应时，应相应地设置HB消息头中的correlator字段，以便接收方能够正确关联响应。如果预期没有响应，则可以忽略correlator字段。
Message body:
消息正文：
The message body is empty for the Heartbeat message.
心跳消息的消息正文为空。
The ForCES protocol provides mechanisms for CE redundancy and failover, in order to support High Availability as defined in [RFC3654]. FE redundancy and FE to FE interaction is currently out of scope of this document. There can be multiple redundant CEs and FEs in a ForCES NE. However, at any one time only one primary CE can control the FEs though there can be multiple secondary CEs. The FE and the CE PL are aware of the primary and secondary CEs. This information (primary, secondary CEs) is configured in the FE and in the CE PLs during pre-association by the FEM and the CEM respectively. Only the primary CE sends control messages to the FEs.
ForCES协议提供CE冗余和故障切换机制，以支持[RFC3654]中定义的高可用性。FE冗余和FE-to-FE交互目前不在本文件范围内。一个网元中可以有多个冗余CE和FEs。然而，尽管可以有多个辅助CE，但在任何时候只有一个主CE可以控制FEs。FE和CE PL知道主要和次要CE。FEM和CEM分别在预关联期间在FE和CE PLs中配置该信息（主要、次要CE）。只有主CE向FEs发送控制消息。
High Availability parameterization in an FE is driven by configuring the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1). The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE
FE中的高可用性参数化通过配置FE协议对象LFB来驱动（请参阅附录B和第7.3.1节）。FE心跳间隔、CE心跳死亡间隔和CE
Heartbeat policy help in detecting connectivity problems between an FE and CE. The CE failover policy defines the reaction on a detected failure.
心跳策略有助于检测FE和CE之间的连接问题。CE故障切换策略定义对检测到的故障的反应。
Figure 44 extends the state machine illustrated in Figure 4 to allow for new states that facilitate connection recovery.
图44扩展了图4所示的状态机，以允许有助于连接恢复的新状态。
(CE issues Teardown || +-----------------+
Lost association) && | Pre-association |
CE failover policy = 0 | (Association |
+------------>-->-->| in +<----+
| | progress) | |
| CE issues +--------+--------+ |
| Association | | CFTI
| Setup V | timer
| ___________________+ | expires
| | |
| V ^
+-+-----------+ +-------+-----+
| | | Not |
| | (CE issues Teardown || | Associated |
| | Lost association) && | |
| Associated | CE failover policy = 1 | (May |
| | | Continue |
| |---------->------->------>| Forwarding)|
| | | |
+-------------+ +-------------+
^ V
| |
| CE issues |
| Association |
| Setup |
+_________________________________________+
(CE issues Teardown || +-----------------+
Lost association) && | Pre-association |
CE failover policy = 0 | (Association |
+------------>-->-->| in +<----+
| | progress) | |
| CE issues +--------+--------+ |
| Association | | CFTI
| Setup V | timer
| ___________________+ | expires
| | |
| V ^
+-+-----------+ +-------+-----+
| | | Not |
| | (CE issues Teardown || | Associated |
| | Lost association) && | |
| Associated | CE failover policy = 1 | (May |
| | | Continue |
| |---------->------->------>| Forwarding)|
| | | |
+-------------+ +-------------+
^ V
| |
| CE issues |
| Association |
| Setup |
+_________________________________________+
Figure 44: FE State Machine Considering HA
图44：考虑HA的FE状态机
Section 4.2 describes transitions between the pre-association, associated, and not associated states.
第4.2节描述了预关联、关联和非关联状态之间的转换。
When communication fails between the FE and CE (which can be caused by either the CE or link failure but not FE related), either the TML on the FE will trigger the FE PL regarding this failure or it will be detected using the HB messages between FEs and CEs. The communication failure, regardless of how it is detected, MUST be considered as a loss of association between the CE and corresponding FE.
当FE和CE之间的通信失败时（可能由CE或链路故障引起，但与FE无关），FE上的TML将触发与此故障相关的FE PL，或者将使用FEs和CE之间的HB消息进行检测。无论如何检测到通信故障，都必须将其视为CE和相应FE之间失去关联。
If the FE's FEPO CE failover policy is configured to mode 0 (the default), it will immediately transition to the pre-association phase. This means that if association is again established, all FE state will need to be re-established.
如果FE的FEPO CE故障切换策略配置为模式0（默认），则它将立即过渡到关联前阶段。这意味着，如果再次建立关联，则需要重新建立所有FE状态。
If the FE's FEPO CE failover policy is configured to mode 1, it indicates that the FE is capable of HA restart recovery. In such a case, the FE transitions to the not associated state and the CEFTI timer is started. The FE MAY continue to forward packets during this state. It MAY also recycle through any configured secondary CEs in a round-robin fashion. It first adds its primary CE to the tail of backup CEs and sets its primary CE to be the first secondary. It then attempts to associate with the CE designated as the new primary CE. If it fails to re-associate with any CE and the CEFTI expires, the FE then transitions to the pre-association state.
如果FE的FEPO CE故障切换策略配置为模式1，则表示FE能够进行HA重启恢复。在这种情况下，FE转换到非关联状态，并且CEFTI定时器启动。FE可在该状态期间继续转发分组。它还可以以循环方式通过任何配置的辅助CE进行循环。它首先将其主CE添加到备份CE的尾部，并将其主CE设置为第一个辅助CE。然后，它尝试与指定为新主CE的CE关联。如果FE未能与任何CE重新关联，且CEFTI过期，则FE将转换到预关联状态。
If the FE, while in the not associated state, manages to reconnect to a new primary CE before CEFTI expires, it transitions to the associated state. Once re-associated, the FE tries to recover any state that may have been lost during the not associated state. How the FE achieves this is out of scope for this document.
如果FE在未关联状态下，在CEFTI到期之前成功重新连接到新的主CE，则它将转换到关联状态。一旦重新关联，FE将尝试恢复在未关联状态期间丢失的任何状态。FE如何实现这一点超出了本文件的范围。
Figure 45 below illustrates the ForCES message sequences that the FE uses to recover the connection.
下面的图45说明了FE用于恢复连接的强制消息序列。
FE CE Primary CE Secondary
| | |
| Asso Estb,Caps exchg | |
1 |<--------------------->| |
| | |
| All msgs | |
2 |<--------------------->| |
| | |
| | |
| FAILURE |
| |
| Asso Estb,Caps exchange |
3 |<------------------------------------------>|
| |
| Event Report (pri CE down) |
4 |------------------------------------------->|
| |
| All Msgs |
5 |<------------------------------------------>|
FE CE Primary CE Secondary
| | |
| Asso Estb,Caps exchg | |
1 |<--------------------->| |
| | |
| All msgs | |
2 |<--------------------->| |
| | |
| | |
| FAILURE |
| |
| Asso Estb,Caps exchange |
3 |<------------------------------------------>|
| |
| Event Report (pri CE down) |
4 |------------------------------------------->|
| |
| All Msgs |
5 |<------------------------------------------>|
Figure 45: CE Failover for Report Primary Mode
图45：报告主模式的CE故障切换
A CE-to-CE synchronization protocol would be needed to support fast failover as well as to address some of the corner cases; however, this will not be defined by the ForCES protocol as it is out of scope for this specification.
需要CE-to-CE同步协议来支持快速故障切换以及解决一些紧急情况；但是，由于这超出了本规范的范围，因此ForCES协议不会对此进行定义。
An explicit message (a Config message setting primary CE component in the FE Protocol Object) from the primary CE can also be used to change the primary CE for an FE during normal protocol operation.
来自主CE的显式消息（FE协议对象中设置主CE组件的配置消息）也可用于在正常协议操作期间更改FE的主CE。
Also note that the FEs in a ForCES NE could also use a multicast CE ID, i.e., they could be associated with a group of CEs (this assumes the use of a CE-CE synchronization protocol, which is out of scope for this specification). In this case, the loss of association would mean that communication with the entire multicast group of CEs has been lost. The mechanisms described above will apply for this case as well during the loss of association. If, however, the secondary CE was also using the multicast CE ID that was lost, then the FE will need to form a new association using a different CE ID. If the capability exists, the FE MAY first attempt to form a new association with the original primary CE using a different non-multicast CE ID.
还要注意，forcesne中的FEs也可以使用多播CE ID，即，它们可以与一组CE相关联（这假设使用CE-CE同步协议，这超出了本规范的范围）。在这种情况下，关联的丢失将意味着与ce的整个多播组的通信已经丢失。上述机制也将适用于这种情况下失去联系的情况。但是，如果辅助CE也在使用丢失的多播CE ID，则FE将需要使用不同的CE ID形成新关联。如果能力存在，FE可能首先尝试使用不同的非多播CE ID与原始主CE形成新关联。
TML level:
TML级别：
1. The TML controls logical connection availability and failover.
1. TML控制逻辑连接可用性和故障切换。
2. The TML also controls peer HA management.
2. TML还控制对等HA管理。
At this level, control of all lower layers, for example, transport level (such as IP addresses, MAC addresses, etc.) and associated links going down are the role of the TML.
在这个级别上，TML的角色是控制所有较低层，例如，传输级别（如IP地址、MAC地址等）和下行的相关链路。
PL level:
损益水平：
All other functionality, including configuring the HA behavior during setup, the CE IDs used to identify primary and secondary CEs, protocol messages used to report CE failure (Event Report), Heartbeat messages used to detect association failure, messages to change the primary CE (Config), and other HA-related operations described before, are the PL responsibility.
所有其他功能，包括在安装期间配置HA行为、用于标识主CE和辅助CE的CE ID、用于报告CE故障（事件报告）的协议消息、用于检测关联故障的心跳消息、用于更改主CE（配置）的消息，以及前面描述的其他HA相关操作，是PL的责任。
To put the two together, if a path to a primary CE is down, the TML would take care of failing over to a backup path, if one is available. If the CE is totally unreachable, then the PL would be informed and it would take the appropriate actions described earlier.
为了将两者结合在一起，如果主CE的路径断开，TML将负责故障切换到备份路径（如果有）。如果CE完全无法访问，则会通知PL并采取前面描述的适当措施。
The ForCES framework document [RFC3746], Section 8, goes into extensive detail on a variety of security threats, the possible effects of those threats on the protocol, and responses to those threats. This document does not repeat that discussion; the reader is referred to the ForCES framework document [RFC3746] for those details and how the ForCES architecture addresses them.
部队框架文件[RFC3746]第8节详细介绍了各种安全威胁、这些威胁对协议的可能影响以及对这些威胁的应对措施。本文件不重复上述讨论；读者可参考ForCES框架文件[RFC3746]了解这些详细信息以及ForCES架构如何解决这些问题。
ForCES PL uses security services provided by the ForCES TML. The TML provides security services such as endpoint authentication service, message authentication service, and confidentiality service. Endpoint authentication service is invoked at the time of the pre-association connection establishment phase and message authentication is performed whenever the FE or CE receives a packet from its peer.
部队PL使用部队TML提供的安全服务。TML提供安全服务，如端点身份验证服务、消息身份验证服务和机密性服务。端点认证服务在预关联连接建立阶段时被调用，并且每当FE或CE从其对等方接收到数据包时，就执行消息认证。
The following are the general security mechanisms that need to be in place for ForCES PL.
以下是部队PL需要建立的一般安全机制。
o Security mechanisms are session controlled -- that is, once the security is turned on depending upon the chosen security level (No Security, Authentication, Confidentiality), it will be in effect for the entire duration of the session.
o 安全机制是会话控制的——也就是说，一旦根据所选的安全级别（无安全性、身份验证、机密性）打开了安全性，它将在会话的整个持续时间内生效。
o An operator should configure the same security policies for both primary and backup FEs and CEs (if available). This will ensure uniform operations and avoid unnecessary complexity in policy configuration.
o 操作员应为主FEs和备用FEs和CE（如果可用）配置相同的安全策略。这将确保统一的操作，并避免策略配置中不必要的复杂性。
When "No Security" is chosen for ForCES protocol communication, both endpoint authentication and message authentication service needs to be performed by ForCES PL. Both these mechanism are weak and do not involve cryptographic operation. An operator can choose "No Security" level when the ForCES protocol endpoints are within a single box, for example.
当ForCES协议通信选择“无安全性”时，端点身份验证和消息身份验证服务都需要由ForCES PL执行。这两种机制都很弱，不涉及加密操作。例如，当ForCES协议端点位于单个框内时，操作员可以选择“无安全性”级别。
In order to have interoperable and uniform implementation across various security levels, each CE and FE endpoint MUST implement this level.
为了在不同的安全级别上实现互操作性和统一性，每个CE和FE端点必须实现此级别。
What is described below (in Section 9.1.1 and Section 9.1.2) are error checks and not security procedures. The reader is referred to Section 9.2 for security procedures.
以下所述（第9.1.1节和第9.1.2节）是错误检查，而不是安全程序。读者可参考第9.2节了解安全程序。
Each CE and FE PL maintains a list of associations as part of its configuration. This is done via the CEM and FEM interfaces. An FE MUST connect to only those CEs that are configured via the FEM; similarly, a CE should accept the connection and establish associations for the FEs which are configured via the CEM. The CE should validate the FE identifier before accepting the connections during the pre-association phase.
每个CE和FE PL维护一个关联列表，作为其配置的一部分。这是通过CEM和FEM接口完成的。FE必须仅连接到通过FEM配置的CE；同样，CE应接受连接并为通过CEM配置的FEs建立关联。在预关联阶段接受连接之前，CE应验证FE标识符。
When a CE or FE initiates a message, the receiving endpoint MUST validate the initiator of the message by checking the common header CE or FE identifiers. This will ensure proper protocol functioning. This extra processing step is recommended even when the underlying TML layer security services exist.
当CE或FE发起消息时，接收端点必须通过检查公共头CE或FE标识符来验证消息的发起方。这将确保协议正常运行。即使存在底层TML层安全服务，也建议执行此额外的处理步骤。
This section is applicable if an operator wishes to use the TML security services. A ForCES TML MUST support one or more security services such as endpoint authentication service, message authentication service, and confidentiality service, as part of TML security layer functions. It is the responsibility of the operator to select an appropriate security service and configure security policies accordingly. The details of such configuration are outside the scope of the ForCES PL and are dependent on the type of transport protocol and the nature of the connection.
如果运营商希望使用TML安全服务，则本节适用。强制TML必须支持一个或多个安全服务，例如端点身份验证服务、消息身份验证服务和保密服务，作为TML安全层功能的一部分。运营商有责任选择适当的安全服务并相应地配置安全策略。此类配置的详细信息不在强制PL的范围内，并且取决于传输协议的类型和连接的性质。
All these configurations should be done prior to starting the CE and FE.
所有这些配置应在启动CE和FE之前完成。
When certificates-based authentication is being used at the TML, the certificate can use a ForCES-specific naming structure as certificate names and, accordingly, the security policies can be configured at the CE and FE.
当TML使用基于证书的身份验证时，证书可以使用强制特定的命名结构作为证书名称，因此，可以在CE和FE上配置安全策略。
The reader is asked to refer to specific TML documents for details on the security requirements specific to that TML.
读者需要参考特定TML文档，以了解特定于该TML的安全要求的详细信息。
When TML security services are enabled, the ForCES TML performs endpoint authentication. Security association is established between CE and FE and is transparent to the ForCES PL.
启用TML安全服务后，TML将执行端点身份验证。安全协会在CE和FE之间建立，对部队PL透明。
This is a TML-specific operation and is transparent to the ForCES PL. For details, refer to Section 5.
这是TML特定的操作，对部队PL是透明的。有关详细信息，请参阅第5节。
This is a TML-specific operation and is transparent to the ForCES PL. For details, refer to Section 5.
这是TML特定的操作，对部队PL是透明的。有关详细信息，请参阅第5节。
The authors of this document would like to acknowledge and thank the ForCES Working Group and especially the following: Furquan Ansari, Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M. Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Zsolt Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their contributions. We would also like to thank David Putzolu and Patrick Droz for their comments and suggestions on the protocol and for their infinite patience. We would also like to thank Sue Hares and Alia Atlas for extensive reviews of the document.
本文件的作者要感谢部队工作组，特别是以下人员：Furquan Ansari、Alex Audu、Steven Blake、Shuchi Chawla、Alan DeKok、Ellen M.Deleganes、郭晓义、郭云飞、Evangelos Haleplidis、Zsolt Haraszti、贾丰根、John C.Lin、Alistair Munro、Jeff Pickering、T.Sridhlar、，感谢王光明、吴朝平和杨丽丽的贡献。我们还要感谢David Putzolu和Patrick Droz就议定书提出的意见和建议以及他们的无限耐心。我们还要感谢Sue Hares和Alia Atlas对该文件的广泛审查。
Alia Atlas did a wonderful job of shaping the document to make it more readable by providing the IESG feedback.
Alia Atlas通过提供IESG反馈，出色地塑造了文档，使其更具可读性。
Ross Callon was instrumental in getting us over major humps to getting this document published.
罗斯·卡隆帮助我们克服了重大困难，使这份文件得以出版。
The editors have used the xml2rfc [RFC2629] tools in creating this document and are very grateful for the existence and quality of these tools. The editor is also grateful to Elwyn Davies for his help in correcting the XML source of this document.
编辑在创建本文档时使用了xml2rfc[RFC2629]工具，非常感谢这些工具的存在和质量。编辑还感谢Elwyn Davies帮助更正本文档的XML源代码。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, December 2008.
[RFC5390]Rosenberg，J.，“会话启动协议中过载管理的要求”，RFC 53902008年12月。
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol", RFC 5811, March 2010.
[RFC5811]Hadi Salim，J.和K.Ogawa，“转发和控制元素分离（ForCES）协议的基于SCTP的传输映射层（TML）”，RFC 58112010年3月。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.
[RFC5812]Halpern，J.和J.Hadi Salim，“转发和控制单元分离（部队）转发单元模型”，RFC 5812，2010年3月。
[2PCREF] Gray, J., "Notes on database operating systems", in "Operating Systems: An Advanced Course" Lecture Notes in Computer Science, Vol. 60, pp. 394-481, Springer-Verlag, 1978.
[2PCREF]Gray，J.，“关于数据库操作系统的说明”，在“操作系统：高级课程”中，《计算机科学讲义》，第60卷，第394-481页，Springer Verlag，1978年。
[ACID] Haerder, T. and A. Reuter, "Principles of Transaction-Orientated Database Recovery", 1983.
[ACID]Haerder，T.和A.Reuter，“面向事务的数据库恢复原则”，1983年。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]Rose，M.，“使用XML编写I-D和RFC”，RFC 26292999年6月。
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3654]Khosravi，H.和T.Anderson，“IP控制和转发分离的要求”，RFC 3654，2003年11月。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004.
[RFC3746]Yang，L.，Dantu，R.，Anderson，T.，和R.Gopal，“转发和控制单元分离（部队）框架”，RFC 37462004年4月。
Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following namespaces are defined in ForCES.
按照“在RFCs中编写IANA注意事项部分的指南”（RFC 5226[RFC5226]）中概述的策略，以下名称空间在ForCES中定义。
o Message Type Namespace, Section 7
o 消息类型名称空间，第7节
o Operation Type Namespace, Section 7.1.6
o 操作类型名称空间，第7.1.6节
o Header Flags, Section 6.1
o 标题标志，第6.1节
o TLV Type, Section 7
o TLV类型，第7节
o TLV Result Values, Section 7.1.7
o TLV结果值，第7.1.7节
o LFB Class ID, Section 7.1.5 (resolved by model document, [RFC5812].
o LFB类ID，第7.1.5节（由模型文件[RFC5812]解决）。
o Result: Association Setup Response, Section 7.5.2
o 结果：关联设置响应，第7.5.2节
o Reason: Association Teardown Message, Section 7.5.3
o 原因：关联拆卸消息，第7.5.3节
The Message Type is an 8-bit value. The following is the guideline for defining the Message Type namespace:
消息类型为8位值。以下是定义消息类型命名空间的指南：
Message Types 0x00 - 0x1F Message Types in this range are part of the base ForCES protocol. Message Types in this range are allocated through an IETF consensus action [RFC5226].
此范围内的消息类型0x00-0x1F消息类型是基本部队协议的一部分。此范围内的消息类型通过IETF一致行动[RFC5226]进行分配。
Values assigned by this specification:
本规范指定的值：
0x00 Reserved 0x01 AssociationSetup 0x02 AssociationTeardown 0x03 Config 0x04 Query 0x05 EventNotification 0x06 PacketRedirect 0x07 - 0x0E Reserved 0x0F Hearbeat 0x11 AssociationSetupResponse 0x12 Reserved 0x13 ConfigResponse 0x14 QueryResponse
0x00保留0x01关联设置0x02关联搜索0x03配置0x04查询0x05事件通知0x06包重定向0x07-0x0E保留0x0F Hearbeat 0x11关联设置响应0x12保留0x13配置响应0x14查询响应
Message Types 0x20 - 0x7F Message Types in this range are Specification Required [RFC5226]. Message Types using this range MUST be documented in an RFC or other permanent and readily available reference.
此范围内的消息类型0x20-0x7F需要规范[RFC5226]。使用此范围的消息类型必须记录在RFC或其他永久且随时可用的参考文件中。
Message Types 0x80 - 0xFF Message Types in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Message Type namespace is unnecessary.
此范围内的消息类型0x80-0xFF消息类型是为供应商专用扩展保留的，由各个供应商负责。IANA不需要管理此范围的消息类型命名空间。
The Operation Selection (OPER-TLV) namespace is 16 bits long. The following is the guideline for managing the OPER-TLV namespace.
操作选择（OPER-TLV）命名空间的长度为16位。以下是管理OPER-TLV命名空间的指南。
OPER-TLV Type 0x0000-0x0FF OPER-TLV Types in this range are allocated through an IETF consensus process [RFC5226].
此范围内的OPER-TLV类型0x0000-0x0FF OPER-TLV类型通过IETF协商一致过程分配[RFC5226]。
Values assigned by this specification:
本规范指定的值：
0x0000 Reserved 0x0001 SET 0x0002 SET-PROP 0x0003 SET-RESPONSE 0x0004 SET-PROP-RESPONSE 0x0005 DEL 0x0006 DEL-RESPONSE 0x0007 GET 0x0008 GET-PROP 0x0009 GET-RESPONSE 0x000A GET-PROP-RESPONSE 0x000B REPORT 0x000C COMMIT 0x000D COMMIT-RESPONSE 0x000E TRCOMP
0x0000保留0x0001集0x0002集-PROP 0x0003集-RESPONSE 0x0004集-PROP-RESPONSE 0x0005 DEL 0x0006 DEL-RESPONSE 0x0007获取0x0008获取-PROP 0x0009获取-RESPONSE 0x000A获取-PROP-RESPONSE 0x000B报告0x000C提交0x000D提交-RESPONSE 0x000E TRCOMP
OPER-TLV Type 0x0100-0x7FFF OPER-TLV Types using this range MUST be documented in an RFC or other permanent and readily available reference [RFC5226].
使用此范围的OPER-TLV类型0x0100-0x7FFF OPER-TLV类型必须记录在RFC或其他永久性且随时可用的参考文件[RFC5226]中。
OPER-TLV Type 0x8000-0xFFFF OPER-TLV Types in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the OPER-TLV Type namespace is unnecessary.
此范围内的OPER-TLV类型0x8000-0xFFFF OPER-TLV类型是为供应商专用扩展保留的，由各个供应商负责。IANA不需要管理此范围的OPER-TLV类型命名空间。
The Header flag field is 32 bits long. Header flags are part of the ForCES base protocol. Header flags are allocated through an IETF consensus action [RFC5226].
标头标志字段的长度为32位。标头标志是ForCES base协议的一部分。头标志通过IETF一致行动[RFC5226]分配。
The TLV Type namespace is 16 bits long. The following is the guideline for managing the TLV Type namespace.
TLV类型命名空间的长度为16位。以下是管理TLV类型命名空间的指南。
TLV Type 0x0000-0x01FF TLV Types in this range are allocated through an IETF consensus process [RFC5226].
此范围内的TLV类型0x0000-0x01FF TLV类型通过IETF共识过程[RFC5226]分配。
Values assigned by this specification:
本规范指定的值：
0x0000 Reserved 0x0001 REDIRECT-TLV 0x0010 ASResult-TLV 0x0011 ASTreason-TLV 0x1000 LFBselect-TLV 0x0110 PATH-DATA-TLV 0x0111 KEYINFO-TLV 0x0112 FULLDATA-TLV 0x0113 SPARSEDATA-TLV 0x0114 RESULT-TLV 0x0115 METADATA-TLV 0x0116 REDIRECTDATA-TLV
0x0000保留0x0001重定向-TLV 0x0010 ASResult TLV 0x0011 ASTreason TLV 0x1000 LFB选择TLV 0x0110 PATH-DATA-TLV 0x0111 KEYINFO-TLV 0x0112 FULLDATA-TLV 0x0113 ASResult TLV 0x0115元数据-TLV 0x0116重定向数据-TLV
TLV Type 0x0200-0x7FFF TLV Types using this range MUST be documented in an RFC or other permanent and readily available reference [RFC5226].
使用此范围的TLV类型0x0200-0x7FFF TLV类型必须记录在RFC或其他永久性且随时可用的参考文献[RFC5226]中。
TLV Type 0x8000-0xFFFF TLV Types in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the TLV Type namespace is unnecessary.
此范围内的TLV类型0x8000-0xFFFF TLV类型是为供应商专用扩展保留的，由各个供应商负责。IANA不需要管理此范围的TLV类型命名空间。
The RESULT-TLV RTesult Value is an 8-bit value.
RESULT-TLV RTesult值为8位值。
0x00 E_SUCCESS 0x01 E_INVALID_HEADER 0x02 E_LENGTH_MISMATCH 0x03 E_VERSION_MISMATCH 0x04 E_INVALID_DESTINATION_PID 0x05 E_LFB_UNKNOWN 0x06 E_LFB_NOT_FOUND 0x07 E_LFB_INSTANCE_ID_NOT_FOUND 0x08 E_INVALID_PATH 0x09 E_COMPONENT_DOES_NOT_EXIST 0x0A E_EXISTS 0x0B E_NOT_FOUND 0x0C E_READ_ONLY 0x0D E_INVALID_ARRAY_CREATION 0x0E E_VALUE_OUT_OF_RANGE 0x0F E_CONTENTS_TOO_LONG 0x10 E_INVALID_PARAMETERS 0x11 E_INVALID_MESSAGE_TYPE 0x12 E_E_INVALID_FLAGS 0x13 E_INVALID_TLV 0x14 E_EVENT_ERROR 0x15 E_NOT_SUPPORTED 0x16 E_MEMORY_ERROR 0x17 E_INTERNAL_ERROR 0x18-0xFE Reserved 0xFF E_UNSPECIFIED_ERROR
0x00 E\u成功0x01 E\u无效\u头0x02 E\u长度\u不匹配0x03 E\u版本\u不匹配0x04 E\u无效\u目的地\u PID 0x05 E\u LFB\u未知0x06 E\u LFB\u未找到0x07 E\u LFB\u实例\u ID未找到0x08 E\u无效\u路径0x09 E\u组件\u不存在0x0A E\u存在0x0B E\u未找到0x0C E\u只读0x0D E\u无效数组\u创建值超出0xU范围E_内容太长0x10 E_无效参数0x11 E_无效消息类型0x12 E_无效标志0x13 E_无效标志0x14 E_事件错误0x15 E_不受支持0x16 E_内存错误0x17 E_内部错误0x18-0xFE保留0xFF E_未指定错误
All values not assigned in this specification are designated as Assignment by Expert Review.
本规范中未指定的所有值均由专家评审指定为指定值。
The Association Setup Response namespace is 32 bits long. The following is the guideline for managing the Association Setup Response namespace.
关联设置响应命名空间的长度为32位。以下是管理关联设置响应命名空间的指南。
Association Setup Response 0x0000-0x00FF Association Setup Responses in this range are allocated through an IETF consensus process [RFC5226].
此范围内的关联设置响应0x0000-0x00FF关联设置响应通过IETF共识过程[RFC5226]分配。
Values assigned by this specification:
本规范指定的值：
0x0000 Success 0x0001 FE ID Invalid 0x0002 Permission Denied
0x0000成功0x0001 FE ID无效0x0002权限被拒绝
Association Setup Response 0x0100-0x0FFF Association Setup Responses in this range are Specification Required [RFC5226]. Values using this range MUST be documented in an RFC or other permanent and readily available reference [RFC5226].
此范围内的关联设置响应0x0100-0x0FFF需要规范[RFC5226]。使用此范围的值必须记录在RFC或其他永久性且随时可用的参考文献[RFC5226]中。
Association Setup Response 0x1000-0xFFFF Association Setup Responses in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Association Setup Response namespace is unnecessary.
此范围内的关联设置响应0x1000-0xFFFF关联设置响应保留给供应商专用扩展，由各个供应商负责。IANA不需要管理此范围的关联设置响应命名空间。
The Association Teardown Message namespace is 32 bits long. The following is the guideline for managing the Association Teardown Message namespace.
关联拆卸消息命名空间的长度为32位。以下是管理关联拆卸消息命名空间的指南。
Association Teardown Message 0x00000000-0x0000FFFF Association Teardown Messages in this range are allocated through an IETF consensus process [RFC5226].
此范围内的关联拆卸消息0x00000000-0x0000FFFF关联拆卸消息通过IETF共识进程[RFC5226]分配。
Values assigned by this specification:
本规范指定的值：
0x00000000 Normal - teardown by administrator 0x00000001 Error - loss of heartbeats 0x00000002 Error - loss of bandwidth 0x00000003 Error - out of Memory 0x00000004 Error - application crash 0x000000FF Error - unspecified
0x00000000正常-管理员拆除0x00000001错误-心跳丢失0x00000002错误-带宽丢失0x00000003错误-内存不足0x00000004错误-应用程序崩溃0x000000FF错误-未指定
Association Teardown Message 0x00010000-0x7FFFFFFF Association Teardown Messages in this range are Specification Required [RFC5226]. Association Teardown Messages using this range MUST be documented in an RFC or other permanent and readily available references. [RFC5226].
此范围内的关联拆卸消息0x00010000-0x7FFFFFFF关联拆卸消息需要规范[RFC5226]。使用此范围的关联拆卸消息必须记录在RFC或其他永久且随时可用的参考文件中。[RFC5226]。
Association Teardown Message 0x80000000-0xFFFFFFFFF Association Teardown Messages in this range are reserved for vendor private extensions and are the responsibility of individual
此范围内的关联拆卸消息0x80000000-0xFFFFFFFFFFF关联拆卸消息保留给供应商专用扩展，由个人负责
vendors. IANA management of this range of the Association Teardown Message namespace is unnecessary.
供应商。IANA不需要管理此范围的关联拆卸消息命名空间。
The schema described below conforms to the LFB schema described in the ForCES model [RFC5812].
下面描述的模式符合部队模型[RFC5812]中描述的LFB模式。
Section 7.3.1 describes the details of the different components defined in this definition.
第7.3.1节描述了本定义中定义的不同组件的详细信息。
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="FEPO">
<!-- XXX -->
<dataTypeDefs>
<dataTypeDef>
<name>CEHBPolicyValues</name>
<synopsis>
The possible values of CE heartbeat policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEHBPolicy0</name>
<synopsis>
The CE heartbeat policy 0
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEHBPolicy1</name>
<synopsis>
The CE heartbeat policy 1
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="FEPO">
<!-- XXX -->
<dataTypeDefs>
<dataTypeDef>
<name>CEHBPolicyValues</name>
<synopsis>
The possible values of CE heartbeat policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEHBPolicy0</name>
<synopsis>
The CE heartbeat policy 0
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEHBPolicy1</name>
<synopsis>
The CE heartbeat policy 1
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FEHBPolicyValues</name>
<synopsis>
The possible values of FE heartbeat policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<dataTypeDef>
<name>FEHBPolicyValues</name>
<synopsis>
The possible values of FE heartbeat policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FEHBPolicy0</name>
<synopsis>
The FE heartbeat policy 0
</synopsis>
</specialValue>
<specialValue value="1">
<name>FEHBPolicy1</name>
<synopsis>
The FE heartbeat policy 1
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<specialValue value="0">
<name>FEHBPolicy0</name>
<synopsis>
The FE heartbeat policy 0
</synopsis>
</specialValue>
<specialValue value="1">
<name>FEHBPolicy1</name>
<synopsis>
The FE heartbeat policy 1
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FERestartPolicyValues</name>
<synopsis>
The possible values of FE restart policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FERestartPolicy0</name>
<synopsis>
The FE restart policy 0
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FERestartPolicyValues</name>
<synopsis>
The possible values of FE restart policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FERestartPolicy0</name>
<synopsis>
The FE restart policy 0
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>CEFailoverPolicyValues</name>
<synopsis>
The possible values of CE failover policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEFailoverPolicy0</name>
<synopsis>
The CE failover policy 0
</synopsis>
</specialValue>
<dataTypeDef>
<name>CEFailoverPolicyValues</name>
<synopsis>
The possible values of CE failover policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEFailoverPolicy0</name>
<synopsis>
The CE failover policy 0
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEFailoverPolicy1</name>
<synopsis>
The CE failover policy 1
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<specialValue value="1">
<name>CEFailoverPolicy1</name>
<synopsis>
The CE failover policy 1
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FEHACapab</name>
<synopsis>
The supported HA features
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>GracefullRestart</name>
<synopsis>
The FE supports Graceful Restart
</synopsis>
</specialValue>
<specialValue value="1">
<name>HA</name>
<synopsis>
The FE supports HA
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
</dataTypeDefs>
<dataTypeDef>
<name>FEHACapab</name>
<synopsis>
The supported HA features
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>GracefullRestart</name>
<synopsis>
The FE supports Graceful Restart
</synopsis>
</specialValue>
<specialValue value="1">
<name>HA</name>
<synopsis>
The FE supports HA
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="2">
<name>FEPO</name>
<synopsis>
The FE Protocol Object
</synopsis>
<version>1.0</version>
<LFBClassDefs>
<LFBClassDef LFBClassID="2">
<name>FEPO</name>
<synopsis>
The FE Protocol Object
</synopsis>
<version>1.0</version>
<components>
<component componentID="1" access="read-only">
<name>CurrentRunningVersion</name>
<synopsis>Currently running ForCES version</synopsis>
<typeRef>uchar</typeRef>
<components>
<component componentID="1" access="read-only">
<name>CurrentRunningVersion</name>
<synopsis>Currently running ForCES version</synopsis>
<typeRef>uchar</typeRef>
</component>
<component componentID="2" access="read-only">
<name>FEID</name>
<synopsis>Unicast FEID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3" access="read-write">
<name>MulticastFEIDs</name>
<synopsis>
the table of all multicast IDs
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="4" access="read-write">
<name>CEHBPolicy</name>
<synopsis>
The CE Heartbeat Policy
</synopsis>
<typeRef>CEHBPolicyValues</typeRef>
</component>
<component componentID="5" access="read-write">
<name>CEHDI</name>
<synopsis>
The CE Heartbeat Dead Interval in millisecs
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="6" access="read-write">
<name>FEHBPolicy</name>
<synopsis>
The FE Heartbeat Policy
</synopsis>
<typeRef>FEHBPolicyValues</typeRef>
</component>
<component componentID="7" access="read-write">
<name>FEHI</name>
<synopsis>
The FE Heartbeat Interval in millisecs
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8" access="read-write">
<name>CEID</name>
<synopsis>
The Primary CE this FE is associated with
</synopsis>
</component>
<component componentID="2" access="read-only">
<name>FEID</name>
<synopsis>Unicast FEID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3" access="read-write">
<name>MulticastFEIDs</name>
<synopsis>
the table of all multicast IDs
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="4" access="read-write">
<name>CEHBPolicy</name>
<synopsis>
The CE Heartbeat Policy
</synopsis>
<typeRef>CEHBPolicyValues</typeRef>
</component>
<component componentID="5" access="read-write">
<name>CEHDI</name>
<synopsis>
The CE Heartbeat Dead Interval in millisecs
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="6" access="read-write">
<name>FEHBPolicy</name>
<synopsis>
The FE Heartbeat Policy
</synopsis>
<typeRef>FEHBPolicyValues</typeRef>
</component>
<component componentID="7" access="read-write">
<name>FEHI</name>
<synopsis>
The FE Heartbeat Interval in millisecs
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8" access="read-write">
<name>CEID</name>
<synopsis>
The Primary CE this FE is associated with
</synopsis>
<typeRef>uint32</typeRef>
</component>
<typeRef>uint32</typeRef>
</component>
<component componentID="9" access="read-write">
<name>BackupCEs</name>
<synopsis>
The table of all backup CEs other than the primary
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="10" access="read-write">
<name>CEFailoverPolicy</name>
<synopsis>
The CE Failover Policy
</synopsis>
<typeRef>CEFailoverPolicyValues</typeRef>
</component>
<component componentID="9" access="read-write">
<name>BackupCEs</name>
<synopsis>
The table of all backup CEs other than the primary
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="10" access="read-write">
<name>CEFailoverPolicy</name>
<synopsis>
The CE Failover Policy
</synopsis>
<typeRef>CEFailoverPolicyValues</typeRef>
</component>
<component componentID="11" access="read-write">
<name>CEFTI</name>
<synopsis>
The CE Failover Timeout Interval in millisecs
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="12" access="read-write">
<name>FERestartPolicy</name>
<synopsis>
The FE Restart Policy
</synopsis>
<typeRef>FERestartPolicyValues</typeRef>
</component>
<component componentID="13" access="read-write">
<name>LastCEID</name>
<synopsis>
The Primary CE this FE was last associated with
</synopsis>
<typeRef>uint32</typeRef>
</component>
</components>
<component componentID="11" access="read-write">
<name>CEFTI</name>
<synopsis>
The CE Failover Timeout Interval in millisecs
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="12" access="read-write">
<name>FERestartPolicy</name>
<synopsis>
The FE Restart Policy
</synopsis>
<typeRef>FERestartPolicyValues</typeRef>
</component>
<component componentID="13" access="read-write">
<name>LastCEID</name>
<synopsis>
The Primary CE this FE was last associated with
</synopsis>
<typeRef>uint32</typeRef>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>SupportableVersions</name>
<synopsis>
the table of ForCES versions that FE supports
<capabilities>
<capability componentID="30">
<name>SupportableVersions</name>
<synopsis>
the table of ForCES versions that FE supports
</synopsis>
<array type="variable-size">
<typeRef>uchar</typeRef>
</array>
</capability>
<capability componentID="31">
<name>HACapabilities</name>
<synopsis>
the table of HA capabilities the FE supports
</synopsis>
<array type="variable-size">
<typeRef>FEHACapab</typeRef>
</array>
</capability>
</capabilities>
</synopsis>
<array type="variable-size">
<typeRef>uchar</typeRef>
</array>
</capability>
<capability componentID="31">
<name>HACapabilities</name>
<synopsis>
the table of HA capabilities the FE supports
</synopsis>
<array type="variable-size">
<typeRef>FEHACapab</typeRef>
</array>
</capability>
</capabilities>
<events baseID="61">
<event eventID="1">
<name>PrimaryCEDown</name>
<synopsis>
The pimary CE has changed
</synopsis>
<eventTarget>
<eventField>LastCEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>LastCEID</eventField>
</eventReport>
</eventReports>
</event>
</events>
<events baseID="61">
<event eventID="1">
<name>PrimaryCEDown</name>
<synopsis>
The pimary CE has changed
</synopsis>
<eventTarget>
<eventField>LastCEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>LastCEID</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
Supportable Versions enumerates all ForCES versions that an FE supports.
可支持版本枚举FE支持的所有部队版本。
FEHACapab enumerates the HA capabilities of the FE. If the FE is not capable of graceful restarts or HA, then it will not be able to participate in HA as described in Section 8.1.
FEHACapab列举了FE的HA能力。如果FE无法正常重启或HA，则其将无法参与第8.1节所述的HA。
All components are explained in Section 7.3.1.
第7.3.1节对所有部件进行了说明。
In this section a few examples of data encoding are discussed. These example, however, do not show any padding.
本节将讨论几个数据编码示例。但是，这些示例没有显示任何填充。
==========
Example 1:
==========
==========
Example 1:
==========
Structure with three fixed-lengthof, mandatory fields.
结构，具有三个固定长度的必填字段。
struct S {
uint16 a
uint16 b
uint16 c
}
struct S {
uint16 a
uint16 b
uint16 c
}
(a) Describing all fields using SPARSEDATA-TLV
(a) 使用SPARA-TLV描述所有字段
PATH-DATA-TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
PATH-DATA-TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
(b) Describing a subset of fields
(b) 描述字段的子集
PATH-DATA-TLV Path to an instance of S ... SPARSEDATA-TLV ComponentIDof(a), lengthof(a), valueof(a) ComponentIDof(c), lengthof(c), valueof(c)
PATH-DATA-TLV指向S的实例的路径。。。a-TLV组件自由度（a）、长度（a）、值（a）组件自由度（c）、长度（c）、值（c）
Note: Even though there are non-optional components in structure S, since one can uniquely identify components, one can selectively send components of structure S (e.g., in the case of an update from CE to FE).
注：尽管结构S中存在非可选组件，但由于可以唯一标识组件，因此可以有选择地发送结构S的组件（例如，在从CE更新到FE的情况下）。
(c) Describing all fields using a FULLDATA-TLV
(c) 使用FULLDATA-TLV描述所有字段
PATH-DATA-TLV Path to an instance of S ... FULLDATA-TLV valueof(a) valueof(b) valueof(c)
PATH-DATA-TLV指向S的实例的路径。。。FULLDATA-TLV值（a）值（b）值（c）
==========
Example 2:
==========
==========
Example 2:
==========
Structure with three fixed-lengthof fields, one mandatory, two optional.
具有三个固定长度字段的结构，一个必填字段，两个可选字段。
struct T {
uint16 a
uint16 b (optional)
uint16 c (optional)
}
struct T {
uint16 a
uint16 b (optional)
uint16 c (optional)
}
This example is identical to example 1, as illustrated below.
该示例与示例1相同，如下所示。
(a) Describing all fields using SPARSEDATA-TLV
(a) 使用SPARA-TLV描述所有字段
PATH-DATA-TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
PATH-DATA-TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
(b) Describing a subset of fields using SPARSEDATA-TLV
(b) 使用SPARA-TLV描述字段子集
PATH-DATA-TLV Path to an instance of S ... SPARSEDATA-TLV ComponentIDof(a), lengthof(a), valueof(a) ComponentIDof(c), lengthof(c), valueof(c)
PATH-DATA-TLV指向S的实例的路径。。。a-TLV组件自由度（a）、长度（a）、值（a）组件自由度（c）、长度（c）、值（c）
(c) Describing all fields using a FULLDATA-TLV
(c) 使用FULLDATA-TLV描述所有字段
PATH-DATA-TLV Path to an instance of S ... FULLDATA-TLV valueof(a) valueof(b) valueof(c)
PATH-DATA-TLV指向S的实例的路径。。。FULLDATA-TLV值（a）值（b）值（c）
Note: FULLDATA-TLV _cannot_ be used unless all fields are being described.
注：除非描述了所有字段，否则不能使用FULLDATA-TLV。
==========
Example 3:
==========
==========
Example 3:
==========
Structure with a mix of fixed-lengthof and variable-lengthof fields, some mandatory, some optional. Note in this case, b is variable sized.
结构中混合了固定长度和可变长度字段，有些是必需的，有些是可选的。注：在这种情况下，b的大小是可变的。
struct U {
uint16 a
string b (optional)
uint16 c (optional)
}
struct U {
uint16 a
string b (optional)
uint16 c (optional)
}
(a) Describing all fields using SPARSEDATA-TLV
(a) 使用SPARA-TLV描述所有字段
Path to an instance of U ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
Path to an instance of U ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
(b) Describing a subset of fields using SPARSEDATA-TLV
(b) 使用SPARA-TLV描述字段子集
Path to an instance of U ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)
Path to an instance of U ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)
(c) Describing all fields using FULLDATA-TLV
(c) 使用FULLDATA-TLV描述所有字段
Path to an instance of U ... FULLDATA-TLV valueof(a) FULLDATA-TLV valueof(b) valueof(c)
指向U的实例的路径。。。FULLDATA-TLV值（a）FULLDATA-TLV值（b）值（c）
Note: The variable-length field requires the addition of a FULLDATA-TLV within the outer FULLDATA-TLV as in the case of component b above.
注：可变长度字段要求在外部FULLDATA-TLV中添加FULLDATA-TLV，与上述组件b的情况相同。
==========
Example 4:
==========
==========
Example 4:
==========
Structure containing an array of another structure type.
结构包含另一种结构类型的数组。
struct V {
uint32 x
uint32 y
struct U z[]
}
struct V {
uint32 x
uint32 y
struct U z[]
}
(a) Encoding using SPARSEDATA-TLV, with two instances of z[], also described with SPARSEDATA-TLV, assuming only the 10th and 15th subscripts of z[] are encoded.
(a) 使用SPARSTAT-TLV进行编码，z[]有两个实例，也使用SPARSTAT-TLV进行描述，假设仅对z[]的第10和第15个下标进行编码。
path to instance of V ...
SPARSEDATA-TLV
ComponentIDof(x), lengthof(x), valueof(x)
ComponentIDof(y), lengthof(y), valueof(y)
ComponentIDof(z), lengthof(all below)
ComponentID = 10 (i.e index 10 from z[]), lengthof(all below)
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentID = 15 (index 15 from z[]), lengthof(all below)
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)
path to instance of V ...
SPARSEDATA-TLV
ComponentIDof(x), lengthof(x), valueof(x)
ComponentIDof(y), lengthof(y), valueof(y)
ComponentIDof(z), lengthof(all below)
ComponentID = 10 (i.e index 10 from z[]), lengthof(all below)
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentID = 15 (index 15 from z[]), lengthof(all below)
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)
Note the holes in the components of z (10 followed by 15). Also note the gap in index 15 with only components a and c appearing but not b.
注意z组件中的孔（10后接15）。还要注意索引15中的间隙，其中仅出现组件a和c，而未出现组件b。
Assume LFB with the following components for the following use cases.
对于以下用例，假设LFB具有以下组件。
foo1, type u32, ID = 1
foo1，类型u32，ID=1
foo2, type u32, ID = 2
foo2，类型u32，ID=2
table1: type array, ID = 3
components are:
t1, type u32, ID = 1
t2, type u32, ID = 2 // index into table2
KEY: nhkey, ID = 1, V = t2
table1: type array, ID = 3
components are:
t1, type u32, ID = 1
t2, type u32, ID = 2 // index into table2
KEY: nhkey, ID = 1, V = t2
table2: type array, ID = 4
components are:
j1, type u32, ID = 1
j2, type u32, ID = 2
KEY: akey, ID = 1, V = { j1,j2 }
table2: type array, ID = 4
components are:
j1, type u32, ID = 1
j2, type u32, ID = 2
KEY: akey, ID = 1, V = { j1,j2 }
table3: type array, ID = 5 components are: someid, type u32, ID = 1 name, type string variable sized, ID = 2
表3：类型数组，ID=5组件是：someid，类型u32，ID=1名称，类型字符串变量大小，ID=2
table4: type array, ID = 6
components are:
j1, type u32, ID = 1
j2, type u32, ID = 2
j3, type u32, ID = 3
j4, type u32, ID = 4
KEY: mykey, ID = 1, V = { j1}
table4: type array, ID = 6
components are:
j1, type u32, ID = 1
j2, type u32, ID = 2
j3, type u32, ID = 3
j4, type u32, ID = 4
KEY: mykey, ID = 1, V = { j1}
table5: type array, ID = 7 components are: p1, type u32, ID = 1 p2, type array, ID = 2, array components of type-X
表5：类型数组，ID=7组件为：p1，类型u32，ID=1 p2，类型数组，ID=2，类型X的数组组件
Type-X:
x1, ID 1, type u32
x2, ID2 , type u32
KEY: tkey, ID = 1, V = { x1}
Type-X:
x1, ID 1, type u32
x2, ID2 , type u32
KEY: tkey, ID = 1, V = { x1}
All examples will use valueof(x) to indicate the value of the referenced component x. In the case where F_SEL** are missing (bits equal to 00) then the flags will not show any selection.
所有示例都将使用valueof（x）来表示参考组件x的值。如果F_SEL**缺失（位等于00），则标志将不显示任何选择。
All the examples only show use of FULLDATA-TLV for data encoding; although SPARSEDATA-TLV would make more sense in certain occasions, the emphasis is on showing the message layout. Refer to Appendix C for examples that show usage of both FULLDATA-TLV and SPARSEDATA-TLV.
所有示例仅显示FULLDATA-TLV用于数据编码；虽然A-TLV在某些场合更有意义，但重点是显示消息布局。有关FULLDATA-TLV和SPARA-TLV的使用示例，请参阅附录C。
1. To get foo1
1. 获得食物
OPER = GET-TLV
PATH-DATA-TLV: IDCount = 1, IDs = 1
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags=0, IDCount = 1, IDs = 1
FULLDATA-TLV L = 4+4, V = valueof(foo1)
OPER = GET-TLV
PATH-DATA-TLV: IDCount = 1, IDs = 1
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags=0, IDCount = 1, IDs = 1
FULLDATA-TLV L = 4+4, V = valueof(foo1)
2. To set foo2 to 10
2. 将foo2设置为10
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV: L = 4+4, V=10
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV: L = 4+4, V=10
Result: OPER = SET-RESPONSE-TLV PATH-DATA-TLV: flags = 0, IDCount = 1, IDs = 2 RESULT-TLV
结果：OPER=SET-RESPONSE-TLV PATH-DATA-TLV:flags=0，IDCount=1，IDs=2结果-TLV
3. To dump table2
3. 转储表2
OPER = GET-TLV
PATH-DATA-TLV:
IDCount = 1, IDs = 4
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV: L = XXX, V=
a series of: index, valueof(j1), valueof(j2)
representing the entire table
OPER = GET-TLV
PATH-DATA-TLV:
IDCount = 1, IDs = 4
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV: L = XXX, V=
a series of: index, valueof(j1), valueof(j2)
representing the entire table
Note: One should be able to take a GET-RESPONSE-TLV and convert it to a SET-TLV. If the result in the above example is sent back in a SET-TLV (instead of a GET-RESPONSE_TLV), then the entire contents of the table will be replaced at that point.
注意：应该能够获取GET-RESPONSE-TLV并将其转换为SET-TLV。如果上述示例中的结果以SET-TLV（而不是GET-RESPONSE_TLV）的形式发送回，则此时将替换表的全部内容。
4. Multiple operations example. To create entry 0-5 of table2 (Error conditions are ignored)
4. 多操作示例。创建表2的条目0-5（忽略错误条件）
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV valueof(j1), valueof(j2) of entry 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV valueof(j1), valueof(j2) of entry 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV valueof(j1), valueof(j2) of entry 2
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV valueof(j1), valueof(j2) of entry 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV valueof(j1), valueof(j2) of entry 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
FULLDATA-TLV valueof(j1), valueof(j2) of entry 5
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV valueof(j1), valueof(j2) of entry 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV valueof(j1), valueof(j2) of entry 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV valueof(j1), valueof(j2) of entry 2
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV valueof(j1), valueof(j2) of entry 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV valueof(j1), valueof(j2) of entry 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
FULLDATA-TLV valueof(j1), valueof(j2) of entry 5
Result:
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
RESULT-TLV
Result:
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
RESULT-TLV
5. Block operations (with holes) example. Replace entry 0,2 of table2.
5. 块操作（带孔）示例。替换表2的条目0,2。
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV containing valueof(j1), valueof(j2) of 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV containing valueof(j1), valueof(j2) of 2
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV containing valueof(j1), valueof(j2) of 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV containing valueof(j1), valueof(j2) of 2
Result:
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
Result:
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0 , IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
6. Getting rows example. Get first entry of table2.
6. 获取行示例。获取表2的第一个条目。
OPER = GET-TLV PATH-DATA-TLV: IDCount = 2, IDs = 4.0
OPER=GET-TLV PATH-DATA-TLV:IDCount=2，IDs=4.0
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
IDCount = 2, IDs = 4.0
FULLDATA-TLV containing valueof(j1), valueof(j2)
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
IDCount = 2, IDs = 4.0
FULLDATA-TLV containing valueof(j1), valueof(j2)
7. Get entry 0-5 of table2.
7. 获取表2的条目0-5。
OPER = GET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
OPER = GET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
FULLDATA-TLV containing valueof(j1), valueof(j2)
Result:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
FULLDATA-TLV containing valueof(j1), valueof(j2)
8. Create a row in table2, index 5.
8. 在表2中的索引5中创建一行。
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 2, IDs = 4.5
FULLDATA-TLV containing valueof(j1), valueof(j2)
OPER = SET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 2, IDs = 4.5
FULLDATA-TLV containing valueof(j1), valueof(j2)
Result: OPER = SET-RESPONSE-TLV PATH-DATA-TLV: flags = 0, IDCount = 1, IDs = 4.5 RESULT-TLV
结果：OPER=SET-RESPONSE-TLV PATH-DATA-TLV:flags=0，IDCount=1，IDs=4.5 Result-TLV
9. Dump contents of table1.
9. 转储表1的内容。
OPER = GET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 3
OPER = GET-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 3
Result: OPER = GET-RESPONSE-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 3 FULLDATA-TLV, Length = XXXX (depending on size of table1) index, valueof(t1),valueof(t2) index, valueof(t1),valueof(t2) . . .
结果：OPER=GET-RESPONSE-TLV PATH-DATA-TLV flags=0，IDCount=1，IDs=3 FULLDATA-TLV，Length=XXXX（取决于表1的大小）索引，valueof（t1），valueof（t2）索引，valueof（t1），valueof（t2）。
10. Using keys. Get row entry from table4 where j1=100. Recall, j1 is a defined key for this table and its KeyID is 1.
10. 使用钥匙。从表4中获取行条目，其中j1=100。回想一下，j1是此表的定义键，其键ID为1。
OPER = GET-TLV
PATH-DATA-TLV:
flags = F_SELKEY IDCount = 1, IDs = 6
KEYINFO-TLV = KeyID=1, KEY_DATA=100
OPER = GET-TLV
PATH-DATA-TLV:
flags = F_SELKEY IDCount = 1, IDs = 6
KEYINFO-TLV = KeyID=1, KEY_DATA=100
Result:
If j1=100 was at index 10
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 6.10
FULLDATA-TLV containing
valueof(j1), valueof(j2),valueof(j3),valueof(j4)
Result:
If j1=100 was at index 10
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0, IDCount = 1, IDs = 6.10
FULLDATA-TLV containing
valueof(j1), valueof(j2),valueof(j3),valueof(j4)
11. Delete row with KEY match (j1=100, j2=200) in table2. Note that the j1,j2 pair is a defined key for the table2.
11. 删除表2中键匹配的行（j1=100，j2=200）。请注意，j1、j2对是表2的定义键。
OPER = DEL-TLV
PATH-DATA-TLV:
flags = F_SELKEY IDCount = 1, IDs = 4
KEYINFO-TLV: {KeyID =1 KEY_DATA=100,200}
OPER = DEL-TLV
PATH-DATA-TLV:
flags = F_SELKEY IDCount = 1, IDs = 4
KEYINFO-TLV: {KeyID =1 KEY_DATA=100,200}
Result:
If (j1=100, j2=200) was at entry 15:
OPER = DELETE-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0 IDCount = 2, IDs = 4.15
RESULT-TLV
Result:
If (j1=100, j2=200) was at entry 15:
OPER = DELETE-RESPONSE-TLV
PATH-DATA-TLV:
flags = 0 IDCount = 2, IDs = 4.15
RESULT-TLV
12. Dump contents of table3. It should be noted that this table has a column with a component name that is variable sized. The purpose of this use case is to show how such a component is to be encoded.
12. 转储表3的内容。应该注意的是，此表中有一列的组件名称大小可变。本用例的目的是展示如何对这样的组件进行编码。
OPER = GET-TLV
PATH-DATA-TLV:
flags = 0 IDCount = 1, IDs = 5
OPER = GET-TLV
PATH-DATA-TLV:
flags = 0 IDCount = 1, IDs = 5
Result: OPER = GET-RESPONSE-TLV PATH-DATA-TLV: flags = 0 IDCount = 1, IDs = 5 FULLDATA-TLV, Length = XXXX index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), V = valueof(v) index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), V = valueof(v) index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), V = valueof(v) index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), V = valueof(v) . . .
结果：OPER=GET-RESPONSE-TLV PATH-DATA-TLV:flags=0 IDCount=1，IDs=5 FULLDATA-TLV，Length=XXXX index，someidv，TLV:T=FULLDATA-TLV，L=4+strlen（namev），V=valueof（V）index，someidv，TLV:T=FULLDATA-TLV，L=4+strlen（namev），V=valueof（V）index，someidv，TLV:T=FULLDATA-TLV，L=4+strlen（namev），V=valueof（V）。
13. Multiple atomic operations.
13. 多重原子操作。
Note 1: This emulates adding a new nexthop entry and then atomically updating the L3 entries pointing to an old NH to point to a new one. The assumption is that both tables are in the same LFB.
注1：这模拟添加一个新的nexthop条目，然后自动更新指向旧NH的L3条目以指向新条目。假设两个表位于同一LFB中。
Note: Observe the two operations on the LFB instance; both are SET operations.
注意：观察LFB实例上的两个操作；两者都是集合操作。
//Operation 1: Add a new entry to table2 index #20.
OPER = SET-TLV
Path-TLV:
flags = 0, IDCount = 2, IDs = 4.20
FULLDATA-TLV, V= valueof(j1),valueof(j2)
//Operation 1: Add a new entry to table2 index #20.
OPER = SET-TLV
Path-TLV:
flags = 0, IDCount = 2, IDs = 4.20
FULLDATA-TLV, V= valueof(j1),valueof(j2)
// Operation 2: Update table1 entry which
// was pointing with t2 = 10 to now point to 20
OPER = SET-TLV
PATH-DATA-TLV:
flags = F_SELKEY, IDCount = 1, IDs = 3
KEYINFO-TLV = KeyID=1 KEY_DATA=10
PATH-DATA-TLV
flags = 0 IDCount = 1, IDs = 2
FULLDATA-TLV, V= 20
// Operation 2: Update table1 entry which
// was pointing with t2 = 10 to now point to 20
OPER = SET-TLV
PATH-DATA-TLV:
flags = F_SELKEY, IDCount = 1, IDs = 3
KEYINFO-TLV = KeyID=1 KEY_DATA=10
PATH-DATA-TLV
flags = 0 IDCount = 1, IDs = 2
FULLDATA-TLV, V= 20
Result:
//first operation, SET
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 3, IDs = 4.20
RESULT-TLV code = success
FULLDATA-TLV, V = valueof(j1),valueof(j2)
// second operation SET - assuming entry 16 was updated
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs = 3.16
PATH-DATA-TLV
flags = 0 IDCount = 1, IDs = 2
RESULT-TLV code = success
FULLDATA-TLV, Length = XXXX v=20
Result:
//first operation, SET
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 3, IDs = 4.20
RESULT-TLV code = success
FULLDATA-TLV, V = valueof(j1),valueof(j2)
// second operation SET - assuming entry 16 was updated
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs = 3.16
PATH-DATA-TLV
flags = 0 IDCount = 1, IDs = 2
RESULT-TLV code = success
FULLDATA-TLV, Length = XXXX v=20
14. Selective setting. On table4 -- for indices 1, 3, 5, 7, and 9. Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is.
14. 选择性设置。在表4中——对于指数1、3、5、7和9。更换j1至100、j2至200、j3至300。让j4保持原样。
PER = SET-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 6
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PER = SET-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 6
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 7
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 9
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 7
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 9
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
response:
答复：
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 6
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
OPER = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 6
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 7
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 9
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 7
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 9
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
15. Manipulation of table of table examples. Get x1 from table10 row with index 4, inside table5 entry 10.
15. 操作表格的表格示例。从表10行中获取x1，索引为4，在表5条目10内。
operation = GET-TLV PATH-DATA-TLV flags = 0 IDCount = 5, IDs=7.10.2.4.1
操作=GET-TLV PATH-DATA-TLV标志=0 IDCount=5，IDs=7.10.2.4.1
Results:
operation = GET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 5, IDs=7.10.2.4.1
FULLDATA-TLV: L=XXXX, V = valueof(x1)
Results:
operation = GET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 5, IDs=7.10.2.4.1
FULLDATA-TLV: L=XXXX, V = valueof(x1)
16. From table5's row 10 table10, get X2s based on the value of x1 equaling 10 (recall x1 is KeyID 1).
16. 从表5的第10行表10中，根据x1等于10的值获取X2s（调用x1是keyid1）。
operation = GET-TLV
PATH-DATA-TLV
flag = F_SELKEY, IDCount=3, IDS = 7.10.2
KEYINFO-TLV, KeyID = 1, KEYDATA = 10
PATH-DATA-TLV
IDCount = 1, IDS = 2 //select x2
operation = GET-TLV
PATH-DATA-TLV
flag = F_SELKEY, IDCount=3, IDS = 7.10.2
KEYINFO-TLV, KeyID = 1, KEYDATA = 10
PATH-DATA-TLV
IDCount = 1, IDS = 2 //select x2
Results:
If x1=10 was at entry 11:
operation = GET-RESPONSE-TLV
PATH-DATA-TLV
flag = 0, IDCount=5, IDS = 7.10.2.11
PATH-DATA-TLV
flags = 0 IDCount = 1, IDS = 2
FULLDATA-TLV: L=XXXX, V = valueof(x2)
Results:
If x1=10 was at entry 11:
operation = GET-RESPONSE-TLV
PATH-DATA-TLV
flag = 0, IDCount=5, IDS = 7.10.2.11
PATH-DATA-TLV
flags = 0 IDCount = 1, IDS = 2
FULLDATA-TLV: L=XXXX, V = valueof(x2)
17. Further example of manipulating a table of tables
17. 操作一个表的表的进一步示例
Consider table6, which is defined as: table6: type array, ID = 8 components are: p1, type u32, ID = 1 p2, type array, ID = 2, array components of type type-A
考虑表6，它定义为：表6：类型数组，ID＝8个组件是：p1、类型u32、id＝1 p2、类型数组、id＝2、类型A的数组组件。
type-A: a1, type u32, ID 1, a2, type array ID2 ,array components of type type-B
A型：a1型、u32型、ID 1、a2型、阵列ID2型、B型阵列组件
type-B: b1, type u32, ID 1 b2, type u32, ID 2
B型：b1型，u32型，ID 1 b2型，u32型，ID 2
If for example one wanted to set by replacing: table6.10.p1 to 111 table6.10.p2.20.a1 to 222 table6.10.p2.20.a2.30.b1 to 333
例如，如果要通过替换来设置：表6.10.p1至111表6.10.p2.20.a1至222表6.10.p2.20.a2.30.b1至333
in one message and one operation.
在一个消息和一个操作中。
There are two ways to do this: a) using nesting b) using a flat path data
有两种方法可以做到这一点：a）使用嵌套b）使用平面路径数据
A. Method using nesting in one message with a single operation
A.通过一次操作在一条消息中使用嵌套的方法
operation = SET-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=6.10
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
FULLDATA-TLV: L=XXXX,
V = {111}
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=2.20
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
FULLDATA-TLV: L=XXXX,
V = {222}
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=2.30.1
FULLDATA-TLV: L=XXXX,
V = {333}
operation = SET-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=6.10
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
FULLDATA-TLV: L=XXXX,
V = {111}
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=2.20
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
FULLDATA-TLV: L=XXXX,
V = {222}
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=2.30.1
FULLDATA-TLV: L=XXXX,
V = {333}
Result:
operation = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=6.10
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
RESULT-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=2.20
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
RESULT-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=2.30.1
RESULT-TLV
Result:
operation = SET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=6.10
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
RESULT-TLV
PATH-DATA-TLV
flags = 0 IDCount = 2, IDs=2.20
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs=1
RESULT-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=2.30.1
RESULT-TLV
B. Method using a flat path data in one message with a single operation
B.通过一次操作在一条消息中使用平坦路径数据的方法
operation = SET-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=6.10.1
FULLDATA-TLV: L=XXXX,
V = {111}
PATH-DATA-TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1
FULLDATA-TLV: L=XXXX,
V = {222}
PATH-DATA-TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
FULLDATA-TLV: L=XXXX,
V = {333}
Result:
operation = SET-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=6.10.1
RESULT-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1
RESULT-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
RESULT-TLV
operation = SET-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=6.10.1
FULLDATA-TLV: L=XXXX,
V = {111}
PATH-DATA-TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1
FULLDATA-TLV: L=XXXX,
V = {222}
PATH-DATA-TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
FULLDATA-TLV: L=XXXX,
V = {333}
Result:
operation = SET-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 3, IDs=6.10.1
RESULT-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1
RESULT-TLV
PATH-DATA-TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
RESULT-TLV
18. Get a whole LFB (all its components, etc.).
18. 获取整个LFB（其所有组件等）。
For example: At startup a CE might well want the entire FE Object LFB. So, in a request targeted at class 1, instance 1, one might find:
例如：在启动时，CE可能需要整个FE对象LFB。因此，在针对类1实例1的请求中，您可能会发现：
operation = GET-TLV PATH-DATA-TLV flags = 0 IDCount = 0
操作=GET-TLV PATH-DATA-TLV标志=0 IDCount=0
result: operation = GET-RESPONSE-TLV PATH-DATA-TLV flags = 0 IDCount = 0 FULLDATA-TLV encoding of the FE Object LFB
结果：操作=GET-RESPONSE-TLV PATH-DATA-TLV flags=0 IDCount=0 FE对象LFB的FULLDATA-TLV编码
Authors' Addresses
作者地址
Avri Doria (editor) Lulea University of Technology Rainbow Way Lulea SE-971 87 Sweden
Avri Doria（编辑）Lulea技术大学彩虹路LuleA SE-97 87瑞典
Phone: +46 73 277 1788
EMail: avri@ltu.se
Phone: +46 73 277 1788
EMail: avri@ltu.se
Jamal Hadi Salim (editor) Znyx Ottawa, Ontario Canada
贾马尔·哈迪·萨利姆（编辑）加拿大安大略省渥太华Znyx
Phone: EMail: hadi@mojatatu.com
电话：电邮：hadi@mojatatu.com
Robert Haas (editor) IBM Saumerstrasse 4 8803 Ruschlikon Switzerland
罗伯特·哈斯（编辑）IBM Saumerstrasse 48803 Ruschlikon瑞士
Phone: EMail: rha@zurich.ibm.com
电话：电邮：rha@zurich.ibm.com
Hormuzd M Khosravi (editor) Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
霍姆兹德M科斯拉维（编辑）英特尔2111东北25大道希尔斯博罗，或97124美国
Phone: +1 503 264 0334
EMail: hormuzd.m.khosravi@intel.com
Phone: +1 503 264 0334
EMail: hormuzd.m.khosravi@intel.com
Weiming Wang (editor) Zhejiang Gongshang University 18, Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China
王伟明（编辑）浙江工商大学中国杭州下沙大学城学政街18号310018
Phone: +86-571-28877721
EMail: wmwang@zjgsu.edu.cn
Phone: +86-571-28877721
EMail: wmwang@zjgsu.edu.cn
Ligang Dong Zhejiang Gongshang University 18, Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China
中国杭州下沙大学城学政街18号浙江工商大学李港东310018
Phone: +86-571-28877751
EMail: donglg@zjgsu.edu.cn
Phone: +86-571-28877751
EMail: donglg@zjgsu.edu.cn
Ram Gopal Nokia 5, Wayside Road Burlington, MA 310035 USA
Ram Gopal诺基亚5，美国马萨诸塞州伯灵顿韦赛德路，邮编310035
Phone: +1-781-993-3685
EMail: ram.gopal@nsn.com
Phone: +1-781-993-3685
EMail: ram.gopal@nsn.com
Joel Halpern P.O. Box 6049 Leesburg, VA 20178 USA
美国弗吉尼亚州利斯堡市Joel Halpern邮政信箱6049号，邮编20178
Phone: +1-703-371-3043
EMail: jmh@joelhalpern.com
Phone: +1-703-371-3043
EMail: jmh@joelhalpern.com