Internet Engineering Task Force (IETF) E. Haleplidis
Request for Comments: 6369 O. Koufopavlou
Category: Informational S. Denazis
ISSN: 2070-1721 University of Patras
September 2011
Internet Engineering Task Force (IETF) E. Haleplidis
Request for Comments: 6369 O. Koufopavlou
Category: Informational S. Denazis
ISSN: 2070-1721 University of Patras
September 2011
Forwarding and Control Element Separation (ForCES) Implementation Experience
转发和控制元素分离（ForCES）实施经验
Abstract
摘要
The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE). This document captures the experience of implementing the ForCES protocol and model. Its aim is to help others by providing examples and possible strategies for implementing the ForCES protocol.
转发和控制元素分离（ForCES）协议定义了一种标准的通信和控制机制，通过该机制，控制元素（CE）可以控制转发元素（FE）的行为。本文件总结了实施部队协议和模型的经验。其目的是通过提供实施《部队议定书》的实例和可能的战略来帮助他人。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6369.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6369.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document Goal . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. ForCES Architecture . . . . . . . . . . . . . . . . . . . . . 4
3.1. Pre-Association Setup - Initial Configuration . . . . . . 5
3.2. TML . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Components . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. LFBs . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Message Deserialization . . . . . . . . . . . . . . . 13
3.4.3. Message Serialization . . . . . . . . . . . . . . . . 15
4. Development Platforms . . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document Goal . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. ForCES Architecture . . . . . . . . . . . . . . . . . . . . . 4
3.1. Pre-Association Setup - Initial Configuration . . . . . . 5
3.2. TML . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Components . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. LFBs . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Message Deserialization . . . . . . . . . . . . . . . 13
3.4.3. Message Serialization . . . . . . . . . . . . . . . . 15
4. Development Platforms . . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
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). [RFC3654] defines the ForCES requirements, and [RFC3746] defines the ForCES framework.
转发和控制元素分离（ForCES）定义了一个体系结构框架和相关协议，以标准化ForCES网元（ForCES NE）中控制平面和转发平面之间的信息交换。[RFC3654]定义了部队需求，[RFC3746]定义了部队框架。
The ForCES protocol works in a master-slave mode in which Forwarding Elements (FEs) are slaves and Control Elements (CEs) are masters. The protocol includes commands for transport of Logical Functional Block (LFB) configuration information, association setup, status, and event notifications, etc. The reader is encouraged to read the Forwarding and Control Element Separation Protocol [RFC5810] for further information.
ForCES协议在主从模式下工作，其中转发元素（FEs）是从元素，控制元素（ce）是主元素。该协议包括用于传输逻辑功能块（LFB）配置信息、关联设置、状态和事件通知等的命令。建议读者阅读转发和控制元件分离协议[RFC5810]以了解更多信息。
[RFC5812] presents a formal way to define FE LFBs using XML. LFB configuration components, capabilities, and associated events are defined when LFBs are formally created. The LFBs within the Forwarding Element (FE) are accordingly controlled in a standardized way by the ForCES protocol.
[RFC5812]提供了一种使用XML定义FE LFB的正式方法。LFB配置组件、功能和相关事件在正式创建LFB时定义。转发元件（FE）内的LFB相应地由ForCES协议以标准化方式控制。
The Transport Mapping Layer (TML) transports the protocol 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. Although more than one TML may be standardized for the ForCES protocol, all ForCES implementations must implement the Stream Control Transmission Protocol (SCTP) TML [RFC5811].
传输映射层（TML）传输协议消息。TML是处理如何实现传输级可靠性、拥塞控制、多播、排序等问题的地方。预计不止一个TML将标准化。各种可能的TML可以根据底层媒体和传输的能力而改变其实现。但是，由于每个TML都是标准化的，只要两个端点都支持相同的TML，就可以保证互操作性。所有部队协议层实现必须可移植到所有TML。尽管可以为ForCES协议标准化多个TML，但所有ForCES实施必须实现流控制传输协议（SCTP）TML[RFC5811]。
The Forwarding and Control Element Separation Applicability Statement [RFC6041] captures the applicable areas in which ForCES can be used.
转发和控制元件分离适用性声明[RFC6041]捕获了可使用力的适用区域。
This document captures the experience of implementing the ForCES protocol and model, and its main goal is to provide alternatives, ideas, and proposals as how it can be implemented, not to tell others how to implement it.
本文件收集了实施部队协议和模型的经验，其主要目标是提供替代方案、想法和建议，说明如何实施，而不是告诉其他人如何实施。
Also, this document mentions possible problems and potential choices that can be made, in an attempt to help implementors develop their own products.
此外，本文档还提到了可能存在的问题和可能做出的选择，以帮助实施者开发他们自己的产品。
Additionally, this document assumes that the reader has become familiar with the three main ForCES RFCs: the Forwarding and Control Element Separation Protocol [RFC5810], the Forwarding and Control Element Separation Forwarding Element Model [RFC5812], and the SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation Protocol [RFC5811].
此外，本文档假设读者已经熟悉三种主要力量RFC：转发和控制元素分离协议[RFC5810]、转发和控制元素分离转发元素模型[RFC5812]和基于SCTP的传输映射层（TML）用于转发和控制元素分离协议[RFC5811]。
The terminology used in this document is the same as in the Forwarding and Control Element Separation Protocol [RFC5810]; some of the definitions below are copied from that document.
本文件中使用的术语与转发和控制元件分离协议[RFC5810]中的术语相同；下面的一些定义是从该文档中复制的。
Control Element (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.
控制元素（CE）：实现ForCES协议并使用它指示一个或多个FEs如何处理数据包的逻辑实体。CEs处理控制和信令协议的执行等功能。
Forwarding Element (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.
转发元素（FE）：实现ForCES协议的逻辑实体。FEs使用底层硬件，按照一个或多个CE通过ForCES协议的指示/控制，提供每包处理和处理。
LFB (Logical Functional Block): 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.
LFB（逻辑功能块）：由ForCES协议操作的基本构建块。LFB是一个定义良好、逻辑上可分离的功能块，位于FE中，由CE通过ForCES协议控制。LFB可以驻留在FE的数据路径上并处理分组，或者可以是由CE操作的纯粹FE控制或配置实体。请注意，LFB是FE处理能力的功能精确抽象，但不是FE实现的硬件精确表示。
LFB Class and LFB Instance: 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类分类。LFB实例表示LFB类（或类型）的存在。FE中可能存在同一LFB类（或类型）的多个实例。LFB类由LFB类ID表示，LFB实例由LFB实例ID表示。因此，与LFB实例ID关联的LFB类ID唯一地指定LFB的存在。
LFB Component: 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.
LFB组件：CEs必须可见的LFB操作参数在FE模型中被概念化为LFB组件。LFB组件包括，例如，标志、单参数参数参数、复杂参数以及CE可以通过ForCES协议读取和/或写入的表。
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 [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.
部队协议：虽然在整个部队体系结构中可能使用多个协议，但术语“部队协议”和“协议”指的是部队框架中的Fp参考点[RFC3746]。本协议不适用于CE-to-CE通信、FE-to-FE通信或FE与CE经理之间的通信。基本上，ForCES协议在主-从模式下工作，其中FEs是从机，ce是主机。本文件定义了本协议的规范。
ForCES has undergone two successful interoperability tests, where very few issues were caught and resolved.
部队已经经历了两次成功的互操作性测试，很少发现和解决问题。
This section discusses the ForCES architecture, implementation challenges, and ways to overcome these challenges.
本节讨论了ForCES体系结构、实施挑战以及克服这些挑战的方法。
The initial configuration of the FE and the CE is done by the FE Manager and the CE Manager, respectively. These entities have not as yet been standardized.
FE和CE的初始配置分别由FE管理器和CE管理器完成。这些实体尚未标准化。
The simplest solution is static configuration files, which play the role of the Managers and are read by FEs and CEs.
最简单的解决方案是静态配置文件，它扮演管理器的角色，由FEs和CEs读取。
For more dynamic solutions, however, it is expected that the Managers will be entities that will talk to each other and exchange details regarding the associations. Any developer can create any Manager, but they should at least be able to exchange the details below.
然而，对于更具动态性的解决方案，预期管理者将是相互交谈并交换有关关联的详细信息的实体。任何开发人员都可以创建任何经理，但他们至少应该能够交换以下详细信息。
From the FE Manager side:
FE经理方面：
1. FE Identifiers (FEIDs).
1. FE标识符（FEID）。
2. FE IP addresses, if the FEs and CEs will be communicating via network.
2. FE IP地址，如果FEs和CEs将通过网络进行通信。
3. TML. The TML that will be used. If this is omitted, then SCTP must be chosen as default.
3. TML。将使用的TML。如果省略此项，则必须选择SCTP作为默认值。
4. TML priority ports. If this is omitted as well, then the CE must use the default values from the respective TML RFC.
4. TML优先端口。如果也省略了这一点，则CE必须使用相应TML RFC的默认值。
From the CE Manager side:
从CE经理方面：
1. CE Identifiers (CEIDs).
1. CE标识符（CEID）。
2. CE IP addresses, if the FEs and CEs will be communicating via network.
2. CE IP地址，如果FEs和CEs将通过网络进行通信。
3. TML. The TML that will be used. If this is omitted, then SCTP must be chosen as default.
3. TML。将使用的TML。如果省略此项，则必须选择SCTP作为默认值。
4. TML priority ports. If this is omitted as well, then the FE must use the default values from the respective TML RFC.
4. TML优先端口。如果也省略了这一点，则FE必须使用相应TML RFC的默认值。
All ForCES implementations must support the SCTP TML. Even if another TML will be chosen by the developer, SCTP is mandatory and must be supported.
所有部队实施必须支持SCTP TML。即使开发人员将选择另一个TML，SCTP也是强制性的，必须得到支持。
There are several issues that should concern a developer for the TML:
TML开发人员应该关注几个问题：
1. Security. TML must be secure according to the respective RFC. For SCTP, you have to use IPsec.
1. 安全TML必须根据相应的RFC进行保护。对于SCTP，您必须使用IPsec。
2. Remote connection. While ForCES is meant to be used locally, both interoperability tests have proven that ForCES can be deployed everywhere that SCTP/IP is available. In both interoperability tests, there were connections between Greece and China, and the performance was very satisfactory. However, in order for the FE and CE to work in a non-local environment, an implementor must ensure that the SCTP-TML ports are forwarded to the CE and/or FE if they are behind NATs; if there is a firewall, it will allow the SCTP ports through. These were identified during the first ForCES interoperability test and documented in the Implementation Report for Forwarding and Control Element Separation [RFC6053].
2. 远程连接。虽然部队将在本地使用，但两项互操作性测试都证明，部队可以部署在SCTP/IP可用的任何地方。在这两个互操作性测试中，希腊和中国之间都有联系，性能非常令人满意。然而，为了使FE和CE在非本地环境中工作，实施者必须确保SCTP-TML端口转发给CE和/或FE（如果它们在NAT后面）；如果有防火墙，它将允许SCTP端口通过。这些是在第一次部队互操作性测试期间确定的，并记录在转发和控制元件分离实施报告[RFC6053]中。
The ForCES model is inherently very dynamic. Using the basic atomic data types that are specified in the model, new atomic (single valued) and/or compound (structures and arrays) datatypes can be built. Thus, developers are free to create their own LFBs. One other advantage that the ForCES model provides is inheritance. New versions of existing LFBs can be created to suit any extra developer requirements.
力模型本质上是非常动态的。使用模型中指定的基本原子数据类型，可以构建新的原子（单值）和/或复合（结构和数组）数据类型。因此，开发人员可以自由创建自己的LFB。ForCES模型提供的另一个优点是继承。可以创建现有LFB的新版本，以满足任何额外的开发人员需求。
The difficulty for a developer is to create an architecture that is completely scalable so there is no need to write the same code for new LFBs, new components, etc. Developers can just create code for the defined atomic values, and new components can then be built based on already written code, thus reusing it.
开发人员的困难在于创建一个完全可伸缩的体系结构，因此无需为新LFB、新组件等编写相同的代码。开发人员只需为定义的原子值创建代码，然后可以基于已编写的代码构建新组件，从而重用它。
The model itself provides the key, which is inheritance.
模型本身提供了密钥，即继承。
First, a basic component needs to be created as the mother of all the components that has the basic parameters of all the components:
首先，需要创建一个基本组件作为具有所有组件基本参数的所有组件的母亲：
o The ID of the component.
o 组件的ID。
o The access rights of the component.
o 组件的访问权限。
o If it is an optional component.
o 如果是可选组件。
o If it is of variable size.
o 如果是可变大小的。
o Minimum data size.
o 最小数据大小。
o Maximum data size.
o 最大数据大小。
If the data size of the component is not variable, then the size is either the minimum or the maximum size, as both should have the same value.
如果组件的数据大小不是可变的，则大小为最小或最大大小，因为两者应具有相同的值。
Next, some basic functions are in order:
接下来，按顺序介绍一些基本功能：
o A common constructor.
o 公共构造函数。
o A common destructor.
o 常见的析构函数。
o Retrieve Component ID.
o 检索组件ID。
o Retrieve access right property.
o 检索访问权限属性。
o Query if it is an optional component.
o 查询它是否是可选组件。
o Get Full Data.
o 获取完整数据。
o Set Full Data.
o 设置完整数据。
o Get Sparse Data.
o 获取稀疏数据。
o Set Sparse Data.
o 设置稀疏数据。
o Del Full Data.
o 删除全部数据。
o Del Sparse Data.
o 删除稀疏数据。
o Get Property.
o 获取属性。
o Set Property.
o 设置属性。
o Get Value.
o 获取价值。
o Set Value.
o 设置值。
o Del Value.
o Del值。
o Get Data.
o 获取数据。
o Clone component.
o 克隆组件。
The Get/Set/Del Full Data, Get/Set/Del Sparse Data, and Get/Set Property functions handle the respective ForCES commands and return the respective TLV, for example, Set Full Data should return a RESULT-TLV. The Get Value, Set Value, and Del Value functions are called from Get Full/Sparse Data, Set Full/Sparse Data, and Del Full/ Sparse Data respectively and provide the interface to the actual values in the hardware, separating the forces handling logic from the interface to the actual values.
Get/Set/Del Full Data、Get/Set/Del Sparse Data和Get/Set Property函数处理相应的ForCES命令并返回相应的TLV，例如，“Set Full Data”应返回RESULT-TLV。分别从Get Full/Sparse Data、Set Full/Sparse Data和Del Full/Sparse Data调用Get Value、Set Value和Del Value函数，为硬件中的实际值提供接口，将力处理逻辑从接口分离到实际值。
The Get Data function should return the value of the data only, not in TLV format.
Get Data函数应该只返回数据的值，而不是TLV格式。
The Clone function seems out of place. This function must return a new component that has the exact same values and attributes. This function is useful in array components as described further below.
克隆功能似乎不合适。此函数必须返回具有完全相同的值和属性的新组件。如下文所述，此函数在阵列组件中非常有用。
The only requirement is to implement the base atomic data types. Any new atomic datatype can be built as a child of a base data type, which will inherit all the functions and, if necessary, override them.
唯一的要求是实现基本原子数据类型。任何新的原子数据类型都可以构建为基本数据类型的子数据类型，它将继承所有函数，并在必要时重写它们。
The struct component can then be built. A struct component is a component by itself but consists of a number of atomic components. These atomic components create a static array within the struct. The ID of each atomic component is the array's index. For a struct component, the Clone function must create and return an exact copy of the struct component with the same static array.
然后可以构建结构组件。结构组件本身就是一个组件，但由许多原子组件组成。这些原子组件在结构中创建一个静态数组。每个原子组件的ID是数组的索引。对于结构组件，克隆函数必须使用相同的静态数组创建并返回结构组件的精确副本。
The most difficult component to be built is the array. The difficulty lies in the actual benefit of the model: you have absolute freedom over what you build. An array is an array of components. In all rows, you have the exact same type of component, either a single component or a struct. The struct can have multiple single components or a combination of single components, structs, arrays, and so on. So, the difficulty lies in how to create a new row, a new component by itself. This is where the Clone function is very useful. For the array, a mother component that can spawn new components exactly like itself is needed. Once a Set command is received, the mother component can spawn a new component if the targeted row does not exist and add it into the array; with the Set Full Data function, the value is set in the recently spawned component, as the spawned component knows how the data is created. In order to distinguish these spawned components from each other and their functionality, some kind of index is required that will also reflect how the actual data of the specific component is stored on the hardware.
最难构建的组件是阵列。困难在于该模型的实际好处：您对所构建的内容拥有绝对的自由。数组是组件的数组。在所有行中，都有完全相同类型的组件，单个组件或结构。结构可以有多个单个组件或单个组件、结构、数组等的组合。所以，困难在于如何创建一个新行，一个新组件本身。这就是克隆功能非常有用的地方。对于阵列，需要一个能够生成与自身完全相同的新组件的母组件。接收到Set命令后，如果目标行不存在，则母组件可以生成一个新组件，并将其添加到数组中；使用Set Full Data函数，该值在最近生成的组件中设置，因为生成的组件知道如何创建数据。为了区分这些衍生组件及其功能，需要某种索引，该索引还将反映特定组件的实际数据如何存储在硬件上。
Once the basic constructors of all possible components are created, then a developer only has to create LFB components or datatypes as a child of one of the already-created components, and the only thing the developer really needs to add is the three functions of Get Value, Set Value, and Del Value of each component, which is platform dependent. The rest stays the same.
一旦创建了所有可能组件的基本构造函数，那么开发人员只需创建LFB组件或数据类型作为已创建组件之一的子组件，并且开发人员真正需要添加的唯一内容是每个组件的Get Value、Set Value和Del Value这三个函数，这取决于平台。其余的保持不变。
The same architecture in the components can be used for the LFBs, allowing a developer to write LFB handling code only once. The parent LFB has some basic attributes:
组件中的相同体系结构可用于LFB，允许开发人员只编写一次LFB处理代码。父LFB具有一些基本属性：
o The LFB Class ID.
o LFB类ID。
o The LFB Instance ID.
o LFB实例ID。
o An Array of Components.
o 组件的数组。
o An Array of Capabilities.
o 一系列的能力。
o An Array of Events.
o 一系列事件。
Following are some common functions:
以下是一些常见功能：
o Handle Configuration Command.
o 句柄配置命令。
o Handle Query Command.
o 句柄查询命令。
o Get Class ID.
o 获取类ID。
o Get Instance ID.
o 获取实例ID。
Once these are created, each LFB can inherit all these from the parent, and the only thing it has to do is add the components that have already been created.
创建这些组件后，每个LFB都可以从父级继承所有这些组件，它唯一要做的就是添加已经创建的组件。
An example can be seen in Figure 1. The following code creates a part of FEProtocolLFB:
图1中可以看到一个示例。以下代码创建FEProtocolLFB的一部分：
//FEID
cui = new Component_uInt(FEPO_FEID, ACCESS_READ_ONLY, FE_id);
Components[cui->get_ComponentId()]=cui; //Add component to array list
//FEID
cui = new Component_uInt(FEPO_FEID, ACCESS_READ_ONLY, FE_id);
Components[cui->get_ComponentId()]=cui; //Add component to array list
//Current FEHB Policy Value
cub = new Component_uByte(FEPO_FEHBPolicy, ACCESS_READ_WRITE, 0);
Components[cub->get_ComponentId()]=cub; //Add component to array list
//Current FEHB Policy Value
cub = new Component_uByte(FEPO_FEHBPolicy, ACCESS_READ_WRITE, 0);
Components[cub->get_ComponentId()]=cub; //Add component to array list
//FEIDs for BackupCEs Array
cui = new Component_uInt(0, ACCESS_READ_WRITE, 0);
ca = new Component_Array(FEPO_BackupCEs, ACCESS_READ_WRITE);
ca->AddRow(cui, 1);
ca->AddMotherComponent(cui);
Components[ca->get_ComponentId()]=ca; //Add component to array list
//FEIDs for BackupCEs Array
cui = new Component_uInt(0, ACCESS_READ_WRITE, 0);
ca = new Component_Array(FEPO_BackupCEs, ACCESS_READ_WRITE);
ca->AddRow(cui, 1);
ca->AddMotherComponent(cui);
Components[ca->get_ComponentId()]=ca; //Add component to array list
Figure 1: Example Code for Creating Part of FEProtocolLFB
图1：创建FEFB部分的示例代码
The same concept can be applied to handling LFBs as one FE. An FE is a collection of LFBs. Thus, all LFBs can be stored in an array based on the LFB's class id, version, and instance. Then, what is required is an LFBHandler that will handle the array of LFBs. A specific LFB, for example, can be addressed using the following scheme:
同样的概念也可以应用于处理LFB作为一个FE。FE是LFB的集合。因此，所有LFB都可以基于LFB的类id、版本和实例存储在一个数组中。然后，需要一个LFBHandler来处理LFB数组。例如，可以使用以下方案来解决特定LFB：
LFBs[ClassID][Version][InstanceID]
LFBs[ClassID][Version][InstanceID]
Note: While an array can be used in components, capabilities, and events, a hash table or a similar concept is better suited for storing LFBs using the component ID as the hash key with linked lists for collision handling, as the created array can have large gaps if the values of LFB Class ID vary greatly.
注意：虽然可以在组件、功能和事件中使用数组，但哈希表或类似概念更适合使用组件ID作为哈希键存储LFB，并使用链表进行冲突处理，因为如果LFB类ID的值变化很大，则创建的数组可能会有较大的间隙。
The goal for protocol handling is to create a general and scalable architecture that handles all protocol messages instead of something implementation specific. There are certain difficulties that have to be overcome first.
协议处理的目标是创建一个通用的、可扩展的体系结构来处理所有协议消息，而不是特定于实现的消息。有些困难必须首先克服。
Since the model allows a developer to define any LFB required, the protocol has been thus created to give the user the freedom to configure and query any component, whatever the underlying model. While this is a strong point for the protocol itself, one difficulty lies with the unknown underlying model and the unlimited number of types of messages that can be created, making creating generic code a daunting task.
由于该模型允许开发人员定义所需的任何LFB，因此创建该协议是为了让用户能够自由地配置和查询任何组件，无论底层模型是什么。虽然这是协议本身的一个优点，但一个困难在于未知的底层模型和可以创建的无限类型的消息，这使得创建通用代码成为一项艰巨的任务。
Additionally, the protocol also allows two different path approaches to LFB components, and the CE or FE must handle both or even a mix of them, making a generic decoding of the protocol message difficult.
此外，该协议还允许对LFB组件采用两种不同的路径方法，CE或FE必须同时处理这两种方法，甚至混合处理这两种方法，这使得协议消息的通用解码变得困难。
Another difficulty also arises from the batching capabilities of the protocol. You can have multiple Operations within a message; you can select more than one LFB to command and more than one component to manipulate.
协议的批处理能力也带来了另一个困难。一条消息中可以有多个操作；您可以选择多个LFB来命令和多个组件来操作。
A possible solution is again provided by inheritance. There are two basic components in a protocol message:
继承再次提供了一种可能的解决方案。协议消息中有两个基本组件：
1. The common header.
1. 公共标题。
2. The rest of the message.
2. 信息的其余部分。
The rest of the message is divided in Type-Length-Value (TLV) units and, in one case, Index-Length-Value (ILV) units.
消息的其余部分按类型长度值（TLV）单位划分，在一种情况下，按索引长度值（ILV）单位划分。
The TLV hierarchy can be seen in Figure 2:
TLV层次结构如图2所示：
Common Header
|
+---------------+---------------+---------------+
| | | |
REDIRECT-TLV LFBselect-TLV ASResult-TLV ASTreason-TLV
|
|
OPER-TLV
|
|
PATH-DATA-TLV ---> Optional KEYINFO-TLV
|
+-------------+-------------+-------------+
| | | |
SPARSEDATA-TLV RESULT-TLV FULLDATA-TLV PATH-DATA-TLV
Common Header
|
+---------------+---------------+---------------+
| | | |
REDIRECT-TLV LFBselect-TLV ASResult-TLV ASTreason-TLV
|
|
OPER-TLV
|
|
PATH-DATA-TLV ---> Optional KEYINFO-TLV
|
+-------------+-------------+-------------+
| | | |
SPARSEDATA-TLV RESULT-TLV FULLDATA-TLV PATH-DATA-TLV
Figure 2: ForCES TLV Hierarchy
图2：强制TLV层次结构
The above figure shows only the basic hierarchical level of TLVs and does not show batching. Also, this figure does not show the recursion that can occur at the last level of the hierarchy. The figure shows one kind of recursion with a PATH-DATA-TLV within a PATH-DATA-TLV. A FULLDATA-TLV can be within a FULLDATA-TLV and a SPARSEDATA-TLV. The possible combination of TLVs are described in detail in the Forwarding and Control Element Separation Protocol [RFC5810] as well as the data-packing rules.
上图仅显示TLV的基本层次结构级别，未显示批处理。此外，此图未显示在层次结构的最后一级可能发生的递归。该图显示了PATH-DATA-TLV中PATH-DATA-TLV的一种递归。FULLDATA-TLV可以在FULLDATA-TLV和SPARA-TLV中。在转发和控制元素分离协议[RFC5810]以及数据打包规则中详细描述了TLV的可能组合。
A TLV's main attributes are:
TLV的主要属性包括：
o Type.
o 类型
o Length.
o 长
o Data.
o 数据
o An array of TLVs.
o TLV阵列。
The array of TLVs is the next hierarchical level of TLVs nested in this TLV.
TLV数组是嵌套在此TLV中的下一层次TLV。
A TLV's common function could be:
TLV的常见功能可能是：
o A basic constructor.
o 一个基本的构造器。
o A constructor using data from the wire.
o 使用导线数据的构造函数。
o Add a new TLV for next level.
o 为下一级添加新的TLV。
o Get the next TLV of next level.
o 获取下一级别的下一TLV。
o Get a specific TLV of next level.
o 获取下一级别的特定TLV。
o Replace a TLV of next level.
o 更换下一级TLV。
o Get the Data.
o 获取数据。
o Get the Length.
o 获取长度。
o Set the Data.
o 设置数据。
o Set the Length.
o 设定长度。
o Set the Type.
o 设置类型。
o Serialize the header.
o 序列化标头。
o Serialize the TLV to be written on the wire.
o 序列化要在导线上写入的TLV。
All TLVs inherit these functions and attributes and either override them or create new where it is required.
所有TLV继承这些函数和属性，并在需要时覆盖它们或创建新的。
Following is an algorithm for deserializing any protocol message:
以下是反序列化任何协议消息的算法：
1. Get the message header.
1. 获取消息头。
2. Read the length.
2. 读长度。
3. Check the message type to understand what kind of message this is.
3. 检查消息类型以了解这是什么类型的消息。
4. If the length is larger than the message header, then there is data for this message.
4. 如果长度大于消息头，则存在此消息的数据。
5. A check can be made here regarding the message type and the length of the message.
5. 可以在此处检查消息类型和消息长度。
If the message is a Query or Config type, then there are LFBselect-TLVs for this level:
如果消息是查询或配置类型，则此级别有LFBselect TLV：
1. Read the next 2 shorts(type-length). If the type is an LFBselect-TLV, then the message is valid.
1. 阅读下面两条短裤（输入长度）。如果类型为LFBselect TLV，则消息有效。
2. Read the necessary length for this LFBselect-TLV, and create the LFBselect-TLV from the data of the wire.
2. 读取此LFBselect TLV的必要长度，并根据导线数据创建LFBselect TLV。
3. Add this LFBselect-TLV to the main header array of LFBselect-TLVs.
3. 将此LFBselect TLV添加到LFBselect TLV的主标头数组中。
4. Repeat all above steps until the rest of the message has finished.
4. 重复以上所有步骤，直到消息的其余部分完成。
The next level of TLVs is OPER-TLVs.
TLV的下一个级别是操作TLV。
1. Read the next 2 shorts(type-length). If the type is an OPER-TLV, then the message is valid.
1. 阅读下面两条短裤（输入长度）。如果类型为OPER-TLV，则消息有效。
2. Read the necessary length for this OPER-TLV, and create the OPER-TLV from the data of the wire.
2. 读取此OPER-TLV的必要长度，并根据导线数据创建OPER-TLV。
3. Add this OPER-TLV to the LFBselect-TLV array of TLVs.
3. 将此OPER-TLV添加到TLV的LFBselect TLV数组中。
4. Do this until the rest of the LFBselect-TLV has finished.
4. 执行此操作，直到LFBselect TLV的其余部分完成。
The next level of TLVs is PATH-DATA-TLVs.
TLV的下一个级别是路径数据TLV。
1. Read the next 2 shorts(type-length). If the type is a PATH-DATA-TLV, then the message is valid.
1. 阅读下面两条短裤（输入长度）。如果类型为PATH-DATA-TLV，则消息有效。
2. Read the necessary length for this PATH-DATA-TLV, and create the PATH-DATA-TLV from the data of the wire.
2. 读取此PATH-DATA-TLV的必要长度，并根据导线的数据创建PATH-DATA-TLV。
3. Add this PATH-DATA-TLV to the OPER-TLV's array of TLVs.
3. 将此PATH-DATA-TLV添加到OPER-TLV的TLV数组中。
4. Do this until the rest of the OPER-TLV is finished.
4. 执行此操作，直到操作TLV的其余部分完成。
Here it gets interesting, as the next level of PATH-DATA-TLVs can be one of the following:
这里很有趣，因为下一级路径数据TLV可以是以下之一：
o PATH-DATA-TLVs.
o 路径数据TLV。
o FULLDATA-TLV.
o FULLDATA-TLV。
o SPARSEDATA-TLV.
o SPARA-TLV。
o RESULT-TLV.
o 结果-TLV。
The solution to this difficulty is recursion. If the next TLV is a PATH-DATA-TLV, then the PATH-DATA-TLV that is created uses the same kind of deserialization until it reaches a FULLDATA-TLV or SPARSEDATA-TLV. There can be only one FULLDATA-TLV or SPARSEDATA-TLV within a PATH-DATA-TLV.
解决这个困难的办法是递归。如果下一个TLV是PATH-DATA-TLV，则创建的PATH-DATA-TLV将使用相同类型的反序列化，直到到达FULLDATA-TLV或SPARA-TLV。PATH-DATA-TLV中只能有一个FULLDATA-TLV或SPARA-TLV。
1. Read the next 2 shorts(type-length).
1. 阅读下面两条短裤（输入长度）。
2. If the Type is a PATH-DATA-TLV, then repeat the previous algorithm but add the PATH-DATA-TLV to this PATH-DATA-TLV's array of TLVs.
2. 如果类型是PATH-DATA-TLV，则重复前面的算法，但将PATH-DATA-TLV添加到此PATH-DATA-TLV的TLV数组中。
3. Do this until the rest of the PATH-DATA-TLV is finished.
3. 执行此操作，直到PATH-DATA-TLV的其余部分完成。
4. If the Type is a FULLDATA-TLV, then create the FULLDATA-TLV from the message and add this to the PATH-DATA-TLV's array of TLVs.
4. 如果类型为FULLDATA-TLV，则从消息中创建FULLDATA-TLV，并将其添加到PATH-DATA-TLV的TLV数组中。
5. If the Type is a SPARSEDATA-TLV, then create the SPARSEDATA-TLV from the message and add this to the PATH-DATA-TLV's array of TLVs.
5. 如果类型是SPARSTATA-TLV，则从消息中创建SPARSTATA-TLV，并将其添加到PATH-DATA-TLV的TLV数组中。
6. If the Type is a RESULT-TLV, then create the RESULT-TLV from the message and add this to the PATH-DATA-TLV's array of TLVs.
6. 如果类型是RESULT-TLV，则从消息中创建RESULT-TLV，并将其添加到PATH-DATA-TLV的TLV数组中。
If the message is a Query, it must not have any kind of data inside the PATH-DATA-TLV.
如果消息是查询，则在PATH-data-TLV中不得包含任何类型的数据。
If the message is a Query Response, then it must have either a RESULT-TLV or a FULLDATA-TLV.
如果消息是查询响应，那么它必须具有RESULT-TLV或FULLDATA-TLV。
If the message is a Config, it must contain either a FULLDATA-TLV or a SPARSEDATA-TLV.
如果消息是配置，则必须包含FULLDATA-TLV或SPARA-TLV。
If the message is a Config Response, it must contain a RESULT-TLV.
如果消息是配置响应，则必须包含RESULT-TLV。
More details regarding message validation can be read in Section 7 of the Forwarding and Control Element Separation Protocol [RFC5810].
有关消息验证的更多详细信息，请参阅转发和控制元件分离协议[RFC5810]第7节。
Note: When deserializing, implementors must take care to ignore padding of TLVs as all must be 32-bit aligned. The length value in TLVs includes the Type and Length (4 bytes) but does not include padding.
注意：当反序列化时，实现者必须注意忽略TLV的填充，因为所有TLV都必须是32位对齐的。TLV中的长度值包括类型和长度（4字节），但不包括填充。
The same concept can be applied in the message creation process. Having the TLVs ready, a developer can go bottom up. All that is required is the serialization function that will transform the TLV into bytes ready to be transferred on the network.
在消息创建过程中也可以应用相同的概念。准备好TLV后，开发人员可以自下而上。所需的只是将TLV转换为准备在网络上传输的字节的序列化函数。
For example, for the creation of a simple query from the CE to the FE, all the PATH-DATA-TLVs are created. Then they will be serialized and inserted into an OPER-TLV, which in turn will be serialized and inserted into an LFBselect-TLV. The LFBselect-TLV will then be serialized and entered into the Common Header, which will be passed to the TML to be transported to the FE.
例如，为了创建从CE到FE的简单查询，将创建所有路径数据TLV。然后，它们将被序列化并插入OPER-TLV，OPER-TLV将被序列化并插入LFBselect TLV。然后，LFBselect TLV将被序列化并输入到公共标头中，该标头将被传递到TML以传输到FE。
Having an array of TLVs inside a TLV that is next in the TLV hierarchy allows the developer to insert any number of next-level TLVs, thus creating any kind of message.
在TLV层次结构中的下一个TLV中拥有TLV数组允许开发人员插入任意数量的下一级TLV，从而创建任何类型的消息。
Note: When the TLV is serialized to be written on the wire, implementors must take care to include padding to TLVs as all must be 32-bit aligned.
注意：当TLV被序列化以写在线路上时，实现者必须注意将填充包含到TLV中，因为所有填充都必须是32位对齐的。
Any development platform that can support the SCTP TML and the TML of the developer's choosing is available for use.
任何能够支持SCTP TML和开发人员选择的TML的开发平台都可以使用。
Figure 3 provides an initial survey of SCTP support for C/C++ and Java at the present time.
图3提供了目前对C/C++和Java的SCTP支持的初步调查。
/-------------+-------------+-------------+-------------\
|\ Platform | | | |
| ----------\ | Windows | Linux | Solaris |
| Language \| | | |
+-------------+-------------+-------------+-------------+
| | | | |
| C/C++ | Supported | Supported | Supported |
| | | | |
+-------------+-------------+-------------+-------------+
| | Limited | | |
| Java | Third Party | Supported | Supported |
| | Not from SUN| | |
\-------------+-------------+-------------+-------------/
/-------------+-------------+-------------+-------------\
|\ Platform | | | |
| ----------\ | Windows | Linux | Solaris |
| Language \| | | |
+-------------+-------------+-------------+-------------+
| | | | |
| C/C++ | Supported | Supported | Supported |
| | | | |
+-------------+-------------+-------------+-------------+
| | Limited | | |
| Java | Third Party | Supported | Supported |
| | Not from SUN| | |
\-------------+-------------+-------------+-------------/
Figure 3: SCTP Support on Operating Systems
图3：操作系统上的SCTP支持
A developer should be aware of some limitations regarding Java implementations.
开发人员应该了解有关Java实现的一些限制。
Java inherently does not support unsigned types. A workaround can be found in the creation of classes that do the translation of unsigned types to Java types. The problem is that the unsigned long cannot be used as-is in the Java platform. The proposed set of classes can be found in [JavaUnsignedTypes].
Java本身不支持无符号类型。在创建将无符号类型转换为Java类型的类时，可以找到一种解决方法。问题是，无符号long不能像在Java平台中那样使用。建议的类集可以在[JavaUnsignedTypes]中找到。
The authors would like to thank Adrian Farrel for sponsoring this document and Jamal Hadi Salim for discussions that made this document better.
作者要感谢阿德里安·法雷尔（Adrian Farrel）赞助本文件，并感谢贾马尔·哈迪·萨利姆（Jamal Hadi Salim）通过讨论使本文件变得更好。
Developers of ForCES FEs and CEs must take the Security Considerations of the Forwarding and Control Element Separation Framework [RFC3746] and the Forwarding and Control Element Separation Protocol [RFC5810] into account.
部队FEs和CEs的开发者必须考虑转发和控制元素分离框架[RFC3746]以及转发和控制元素分离协议[RFC5810]的安全考虑。
Also, as specified in the Security Considerations section of the SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation Protocol [RFC5811], transport-level security has to be ensured by IPsec.
此外，根据转发和控制元素分离协议[RFC5811]基于SCTP的传输映射层（TML）的安全注意事项部分的规定，必须通过IPsec确保传输级别的安全性。
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010.
[RFC5810]Doria，A.，Hadi Salim，J.，Haas，R.，Khosravi，H.，Wang，W.，Dong，L.，Gopal，R.，和J.Halpern，“转发和控制元件分离（部队）协议规范”，RFC 58102010年3月。
[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月。
[RFC6041] Crouch, A., Khosravi, H., Doria, A., Wang, X., and K. Ogawa, "Forwarding and Control Element Separation (ForCES) Applicability Statement", RFC 6041, October 2010.
[RFC6041]Crouch，A.，Khosravi，H.，Doria，A.，Wang，X.，和K.Ogawa，“转发和控制元件分离（部队）适用性声明”，RFC 60412010年10月。
[RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim, "Implementation Report for Forwarding and Control Element Separation (ForCES)", RFC 6053, November 2010.
[RFC6053]Haleplidis，E.，Ogawa，K.，Wang，W.，和J.Hadi Salim，“转发和控制分队（部队）实施报告”，RFC 60532010年11月。
[JavaUnsignedTypes] "Java Unsigned Types", <http://nam.ece.upatras.gr/index.php?q=node/44>.
[JavaUnsignedTypes]“Java未签名类型”<http://nam.ece.upatras.gr/index.php?q=node/44>.
[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月。
Authors' Addresses
作者地址
Evangelos Haleplidis University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece
佩特雷大学电气与计算机工程系帕特雷26500希腊分校
EMail: ehalep@ece.upatras.gr
EMail: ehalep@ece.upatras.gr
Odysseas Koufopavlou University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece
OdssSoukoufopav娄佩特雷大学电气与计算机工程系帕特雷26500希腊
EMail: odysseas@ece.upatras.gr
EMail: odysseas@ece.upatras.gr
Spyros Denazis University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece
佩特雷大学电气与计算机工程系帕特雷26500希腊分校
EMail: sdena@upatras.gr
EMail: sdena@upatras.gr