Internet Engineering Task Force (IETF) J. Hadi Salim
Request for Comments: 5811 Mojatatu Networks
Category: Standards Track K. Ogawa
ISSN: 2070-1721 NTT Corporation
March 2010
Internet Engineering Task Force (IETF) J. Hadi Salim
Request for Comments: 5811 Mojatatu Networks
Category: Standards Track K. Ogawa
ISSN: 2070-1721 NTT Corporation
March 2010
SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol
用于转发和控制元素分离（ForCES）协议的基于SCTP的传输映射层（TML）
Abstract
摘要
This document defines the SCTP-based TML (Transport Mapping Layer) for the ForCES (Forwarding and Control Element Separation) protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol.
本文件为ForCES（转发和控制元素分离）协议定义了基于SCTP的TML（传输映射层）。它解释了选择SCTP（流控制传输协议）的基本原理，并描述了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/rfc5811.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5811.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Definitions .....................................................3
3. Protocol Framework Overview .....................................4
3.1. The PL .....................................................5
3.2. The TML ....................................................5
3.2.1. TML and PL Interfaces ...............................5
3.2.2. TML Parameterization ................................6
4. SCTP TML Overview ...............................................7
4.1. Rationale for Using SCTP for TML ...........................7
4.2. Meeting TML Requirements ...................................8
4.2.1. SCTP TML Channels ...................................9
4.2.2. Satisfying TML Requirements ........................14
5. SCTP TML Channel Work ..........................................16
6. IANA Considerations ............................................16
7. Security Considerations ........................................17
7.1. IPsec Usage ...............................................17
7.1.1. SAD and SPD Setup ..................................18
8. Acknowledgements ...............................................18
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Appendix A. Suggested SCTP TML Channel Work Implementation .......21
A.1. SCTP TML Channel Initialization ...........................21
A.2. Channel Work Scheduling ...................................21
A.2.1. FE Channel Work Scheduling ............................21
A.2.2. CE Channel Work Scheduling ............................22
A.3. SCTP TML Channel Termination ..............................23
A.4. SCTP TML NE-Level Channel Scheduling ......................23
Appendix B. Suggested Service Interface ..........................24
B.1. TML Bootstrapping .........................................24
B.2. TML Shutdown ..............................................26
B.3. TML Sending and Receiving .................................27
1. Introduction ....................................................3
2. Definitions .....................................................3
3. Protocol Framework Overview .....................................4
3.1. The PL .....................................................5
3.2. The TML ....................................................5
3.2.1. TML and PL Interfaces ...............................5
3.2.2. TML Parameterization ................................6
4. SCTP TML Overview ...............................................7
4.1. Rationale for Using SCTP for TML ...........................7
4.2. Meeting TML Requirements ...................................8
4.2.1. SCTP TML Channels ...................................9
4.2.2. Satisfying TML Requirements ........................14
5. SCTP TML Channel Work ..........................................16
6. IANA Considerations ............................................16
7. Security Considerations ........................................17
7.1. IPsec Usage ...............................................17
7.1.1. SAD and SPD Setup ..................................18
8. Acknowledgements ...............................................18
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Appendix A. Suggested SCTP TML Channel Work Implementation .......21
A.1. SCTP TML Channel Initialization ...........................21
A.2. Channel Work Scheduling ...................................21
A.2.1. FE Channel Work Scheduling ............................21
A.2.2. CE Channel Work Scheduling ............................22
A.3. SCTP TML Channel Termination ..............................23
A.4. SCTP TML NE-Level Channel Scheduling ......................23
Appendix B. Suggested Service Interface ..........................24
B.1. TML Bootstrapping .........................................24
B.2. TML Shutdown ..............................................26
B.3. TML Sending and Receiving .................................27
The ForCES (Forwarding and Control Element Separation) working group in the IETF defines the architecture and protocol for separation of control elements (CEs) and forwarding elements (FEs) in network elements (NEs) such as routers. [RFC3654] and [RFC3746], respectively, define architectural and protocol requirements for the communication between CEs and FEs. The ForCES protocol layer specification [RFC5810] describes the protocol semantics and workings. The ForCES protocol layer operates on top of an inter-connect hiding layer known as the TML. The relationship is illustrated in Figure 1.
IETF中的ForCES（转发和控制元素分离）工作组定义了用于分离路由器等网元（NE）中的控制元素（CE）和转发元素（FEs）的体系结构和协议。[RFC3654]和[RFC3746]分别定义了CEs和FEs之间通信的体系结构和协议要求。ForCES协议层规范[RFC5810]描述了协议语义和工作方式。ForCES协议层在称为TML的连接间隐藏层之上运行。关系如图1所示。
This document defines the SCTP-based TML for the ForCES protocol layer. It also addresses all the requirements for the TML including security, reliability, and etc., as defined in [RFC5810].
本文件为ForCES协议层定义了基于SCTP的TML。它还解决了TML的所有要求，包括[RFC5810]中定义的安全性、可靠性等。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following definitions are taken from [RFC3654] and [RFC3746]:
以下定义取自[RFC3654]和[RFC3746]：
LFB: Logical Functional Block. A template that represents a fine-grained, logically separate aspect of FE processing.
逻辑功能块。表示FE处理的细粒度、逻辑独立方面的模板。
ForCES Protocol: The protocol used at the Fp reference point in the ForCES Framework in [RFC3746].
ForCES协议：在[RFC3746]中ForCES框架的Fp参考点处使用的协议。
ForCES PL: ForCES Protocol Layer. A layer in the ForCES architecture that embodies the ForCES protocol and the state transfer mechanisms as defined in [RFC5810].
forcespl:ForCES协议层。ForCES体系结构中的一层，包含[RFC5810]中定义的ForCES协议和状态传输机制。
ForCES TML: ForCES Protocol Transport Mapping Layer. A layer in the ForCES protocol architecture that specifically addresses the protocol message transportation issues, such as how the protocol messages are mapped to different transport media (like SCTP, IP, TCP, UDP, ATM, Ethernet, etc.), and how to achieve and implement reliability, security, etc.
forcestml：ForCES协议传输映射层。ForCES协议体系结构中的一层，专门解决协议消息传输问题，如协议消息如何映射到不同的传输介质（如SCTP、IP、TCP、UDP、ATM、以太网等），以及如何实现和实现可靠性、安全性等。
The reader is referred to the Framework document [RFC3746], and in particular Sections 3 and 4, for an architectural overview and explanation of where and how the ForCES protocol fits in.
读者可参考框架文件[RFC3746]，特别是第3节和第4节，以了解体系结构概述以及ForCES协议适用的位置和方式。
There is some content overlap between the ForCES protocol specification [RFC5810] and this section (Section 3) in order to provide basic context to the reader of this document.
ForCES协议规范[RFC5810]与本节（第3节）之间存在一些内容重叠，以便为本文件的读者提供基本上下文。
The ForCES protocol layering constitutes two pieces, the PL and TML. This is depicted in Figure 1.
ForCES协议分层由两部分组成，PL和TML。这如图1所示。
+----------------------------------------------+
| CE PL |
+----------------------------------------------+
| CE TML |
+----------------------------------------------+
^
|
ForCES PL |messages
|
v
+-----------------------------------------------+
| FE TML |
+-----------------------------------------------+
| FE PL |
+-----------------------------------------------+
+----------------------------------------------+
| CE PL |
+----------------------------------------------+
| CE TML |
+----------------------------------------------+
^
|
ForCES PL |messages
|
v
+-----------------------------------------------+
| FE TML |
+-----------------------------------------------+
| FE PL |
+-----------------------------------------------+
Figure 1: Message Exchange between CE and FE to Establish an NE Association
图1：CE和FE之间的消息交换以建立NE关联
The PL is in charge of the ForCES protocol. Its semantics and message layout are defined in [RFC5810]. The TML is necessary to connect two ForCES endpoints as shown in Figure 1.
PL负责部队协议。其语义和消息布局在[RFC5810]中定义。TML是连接两个力端点所必需的，如图1所示。
Both the PL and TML are standardized by the IETF. While only one PL is defined, different TMLs are expected to be standardized. The TML at each of the nodes (CE and FE) is expected to be of the same definition in order to inter-operate.
PL和TML均由IETF标准化。虽然只定义了一个PL，但不同的TML有望标准化。每个节点（CE和FE）处的TML应具有相同的定义，以便相互操作。
When transmitting from a ForCES endpoint, the PL delivers its messages to the TML. The TML then delivers the PL message to the destination TML(s).
当从ForCES端点进行传输时，PL将其消息传递给TML。然后，TML将PL消息传递到目标TML。
On reception of a message, the TML delivers the message to its destination PL (as described in the ForCES header).
在接收到消息时，TML将消息发送到其目的地PL（如ForCES报头中所述）。
The PL is common to all implementations of ForCES and is standardized by the IETF [RFC5810]. The PL is responsible for associating an FE or CE to an NE. It is also responsible for tearing down such associations.
PL对于所有部队实施都是通用的，并由IETF[RFC5810]标准化。PL负责将FE或CE与NE关联。它还负责摧毁这些协会。
An FE may use the PL to asynchronously send packets to the CE. The FE may redirect various control protocol packets (e.g., OSPF, etc.) to the CE via the PL (from outside the NE). Additionally, the FE delivers various events that the CE has subscribed to via the PL [RFC5812].
FE可以使用PL向CE异步发送数据包。FE可经由PL（从网元外部）将各种控制协议分组（例如，OSPF等）重定向到CE。此外，FE通过PL[RFC5812]交付CE订阅的各种事件。
The CE and FE may interact synchronously via the PL. The CE issues status requests to the FE and receives responses via the PL. The CE also configures the components of the associated FE's LFBs using the PL [RFC5812].
CE和FE可通过PL同步交互。CE向FE发出状态请求并通过PL接收响应。CE还使用PL配置相关FE LFB的组件[RFC5812]。
The TML is responsible for the transport of the PL messages. [RFC5810], Section 5 defines the requirements that need to be met by a TML specification. The SCTP TML specified in this document meets all the requirements specified in [RFC5810], Section 5. Section 4.2.2 of this document describes how the TML requirements are met.
TML负责PL消息的传输。[RFC5810]，第5节定义了TML规范需要满足的要求。本文件中规定的SCTP TML符合[RFC5810]第5节中规定的所有要求。本文件第4.2.2节描述了如何满足TML要求。
There are two interfaces to the PL and TML. The specification of these interfaces is out of scope for this document, but the interfaces are introduced to show how they fit into the architecture and summarize the function provided at the interfaces. The first interface is between the PL and TML and the other is the CE Manager (CEM)/FE Manager (FEM) [RFC3746] interface to both the PL and TML. Both interfaces are shown in Figure 2.
PL和TML有两个接口。这些接口的规范不在本文档的范围内，但介绍这些接口是为了说明它们如何适合体系结构，并总结接口提供的功能。第一个接口位于PL和TML之间，另一个接口是PL和TML的CE管理器（CEM）/FE管理器（FEM）[RFC3746]接口。两个接口如图2所示。
+----------------------------+
| +----------------------+ |
| | | |
+---------+ | | PL | |
| | | +----------------------+ |
|FEM/CEM |<---->| ^ |
| | | | |
+---------+ | |TML API |
| | |
| V |
| +----------------------+ |
| | | |
| | TML | |
| | | |
| +----------------------+ |
+----------------------------+
+----------------------------+
| +----------------------+ |
| | | |
+---------+ | | PL | |
| | | +----------------------+ |
|FEM/CEM |<---->| ^ |
| | | | |
+---------+ | |TML API |
| | |
| V |
| +----------------------+ |
| | | |
| | TML | |
| | | |
| +----------------------+ |
+----------------------------+
Figure 2: The TML-PL Interface
图2:TML-PL接口
The CEM/FEM [RFC3746] interface is responsible for bootstrapping and parameterization of the TML. In its most basic form, the CEM/FEM interface takes the form of a simple static config file that is read on startup in the pre-association phase.
CEM/FEM[RFC3746]接口负责TML的引导和参数化。CEM/FEM接口最基本的形式是一个简单的静态配置文件，在预关联阶段启动时读取。
Appendix B discusses the service interfaces in more detail.
附录B更详细地讨论了服务接口。
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/SCTP, then parameters such as SCTP ports and IP addresses need to be configured.
o 连接类型和关联数据。例如，如果TML使用IP/SCTP，则需要配置SCTP端口和IP地址等参数。
o Number of transport connections
o 传输连接数
o Connection Capability, such as bandwidth, etc.
o 连接能力，如带宽等。
o Allowed/Supported Connection Quality of Service (QoS) Policy (or Congestion Control Policy)
o 允许/支持的连接服务质量（QoS）策略（或拥塞控制策略）
SCTP [RFC4960] is an end-to-end transport protocol that is equivalent to TCP, UDP, or DCCP in many aspects. With a few exceptions, SCTP can do most of what UDP, TCP, or DCCP can achieve. SCTP as can also do most of what a combination of the other transport protocols can achieve (e.g., TCP and DCCP or TCP and UDP).
SCTP[RFC4960]是一种端到端传输协议，在许多方面等同于TCP、UDP或DCCP。除了少数例外，SCTP可以完成UDP、TCP或DCCP可以实现的大部分功能。SCTP as还可以完成其他传输协议组合可以实现的大部分功能（例如，TCP和DCCP或TCP和UDP）。
Like TCP, it provides ordered, reliable, connection-oriented, flow-controlled, congestion-controlled data exchange. Unlike TCP, it does not provide byte streaming and instead provides message boundaries.
与TCP一样，它提供有序、可靠、面向连接、流量控制、拥塞控制的数据交换。与TCP不同，它不提供字节流，而是提供消息边界。
Like UDP, it can provide unreliable, unordered data exchange. Unlike UDP, it does not provide multicast support
与UDP一样，它可以提供不可靠、无序的数据交换。与UDP不同，它不提供多播支持
Like DCCP, it can provide unreliable, ordered, congestion controlled, connection-oriented data exchange.
与DCCP一样，它可以提供不可靠、有序、拥塞控制、面向连接的数据交换。
SCTP also provides other services that none of the three transport protocols mentioned above provide that we found attractive. These include:
SCTP还提供了上述三种传输协议都没有提供的其他服务，我们认为这些服务很有吸引力。这些措施包括：
o Multi-homing
o 多宿
o Runtime IP address binding
o 运行时IP地址绑定
o A range of reliability shades with congestion control
o 具有拥塞控制的一系列可靠性阴影
o Built-in heartbeats
o 内置心跳
o Multi-streaming
o 多流
o Message boundaries with reliability
o 具有可靠性的消息边界
o Improved SYN DOS protection
o 改进的syndos保护
o Simpler transport events
o 更简单的传输事件
o Simplified replicasting
o 简化复制
SCTP has all the features required to provide a robust TML. As a transport that is all-encompassing, it negates the need for having multiple transport protocols in order to satisfy the TML requirements ([RFC5810], Section 5). As a result, it allows for simpler coding and therefore reduces a lot of the interoperability concerns.
SCTP具有提供健壮TML所需的所有功能。作为一种包罗万象的传输，它不需要有多个传输协议来满足TML要求（[RFC5810]，第5节）。所以，它允许更简单的编码，从而减少了许多互操作性问题。
SCTP is also very mature and widely used, making it a good choice for ubiquitous deployment.
SCTP也非常成熟并得到了广泛的应用，这使得它成为无处不在的部署的良好选择。
PL
+----------------------+
| |
+-----------+----------+
| TML API
TML |
+-----------+----------+
| | |
| +------+------+ |
| | TML core | |
| +-+----+----+-+ |
| | | | |
| SCTP socket API |
| | | | |
| | | | |
| +-+----+----+-+ |
| | SCTP | |
| +------+------+ |
| | |
| | |
| +------+------+ |
| | IP | |
| +-------------+ |
+----------------------+
PL
+----------------------+
| |
+-----------+----------+
| TML API
TML |
+-----------+----------+
| | |
| +------+------+ |
| | TML core | |
| +-+----+----+-+ |
| | | | |
| SCTP socket API |
| | | | |
| | | | |
| +-+----+----+-+ |
| | SCTP | |
| +------+------+ |
| | |
| | |
| +------+------+ |
| | IP | |
| +-------------+ |
+----------------------+
Figure 3: The TML-SCTP Interface
图3:TML-SCTP接口
Figure 3 details the interfacing between the PL and SCTP TML and the internals of the SCTP TML. The core of the TML interacts on its northbound interface to the PL (utilizing the TML API). On the southbound interface, the TML core interfaces to the SCTP layer utilizing the standard socket interface [TSVWG-SCTPSOCKET]. There are three SCTP socket connections opened between any two PL endpoints (whether FE or CE).
图3详细说明了PL和SCTP TML之间的接口以及SCTP TML的内部构件。TML的核心在其北向接口上与PL交互（利用TMLAPI）。在南向接口上，TML核心使用标准套接字接口[TSVWG-SCTPSOCKET]与SCTP层进行接口。在任意两个PL端点（FE或CE）之间打开了三个SCTP套接字连接。
+--------------------+
| |
| TML core |
| |
+-+-------+--------+-+
| | |
| Med prio, |
| Semi-reliable |
| channel |
| | Low prio,
| | Unreliable
| | channel
| | |
^ ^ ^
| | |
Y Y Y
High prio,| | |
reliable | | |
channel | | |
Y Y Y
+-+--------+--------+-+
| |
| SCTP |
| |
+---------------------+
+--------------------+
| |
| TML core |
| |
+-+-------+--------+-+
| | |
| Med prio, |
| Semi-reliable |
| channel |
| | Low prio,
| | Unreliable
| | channel
| | |
^ ^ ^
| | |
Y Y Y
High prio,| | |
reliable | | |
channel | | |
Y Y Y
+-+--------+--------+-+
| |
| SCTP |
| |
+---------------------+
Figure 4: The TML-SCTP Channels
图4:TML-SCTP信道
Figure 4 details further the interfacing between the TML core and SCTP layers. There are three channels used to group and prioritize the work for different types of ForCES traffic. Each channel constitutes an SCTP socket interface that has different properties. It should be noted that all SCTP channels are congestion aware (and for that reason that detail is left out of the description of the three channels). SCTP ports 6704, 6705, and 6706 are used for the higher-, medium-, and lower-priority channels, respectively. SCTP Payload Protocol ID (PPID) values of 21, 22, and 23 are used for the higher-, medium-, and lower-priority channels, respectively.
图4进一步详细说明了TML核心层和SCTP层之间的接口。有三种渠道用于对不同类型的部队交通进行分组和优先排序。每个通道构成一个具有不同属性的SCTP套接字接口。应该注意的是，所有SCTP信道都是拥塞感知的（因此，在三个信道的描述中省略了该细节）。SCTP端口6704、6705和6706分别用于高、中、低优先级信道。SCTP有效负载协议ID（PPID）值21、22和23分别用于高、中和低优先级信道。
SCTP allows up to 64 K streams to be sent over a single socket interface. The authors initially envisioned using a single socket for all three channels (mapping a channel to an SCTP stream). This simplifies programming of the TML as well as conserves use of SCTP ports.
SCTP允许通过单个套接字接口发送多达64K的流。作者最初设想为所有三个通道使用一个套接字（将通道映射到SCTP流）。这简化了TML的编程，并节省了SCTP端口的使用。
Further analysis revealed head-of-line blocking issues with this initial approach. Lower-priority packets not needing reliable delivery could block higher-priority packets (needing reliable delivery) under congestion situations for an indeterminate period of time (depending on how many outstanding lower-priority packets are pending). For this reason, we elected to go with mapping each of the three channels to a different SCTP socket (instead of a different stream within a single socket).
进一步的分析揭示了这种初始方法的线路阻塞问题。不需要可靠传递的低优先级数据包可能会在拥塞情况下在不确定的时间段（取决于有多少未完成的低优先级数据包待定）阻止高优先级数据包（需要可靠传递）。因此，我们选择将三个通道中的每一个映射到不同的SCTP套接字（而不是单个套接字中的不同流）。
The higher-priority (HP) channel uses a standard SCTP reliable socket on port 6704. SCTP PPID 21 is used for all messages on the HP channel. The HP channel is used for CE-solicited messages and their responses:
高优先级（HP）通道在端口6704上使用标准SCTP可靠插槽。SCTP PPID 21用于HP频道上的所有消息。HP频道用于CE请求的消息及其响应：
1. ForCES configuration messages flowing from CE to FE and responses from the FE to CE.
1. 强制配置消息从CE流向FE，并从FE向CE发送响应。
2. ForCES query messages flowing from CE to FE and responses from the FE to the CE.
2. 强制查询消息从CE流到FE，并将响应从FE流到CE。
PL priorities 4-7 MUST be used for all PL messages using this channel. The following PL messages MUST use the HP channel for transport:
PL优先级4-7必须用于使用此通道的所有PL消息。以下PL消息必须使用HP通道进行传输：
o AssociationSetup (default priority: 7)
o 关联设置（默认优先级：7）
o AssociationSetupResponse (default priority: 7)
o AssociationSetupResponse（默认优先级：7）
o AssociationTeardown (default priority: 7)
o AssociationDeardown（默认优先级：7）
o Config (default priority: 4)
o 配置（默认优先级：4）
o ConfigResponse (default priority: 4)
o ConfigResponse（默认优先级：4）
o Query (default priority: 4)
o 查询（默认优先级：4）
o QueryResponse (default priority: 4)
o QueryResponse（默认优先级：4）
If PL priorities outside of the specified range priority (4-7), PPID, or PL message types other than the above are received on the HP channel, then the PL message MUST be dropped.
如果在HP通道上接收到指定范围优先级（4-7）、PPID或PL消息类型以外的PL优先级，则必须删除PL消息。
Although an implementation may choose different values from the defined range (4-7), it is RECOMMENDED that default priorities be used. A response to a ForCES message MUST contain the same priority
尽管实现可能会从定义的范围（4-7）中选择不同的值，但建议使用默认优先级。对ForCES消息的响应必须包含相同的优先级
as the request. For example, a config sent by the CE with priority 5 MUST have a config-response from the FE with priority 5.
根据要求。例如，CE发送的优先级为5的配置必须具有FE发送的优先级为5的配置响应。
The medium-priority (MP) channel uses SCTP-PR on port 6705. SCTP PPID 22 MUST be used for all messages on the MP channel. Time limits on how long a message is valid are set on each outgoing message. This channel is used for events from the FE to the CE that are obsoleted over time. Events that are accumulative in nature and are recoverable by the CE (by issuing a query to the FE) can tolerate lost events and therefore should use this channel. For example, a generated event that carries the value of a counter that is monotonically incrementing is fit to use this channel.
中等优先级（MP）通道在端口6705上使用SCTP-PR。MP通道上的所有消息都必须使用SCTP PPID 22。每个传出消息都设置了消息有效时间限制。此通道用于FE到CE之间随时间推移而过时的事件。本质上是累积的且可由CE（通过向FE发出查询）恢复的事件可以容忍丢失事件，因此应使用此通道。例如，携带单调递增计数器值的生成事件适合使用此通道。
PL priority 3 MUST be used for PL messages on this channel. The following PL messages MUST use the MP channel for transport:
PL优先级3必须用于此通道上的PL消息。以下PL消息必须使用MP通道进行传输：
o Event Notification (default priority: 3)
o 事件通知（默认优先级：3）
If PL priorities outside of the specified priority, PPID, or PL message type other than the above are received on the MP channel, then the PL message MUST be dropped.
如果在MP通道上接收到指定优先级、PPID或PL消息类型以外的PL优先级，则必须丢弃PL消息。
The lower-priority (LP) channel uses SCTP port 6706. SCTP PPID 23 is used for all messages on the LP channel. The LP channel also MUST use SCTP-PR with lower timeout values than the MP channel. The reason an unreliable channel is used for redirect messages is to allow the control protocol at both the CE and its peer-endpoint to take charge of how the end-to-end semantics of the said control protocol's operations. For example:
低优先级（LP）信道使用SCTP端口6706。SCTP PPID 23用于LP通道上的所有消息。LP通道还必须使用SCTP-PR，其超时值低于MP通道。不可靠信道用于重定向消息的原因是允许CE及其对等端点处的控制协议负责所述控制协议的操作的端到端语义。例如：
1. Some control protocols are reliable in nature, therefore making this channel reliable introduces an extra layer of reliability that could be harmful. So any end-to-end retransmits will happen remotely.
1. 某些控制协议本质上是可靠的，因此，使此通道可靠会增加一层可能有害的可靠性。因此，任何端到端的重新传输都将远程进行。
2. Some control protocols may desire having obsolescence of messages over retransmissions; making this channel reliable contradicts that desire.
2. 一些控制协议可能希望消息在重传过程中过时；使这个频道可靠与这种愿望相矛盾。
Given ForCES PL heartbeats are traffic sensitive, sending them over the LP channel also makes sense. If the other end is not processing other channels, it will eventually get heartbeats; and if it is busy processing other channels, heartbeats will be obsoleted locally over time (and it does not matter if they did not make it).
鉴于PL心跳对流量敏感，通过LP通道发送它们也是有意义的。如果另一端不处理其他通道，它最终将获得心跳；如果它忙于处理其他通道，心跳将随着时间推移在本地被淘汰（如果他们没有做到这一点也没关系）。
PL priorities 1-2 MUST be used for PL messages on this channel. PL messages that MUST use the MP channel for transport are:
PL优先级1-2必须用于此通道上的PL消息。必须使用MP通道进行传输的PL消息包括：
o PacketRedirect (default priority: 2)
o PacketRedirect（默认优先级：2）
o Heartbeat (default priority: 1)
o 心跳信号（默认优先级：1）
If PL priorities outside of the specified priority range, PPID, or PL message types other than the above are received on the LP channel, then the PL message MUST be dropped.
如果在LP通道上接收到指定优先级范围、PPID或PL消息类型以外的PL优先级，则必须丢弃PL消息。
In processing the sending and receiving of the PL messages, the TML core uses strict priority work-conserving scheduling, as shown in Figure 5.
在处理PL消息的发送和接收时，TML核心使用严格的优先级工作节约调度，如图5所示。
This means that the HP messages are always processed first until there are no more left. The LP channel is processed only if channels that are a higher priority than itself have no messages left to process. This means that under a congestion situation, a higher-priority channel with sufficient messages that occupy the available bandwidth would starve lower-priority channel(s).
这意味着HP消息始终先被处理，直到没有剩余消息为止。仅当优先级高于其自身的通道没有要处理的消息时，才处理LP通道。这意味着在拥塞情况下，具有足够消息且占用可用带宽的高优先级信道将耗尽低优先级信道。
The design intent of the SCTP TML is to tie processing prioritization, as described in Section 4.2.1.1, and transport congestion control to provide implicit node congestion control. This is further detailed in Appendix A.2.
SCTP TML的设计意图是将处理优先级（如第4.2.1.1节所述）与传输拥塞控制联系起来，以提供隐式节点拥塞控制。附录A.2对此进行了详细说明。
It should be emphasized that the work scheduling prioritization scheme prescribed in this document is receiver-based processing. Fully arrived packets on any of the channels are a source of work whose output may result in transmitted packets. However, we have no control on the order in which the SCTP/OS/network chooses to send transmitted packets across and make them available to the receiver. This is a limitation that we try to ameliorate by our choice of channel properties, ForCES message grouping, and the tying of CE and FE work scheduling. While that helps us ameliorate some of these issues, it does not fully resolve all.
应该强调的是，本文件中规定的工作调度优先级方案是基于接收者的处理。任何信道上完全到达的数据包都是工作源，其输出可能导致传输数据包。但是，我们无法控制SCTP/OS/网络选择发送传输数据包并使其可供接收器使用的顺序。这是一个限制，我们试图通过选择通道属性、强制消息分组以及将CE和FE工作调度捆绑在一起来改善。虽然这有助于我们改善其中一些问题，但并不能完全解决所有问题。
From a ForCES perspective, we can tolerate some reordering. For example, if an FE transmits a config response (HP) followed by 10000 OSPF redirect packets (LP) and the CE gets 5 OSPF redirects (LP) first before the config response (HP), that is tolerable. What matters is the CE gets to processing the HP message soon (instead of sitting in long periods of time processing OSPF packets that would have happened if we use a single socket with three streams). This is
从部队的角度来看，我们可以容忍一些重新排序。例如，如果FE发送配置响应（HP），然后发送10000个OSPF重定向数据包（LP），并且CE在配置响应（HP）之前首先获得5个OSPF重定向（LP），这是可以容忍的。重要的是CE很快就开始处理HP消息（而不是长时间地处理OSPF数据包，如果我们使用具有三个流的单个套接字，就会发生这种情况）。这是
particularly important in order to deal with node overload well, as discussed in Section 4.2.2.6.
如第4.2.2.6节所述，为了更好地处理节点过载，这一点尤为重要。
SCTP channel +----------+
Work available | DONE +---<--<--+
| +---+------+ |
Y ^
| +-->--+ +-->---+ |
+-->-->-+ | | | | |
| | | | | | ^
| ^ ^ v ^ v |
^ / \ | | | | |
| / \ | ^ | ^ ^
| / Is \ | / \ | / \ |
| / there \ | /Is \ | /Is \ |
^ / HP work \ ^ /there\ ^ /there\ ^
| \ ? / | /MP work\ | /LP work\ |
| \ / | \ ? / | \ ? / |
| \ / | \ / | \ / ^
| \ / ^ \ / ^ \ / |
| \ / | \ / | \ / |
^ Y-->-->-->+ Y-->-->-->+ Y->->->-+
| | NO | NO | NO
| | | |
| Y Y Y
| | YES | YES | YES
^ | | |
| Y Y Y
| +----+------+ +---|-------+ +----|------+
| |- process | |- process | |- process |
| | HP work | | MP work | | LP work |
| +------+----+ +-----+-----+ +-----+-----+
| | | |
^ Y Y Y
| | | |
| Y Y Y
+--<--<---+--<--<----<----+-----<---<-----+
SCTP channel +----------+
Work available | DONE +---<--<--+
| +---+------+ |
Y ^
| +-->--+ +-->---+ |
+-->-->-+ | | | | |
| | | | | | ^
| ^ ^ v ^ v |
^ / \ | | | | |
| / \ | ^ | ^ ^
| / Is \ | / \ | / \ |
| / there \ | /Is \ | /Is \ |
^ / HP work \ ^ /there\ ^ /there\ ^
| \ ? / | /MP work\ | /LP work\ |
| \ / | \ ? / | \ ? / |
| \ / | \ / | \ / ^
| \ / ^ \ / ^ \ / |
| \ / | \ / | \ / |
^ Y-->-->-->+ Y-->-->-->+ Y->->->-+
| | NO | NO | NO
| | | |
| Y Y Y
| | YES | YES | YES
^ | | |
| Y Y Y
| +----+------+ +---|-------+ +----|------+
| |- process | |- process | |- process |
| | HP work | | MP work | | LP work |
| +------+----+ +-----+-----+ +-----+-----+
| | | |
^ Y Y Y
| | | |
| Y Y Y
+--<--<---+--<--<----<----+-----<---<-----+
Figure 5: SCTP TML Strict Priority Scheduling
图5:SCTP TML严格优先级调度
The following is a list of parameters needed for booting the TML. It is expected these parameters will be extracted via the FEM/CEM interface for each PL ID.
以下是启动TML所需的参数列表。预计这些参数将通过FEM/CEM接口为每个PL ID提取。
1. The IP address(es) or a resolvable DNS/hostname(s) of the CE/FE.
1. CE/FE的IP地址或可解析DNS/主机名。
2. Whether or not to use IPsec. If IPsec is used, how to parameterize the different required ciphers, keys, etc., as described in Section 7.1
2. 是否使用IPsec。如果使用IPsec，如何按照第7.1节所述参数化不同的所需密码、密钥等
3. The HP SCTP port, as discussed in Section 4.2.1.2. The default HP port value is 6704 (Section 6).
3. HP SCTP端口，如第4.2.1.2节所述。默认HP端口值为6704（第6节）。
4. The MP SCTP port, as discussed in Section 4.2.1.3. The default MP port value is 6705 (Section 6).
4. MP SCTP端口，如第4.2.1.3节所述。默认MP端口值为6705（第6节）。
5. The LP SCTP port, as discussed in Section 4.2.1.4. The default LP port value is 6706 (Section 6).
5. LP SCTP端口，如第4.2.1.4节所述。默认LP端口值为6706（第6节）。
[RFC5810], Section 5 lists requirements that a TML needs to meet. This section describes how the SCTP TML satisfies those requirements.
[RFC5810]，第5节列出了TML需要满足的要求。本节描述了SCTP TML如何满足这些要求。
As mentioned earlier, a shade of reliability ranges is possible in SCTP. Therefore, this requirement is met.
如前所述，SCTP中可能存在一定程度的可靠性范围。因此，满足了这一要求。
Congestion control is built into SCTP. Therefore, this requirement is met.
拥塞控制内置于SCTP中。因此，满足了这一要求。
By using three sockets in conjunction with the partial-reliability feature [RFC3758], both timeliness and prioritization requirements are addressed.
通过将三个插座与部分可靠性功能[RFC3758]结合使用，解决了时效性和优先级要求。
There are no extra headers required for SCTP to fulfill this requirement. SCTP can be told to replicast packets to multiple destinations. The TML implementation will need to translate PL addresses to a variety of unicast IP addresses in order to emulate multicast and broadcast PL addresses.
SCTP不需要额外的标头来满足此要求。可以告诉SCTP将数据包复制到多个目的地。TML实现需要将PL地址转换为各种单播IP地址，以便模拟多播和广播PL地址。
Transport link resiliency is one of SCTP's strongest points. Failure detection and recovery is built in, as mentioned earlier.
传输链路弹性是SCTP最强大的点之一。如前所述，故障检测和恢复是内置的。
o The SCTP multi-homing feature is used to provide path diversity. Should one of the peer IP addresses become unreachable, the others are used without needing lower-layer convergence (routing, for example) or even the TML becoming aware.
o SCTP多归宿功能用于提供路径分集。如果其中一个对等IP地址变得不可访问，则使用其他对等IP地址而不需要较低层的聚合（例如，路由），甚至TML也不需要知道。
o SCTP heartbeats and data transmission thresholds are used on a per-peer IP address to detect reachability faults. The faults could be a result of an unreachable address or peer, which may be caused by a variety of reasons, like interface, network, or endpoint failures. The cause of the fault is noted.
o 在每个对等IP地址上使用SCTP心跳和数据传输阈值来检测可达性故障。故障可能是无法访问的地址或对等方造成的，这可能是由多种原因造成的，如接口、网络或端点故障。已记录故障原因。
o With the ADDIP feature, one can migrate IP addresses to other nodes at runtime. This is not unlike the Virtual Router Redundancy Protocol (VRRP) [RFC5798] use. This feature is used in addition to multi-homing in a planned migration of activity from one FE/CE to another. In such a case, part of the provisioning recipe at the CE for replacing an FE involves migrating activity of one FE to another.
o 使用ADDIP功能，可以在运行时将IP地址迁移到其他节点。这与虚拟路由器冗余协议（VRRP）[RFC5798]的使用并无不同。在活动从一个FE/CE到另一个FE/CE的计划迁移中，除了使用多归宿功能外，还使用此功能。在这种情况下，CE处用于替换FE的供应配方的一部分涉及将一个FE的活动迁移到另一个FE。
The architecture of this TML defines three separate channels, one per socket, to be used within any FE-CE setup. The work scheduling design for processing the TML channels (Section 4.2.1.5) is a strict priority. A fundamental desire of the strict prioritization is to ensure that more important processing work always gets node resources over less important work.
该TML的体系结构定义了三个单独的通道，每个插槽一个，用于任何FE-CE设置。处理TML信道的工作调度设计（第4.2.1.5节）具有严格的优先级。严格优先级划分的一个基本要求是确保更重要的处理工作总是比不太重要的工作获得节点资源。
When a ForCES node CPU is overwhelmed because the incoming packet rate is higher than it can keep up with, the channel queues grow and transport congestion subsequently follows. By virtue of using SCTP, the congestion is propagated back to the source of the incoming packets and eventually alleviated.
当强制节点CPU因传入数据包速率高于其所能跟上的速度而被压垮时，信道队列会增长，随后会出现传输拥塞。通过使用SCTP，拥塞被传播回传入数据包的源，并最终得到缓解。
The HP channel work gets prioritized at the expense of the MP, which gets prioritized over LP channels. The preferential scheduling only kicks in when there is node overload regardless of whether there is transport congestion. As a result of the preferential work treatment, the ForCES node achieves a robust steady processing capacity. Refer to Appendix A.2 for details on scheduling.
HP渠道工作的优先顺序是以牺牲MP为代价的，后者优先于LP渠道。无论是否存在传输拥塞，优先调度仅在节点过载时生效。作为优先工作待遇的结果，ForCES节点实现了强健稳定的处理能力。有关日程安排的详细信息，请参阅附录A.2。
For an example of how the overload prevention works, consider a scenario where an overwhelming amount of redirected packets (from outside the NE) coming into the NE may overload the FE while it has outstanding config work from the CE. In such a case, the FE, while it is busy processing config requests from the CE, essentially ignores processing the redirect packets on the LP channel. If enough redirect packets accumulate, they are dropped either because the LP
对于过载预防如何工作的一个例子，考虑一个场景，其中大量的重定向数据包（来自NE外）进入NE可能过载FE，同时它具有来自CE的出色配置工作。在这种情况下，FE在忙于处理来自CE的配置请求时，基本上忽略处理LP通道上的重定向数据包。如果累积了足够多的重定向数据包，它们将被丢弃，因为LP
channel threshold is exceeded or because they are obsoleted. If on the other hand, the FE has successfully processed the higher-priority channels and their related work, then it can proceed and process the LP channel. So as demonstrated in this case, the TML ties transport congestion and node overload implicitly together.
通道阈值已超过或已过时。另一方面，如果FE已成功处理高优先级通道及其相关工作，则可以继续处理LP通道。如本例所示，TML将传输拥塞和节点过载隐式地联系在一起。
The SCTP TML sets SCTP PPIDs to identify channels used as described in Section 4.2.1.1.
SCTP TML设置SCTP PPID，以识别第4.2.1.1节所述的信道。
There are two levels of TML channel work within an NE when a ForCES node (CE or FE) is connected to multiple other ForCES nodes:
当一个ForCES节点（CE或FE）连接到多个其他ForCES节点时，网元内有两级TML信道工作：
1. NE-level I/O work where a ForCES node (CE or FE) needs to choose which of the peer nodes to process.
1. 网元级I/O工作，其中强制节点（CE或FE）需要选择要处理的对等节点。
2. Node-level I/O work where a ForCES node, handles the three SCTP TML channels separately for each single ForCES endpoint.
2. 节点级I/O工作，其中ForCES节点分别为每个ForCES端点处理三个SCTP TML通道。
NE-level scheduling definition is left up to the implementation and is considered out of scope for this document. Appendix A.4 briefly discusses some constraints about which an implementer needs to worry.
网元级调度定义由实现决定，不在本文档范围内。附录A.4简要讨论了实施者需要担心的一些约束。
This document provides suggestions on SCTP channel work implementation in Appendix A.
本文件在附录A中提供了关于SCTP渠道工作实施的建议。
The FE SHOULD do channel connections to the CE in the order of incrementing priorities, i.e., LP socket first, followed by MP, and ending with HP socket connection. The CE, however, MUST NOT assume that there is ordering of socket connections from any FE.
FE应按照优先级递增的顺序进行与CE的通道连接，即先是LP套接字，然后是MP，最后是HP套接字连接。然而，CE不得假设任何FE都有插座连接的订购。
Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226], the following namespaces are defined in ForCES SCTP TML.
按照“在RFCs中编写IANA注意事项部分的指南”[RFC5226]中概述的策略，在ForCES SCTP TML中定义了以下名称空间。
o SCTP port 6704 for the HP channel, 6705 for the MP channel, and 6706 for the LP channel.
o SCTP端口6704用于HP通道，6705用于MP通道，6706用于LP通道。
o SCTP Payload Protocol ID (PPID) 21 for the HP channel (ForCES-HP), 22 for the MP channel (ForCES-MP), and 23 for the LP channel (ForCES-LP).
o SCTP有效负载协议ID（PPID）21用于HP信道（强制HP），22用于MP信道（强制MP），23用于LP信道（强制LP）。
The SCTP TML provides the following security services to the PL:
SCTP TML向PL提供以下安全服务：
o A mechanism to authenticate ForCES CEs and FEs at the transport level in order to prevent the participation of unauthorized CEs and unauthorized FEs in the control and data path processing of a ForCES NE.
o 一种在传输级别对强制CE和FEs进行身份验证的机制，以防止未经授权的CE和FEs参与强制NE的控制和数据路径处理。
o A mechanism to ensure message authentication of PL data and headers transferred from the CE to FE (and vice versa) in order to prevent the injection of incorrect data into PL messages.
o 确保PL数据和从CE传输到FE（反之亦然）的标头的消息身份验证的机制，以防止向PL消息中注入不正确的数据。
o A mechanism to ensure the confidentiality of PL data and headers transferred from the CE to FE (and vice versa), in order to prevent disclosure of PL information transported via the TML.
o 一种确保从CE传输到FE（反之亦然）的PL数据和报头机密性的机制，以防止通过TML传输的PL信息泄露。
Security choices provided by the TML are made by the operator and take effect during the pre-association phase of the ForCES protocol. An operator may choose to use all, some or none of the security services provided by the TML in a CE-FE connection.
TML提供的安全选择由操作员做出，并在部队协议的预关联阶段生效。运营商可以选择在CE-FE连接中使用TML提供的全部、部分或全部安全服务。
When operating under a secured environment, or for other operational concerns (in some cases performance issues) the operator may turn off all the security functions between CE and FE.
在安全环境下运行时，或出于其他运行问题（在某些情况下，性能问题），操作员可能会关闭CE和FE之间的所有安全功能。
IP Security Protocol (IPsec) [RFC4301] is used to provide needed security mechanisms.
IP安全协议（IPsec）[RFC4301]用于提供所需的安全机制。
IPsec is an IP-level security scheme transparent to the higher-layer applications and therefore can provide security for any transport layer protocol. This gives IPsec the advantage that it can be used to secure everything between the CE and FE without expecting the TML implementation to be aware of the details.
IPsec是对高层应用程序透明的IP级安全方案，因此可以为任何传输层协议提供安全性。这使IPsec的优势在于，它可以用来保护CE和FE之间的所有内容，而不需要TML实现知道细节。
The IPsec architecture is designed to provide message integrity and message confidentiality outlined in the TML security requirements [RFC5810]. Mutual authentication and key exchange protocol are provided by Internet Key Exchange (IKE) [RFC2409].
IPsec体系结构旨在提供TML安全要求[RFC5810]中概述的消息完整性和消息机密性。相互认证和密钥交换协议由Internet密钥交换（IKE）[RFC2409]提供。
A ForCES FE or CE MUST support the following:
力FE或CE必须支持以下各项：
o Internet Key Exchange (IKE)[RFC2409] with certificates for endpoint authentication.
o Internet密钥交换（IKE）[RFC2409]带有用于端点身份验证的证书。
o Transport Mode Encapsulating Security Payload (ESP) [RFC4303].
o 传输模式封装安全有效负载（ESP）[RFC4303]。
o HMAC-SHA1-96 [RFC2404] for message integrity protection
o HMAC-SHA1-96[RFC2404]用于消息完整性保护
o AES-CBC with 128-bit keys [RFC3602] for message confidentiality.
o AES-CBC，带有128位密钥[RFC3602]，用于消息保密。
o Replay protection [RFC4301].
o 重播保护[RFC4301]。
A compliant implementation SHOULD provide operational means for configuring the CE and FE to negotiate other cipher suites and even use manual keying.
合规实施应提供操作手段，用于配置CE和FE以协商其他密码套件，甚至使用手动键控。
To minimize the operational configuration, it is RECOMMENDED that only the IANA-issued SCTP protocol number (132) be used as a selector in the Security Policy Database (SPD) for ForCES. In such a case, only a single SPD and SAD entry is needed.
为尽量减少操作配置，建议仅将IANA发布的SCTP协议编号（132）用作部队安全策略数据库（SPD）中的选择器。在这种情况下，只需要一个SPD和SAD条目。
Setup MAY alternatively extend the above policy so that it uses the three SCTP TML port numbers as SPD selectors. But as noted above, this choice will require an increased number of SPD entries.
安装程序也可以扩展上述策略，以便使用三个SCTP TML端口号作为SPD选择器。但如上所述，这一选择将需要增加SPD条目的数量。
In scenarios where multiple IP addresses are used within a single association, and there is desire to configure different policies on a per-IP address, then following [RFC3554] is RECOMMENDED.
如果在单个关联中使用多个IP地址，并且希望在每个IP地址上配置不同的策略，则建议遵循[RFC3554]。
The authors would like to thank Joel Halpern, Michael Tuxen, Randy Stewart, Evangelos Haleplidis, Chuanhuang Li, Lars Eggert, Avshalom Houri, Adrian Farrel, Juergen Quittek, Magnus Westerlund, and Pasi Eronen for engaging us in discussions that have made this document better.
作者要感谢Joel Halpern、Michael Tuxen、Randy Stewart、Evangelos Haleplidis、Chuanhuang Li、Lars Eggert、Avshalom Houri、Adrian Farrel、Juergen Quitek、Magnus Westerlund和Pasi Eronen让我们参与讨论，使本文件变得更好。
Ross Callon was an excellent manager who persevered in providing us guidance and Joel Halpern was an excellent document shepherd without whom this document would have taken longer to publish.
罗斯·卡隆（Ross Callon）是一位优秀的经理，他坚持不懈地为我们提供指导，而乔尔·哈尔伯恩（Joel Halpern）是一位优秀的文档管理员，如果没有他，本文档的出版时间会更长。
[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月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC3554]Bellovin，S.，Ioannidis，J.，Keromytis，A.，和R.Stewart，“关于流控制传输协议（SCTP）与IPsec的使用”，RFC 3554，2003年7月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，2004年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年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月。
[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., HAAS, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010.
[RFC5810]Doria，A.，Ed.，Hadi Salim，J.，Ed.，HAAS，R.，Ed.，Khosravi，H.，Ed.，Wang，W.，Ed.，Dong，L.，Gopal，R.，和J.Halpern，“转发和控制元素分离（部队）协议规范”，RFC 58102010年3月。
[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月。
[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月。
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[RFC5798]Nadas，S.，编辑，“IPv4和IPv6的虚拟路由器冗余协议（VRRP）第3版”，RFC 5798，2010年3月。
[TSVWG-SCTPSOCKET] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Work in Progress, March 2010.
[TSVWG-SCTPSOCKET]Stewart，R.，Poon，K.，Tuexen，M.，Yasevich，V.，和P.Lei，“流控制传输协议（SCTP）的套接字API扩展”，正在进行的工作，2010年3月。
As mentioned in Section 5, there are two levels of TML channel work within an NE when a ForCES node (CE or FE) is connected to multiple other ForCES nodes:
如第5节所述，当一个ForCES节点（CE或FE）连接到多个其他ForCES节点时，网元内有两个TML信道工作级别：
1. NE-level I/O work where a ForCES node (CE or FE) needs to choose which of the peer nodes to process.
1. 网元级I/O工作，其中强制节点（CE或FE）需要选择要处理的对等节点。
2. Node-level I/O work where a ForCES node, handles the three SCTP TML channels separately for each single ForCES endpoint.
2. 节点级I/O工作，其中ForCES节点分别为每个ForCES端点处理三个SCTP TML通道。
NE-level scheduling definition is left up to the implementation and is considered out of scope for this document. Appendix A.4 briefly discusses some constraints about which an implementer needs to worry.
网元级调度定义由实现决定，不在本文档范围内。附录A.4简要讨论了实施者需要担心的一些约束。
This document, and in particular Appendix A.1, Appendix A.2, and Appendix A.3 discuss details of node-level I/O work.
本文件，尤其是附录A.1、附录A.2和附录A.3讨论了节点级I/O工作的细节。
As discussed in Section 5, it is recommended that the FE SHOULD do socket connections to the CE in the order of incrementing priorities, i.e., LP socket first, followed by MP, and ending with HP socket connection. The CE, however, MUST NOT assume that there is ordering of socket connections from any FE. Appendix B.1 has more details on the expected initialization of SCTP channel work.
如第5节所述，建议FE按照优先级递增的顺序进行与CE的插座连接，即先是LP插座，然后是MP插座，最后是HP插座连接。然而，CE不得假设任何FE都有插座连接的订购。附录B.1详细说明了SCTP通道工程的预期初始化。
This section provides high-level details of the scheduling view of the SCTP TML core (Section 4.2.1). A practical scheduler implementation takes care of many little details (such as timers, work quanta, etc.) not described in this document. It is left to the implementer to take care of those details.
本节提供了SCTP TML核心调度视图的高级详细信息（第4.2.1节）。一个实用的调度器实现会处理许多本文档中没有描述的小细节（如计时器、工作量子等）。这些细节由实现者负责。
The CE(s) and FE(s) are coupled together in the principles of the scheduling scheme described here to tie together node overload with transport congestion. The design intent is to provide the highest possible robust work throughput for the NE under any network or processing congestion.
在这里描述的调度方案的原理中，CE（s）和FE（s）耦合在一起，以将节点过载与传输拥塞联系在一起。设计意图是在任何网络或处理拥塞情况下为网元提供尽可能高的健壮工作吞吐量。
The FE scheduling, in priority order, needs to I/O process:
FE调度按优先级顺序需要进行I/O处理：
1. The HP channel I/O in the following priority order:
1. HP通道I/O的优先级顺序如下：
1. Transmitting back to the CE any outstanding result of executed work via the HP channel transmit path.
1. 通过HP通道传输路径将执行工作的任何未完成结果传输回CE。
2. Taking new incoming work from the CE that creates ForCES work to be executed by the FE.
2. 从CE获取新的传入功，该功将强制FE执行。
2. ForCES events that result in transmission of unsolicited ForCES packets to the CE via the MP channel.
2. 强制事件，导致通过MP信道向CE传输未经请求的强制数据包。
3. Incoming Redirect work in the form of control packets that come from the CE via LP channel. After redirect processing, these packets get sent out on external (to the NE) interface.
3. 传入重定向以控制数据包的形式工作，这些数据包通过LP通道来自CE。在重定向处理之后，这些数据包通过外部（到网元）接口发送出去。
4. Incoming Redirect work in the form of control packets that come from other NEs via external (to the NE) interfaces. After some processing, such packets are sent to the CE.
4. 传入重定向以控制数据包的形式工作，这些数据包通过外部（到网元）接口来自其他网元。在一些处理之后，这些分组被发送到CE。
It is worth emphasizing, at this point again, that the SCTP TML processes the channel work in strict priority. For example, as long as there are messages to send to the CE on the HP channel, they will be processed first until there are no more left before processing the next priority work (which is to read new messages on the HP channel incoming from the CE).
在这一点上，值得再次强调的是，SCTP TML以严格的优先级处理信道工作。例如，只要HP频道上有要发送给CE的消息，就会先处理这些消息，直到没有剩余消息为止，然后再处理下一个优先级工作（即读取HP频道上从CE传入的新消息）。
The CE scheduling, in priority order, needs to deal with:
CE调度按优先级顺序需要处理：
1. The HP channel I/O in the following priority order:
1. HP通道I/O的优先级顺序如下：
1. Process incoming responses to requests of work it made to the FE(s).
1. 处理对其向FE提出的工作请求的传入响应。
2. Transmit any outstanding HP work it needs the FE(s) to complete.
2. 传输任何需要FE完成的未完成HP工作。
2. Incoming ForCES events from the FE(s) via the MP channel.
2. 来自FE（s）通过MP通道的来袭部队事件。
3. Outgoing Redirect work in the form of control packets that get sent from the CE via LP channel destined to external (to the NE) interface on FE(s).
3. 传出重定向以控制数据包的形式工作，控制数据包通过LP通道从CE发送到FE上的外部（到NE）接口。
4. Incoming Redirect work in the form of control packets that come from other NEs via external interfaces (to the NE) on the FE(s).
4. 传入重定向以控制数据包的形式工作，这些数据包通过FE上的外部接口（到网元）来自其他网元。
It is worth repeating, for emphasis, that the SCTP TML processes the channel work in strict priority. For example, if there are messages incoming from an FE on the HP channel, they will be processed first
值得强调的是，SCTP TML以严格的优先级处理信道工作。例如，如果HP频道上有来自FE的消息，将首先处理这些消息
until there are no more left before processing the next priority work, which is to transmit any outstanding HP channel messages going to the FE.
在处理下一项优先工作之前，将所有未完成的HP通道信息传输至FE，直到没有剩余信息为止。
Appendix B.2 describes a controlled disassociation of the FE from the NE.
附录B.2描述了FE与NE的受控分离。
It is also possible for connectivity to be lost between the FE and CE on one or more sockets. In cases where SCTP multi-homing features are used for path availability, the disconnection of a socket will only occur if all paths are unreachable; otherwise, SCTP will ensure reachability. In the situation of a total connectivity loss of even one SCTP socket, it is recommended that the FE and CE SHOULD assume a state equivalent to ForCES Association Teardown being issued and follow the sequence described in Appendix B.2.
一个或多个插座上的FE和CE之间也可能失去连接。在SCTP多主功能用于路径可用性的情况下，只有当所有路径都无法访问时，才会断开套接字；否则，SCTP将确保可达性。在连一个SCTP插座都完全失去连接的情况下，建议FE和CE应假设一种等同于正在发布的力关联拆卸的状态，并遵循附录B.2中所述的顺序。
A CE could also disconnect sockets to an FE to indicate an "emergency teardown". The "emergency teardown" may be necessary in cases when a CE needs to disconnect an FE but knows that an FE is busy processing a lot of outstanding commands (some of which the FE hasn't gotten around to processing, yet). By virtue of the CE closing the connections, the FE will immediately be asynchronously notified and will not have to process any outstanding commands from the CE.
CE还可以断开FE的插座，以指示“紧急拆卸”。当CE需要断开FE，但知道FE正忙于处理大量未完成的命令（其中一些命令FE尚未着手处理）时，可能需要“紧急拆卸”。通过CE关闭连接，FE将立即收到异步通知，并且不必处理来自CE的任何未完成命令。
In handling NE-level I/O work, an implementation needs to worry about being both fair and robust across peer ForCES nodes.
在处理网元级I/O工作时，实现需要考虑在对等节点之间的公平性和健壮性。
Fairness is desired so that each peer node makes progress across the NE. For the sake of illustration, consider two FEs connected to a CE; whereas one FE has a few HP messages that need to be processed by the CE, another may have infinite HP messages. The scheduling scheme may decide to use a quota scheduling system to ensure that the second FE does not hog the CE cycles.
需要公平性，以便每个对等节点在整个网元上取得进展。为了说明，考虑连接到CE的两个FES；一个FE有一些HP消息需要CE处理，而另一个FE可能有无限的HP消息。调度方案可决定使用配额调度系统以确保第二FE不占用CE周期。
Robustness is desired so that the NE does not succumb to a Denial-of-Service (DoS) attack from hostile entities and always achieves a maximum stable workload processing level. For the sake of illustration, consider again two FEs connected to a CE. Consider FE1 as having a large number of HP and MP messages and FE2 having a large number of MP and LP messages. The scheduling scheme needs to ensure that while FE1 always gets its messages processed, at some point we allow FE2 messages to be processed. A promotion and preemption-based scheduling could be used by the CE to resolve this issue.
需要健壮性，以便网元不会屈服于来自敌对实体的拒绝服务（DoS）攻击，并始终实现最大稳定的工作负载处理级别。为了说明，再次考虑连接到CE的两个FES。考虑FE1具有大量HP和MP消息，并且FE2具有大量MP和LP消息。调度方案需要确保，虽然FE1总是处理其消息，但在某个时刻，我们允许处理FE2消息。CE可以使用基于提升和抢占的调度来解决此问题。
This section outlines a high-level service interface between FEM/CEM and TML, the PL and TML, and between local and remote TMLs. The intent of this interface discussion is to provide general guidelines. The implementer is expected to care of details and even follow a different approach if needed.
本节概述了FEM/CEM和TML、PL和TML以及本地和远程TML之间的高级服务接口。本接口讨论的目的是提供一般指南。期望实现者关注细节，甚至在需要时采用不同的方法。
The theory of operation for the PL-TML service is as follows:
PL-TML服务的操作原理如下：
1. The PL starts up and bootstraps the TML. The end result of a successful TML bootstrap is that the CE TML and the FE TML connect to each other at the transport level.
1. PL启动并引导TML。TML引导成功的最终结果是CE TML和FE TML在传输级别相互连接。
2. Transmission and reception of the PL messages commences after a successful TML bootstrap. The PL uses send and receive PL-TML interfaces to communicate to its peers. The TML is agnostic to the nature of the messages being sent or received. The first message exchanges that happen are to establish ForCES association. Subsequent messages may be either unsolicited events from the FE PL, control message redirects to/from the CE to/from FE, or configuration from the CE to the FE, and their responses flowing from the FE to the CE.
2. 在TML引导成功后，PL消息的传输和接收开始。PL使用发送和接收PL-TML接口与对等方通信。TML对正在发送或接收的消息的性质是不可知的。发生的第一个消息交换是建立部队联系。后续消息可以是来自FE-PL的未经请求的事件，控制消息重定向到/从CE到/从FE，或者从CE到FE的配置，以及它们的响应从FE流到CE。
3. The PL does a shutdown of the TML after terminating ForCES association.
3. PL在终止力关联后关闭TML。
Figure 6 illustrates a flow for the TML bootstrapped by the PL.
图6展示了PL引导的TML流程。
When the PL starts up (possibly after some internal initialization), it boots up the TML. The TML first interacts with the FEM/CEM and acquires the necessary TML parameterization (Section 4.2.1.6). Next, the TML uses the information it retrieved from the FEM/CEM interface to initialize itself.
当PL启动时（可能在一些内部初始化之后），它将引导TML。TML首先与FEM/CEM交互，并获得必要的TML参数化（第4.2.1.6节）。接下来，TML使用从FEM/CEM接口检索到的信息来初始化自身。
The TML on the FE proceeds to connect the three channels to the CE. The socket interface is used for each of the channels. The TML continues to re-try the connections to the CE until all three channels are connected. It is advisable that the number of connection retry attempts and the time between each retry is also configurable via the FEM. On failure to connect one or more channels, and after the configured number of retry thresholds is exceeded, the TML will return an appropriate failure indicator to the PL. On success (as shown in Figure 6), a success indication is presented to the PL.
FE上的TML继续将三个通道连接到CE。套接字接口用于每个通道。TML继续重新尝试与CE的连接，直到所有三个通道都已连接。建议通过FEM配置连接重试次数和每次重试之间的时间。在连接一个或多个通道失败时，并且在超过配置的重试阈值数量后，TML将向PL返回适当的失败指示器。成功时（如图6所示），将向PL显示成功指示。
FE PL FE TML FEM CEM CE TML CE PL
| | | | | |
| | | | | Bootup |
| | | | |<-------------------|
| Bootup | | | | |
|----------->| | |get CEM info| |
| |get FEM info | |<-----------| |
| |------------>| ~ ~ |
| ~ ~ |----------->| |
| |<------------| | |
| | |-initialize TML |
| | |-create the 3 chans.|
| | | to listen to FEs |
| | | |
| |-initialize TML |Bootup success |
| |-create the 3 chans. locally |------------------->|
| |-connect 3 chans. remotely | |
| |------------------------------>| |
| ~ ~ - FE TML connected ~
| ~ ~ - FE TML info init ~
| | channels connected | |
| |<------------------------------| |
| Bootup | | |
| succeeded | | |
|<-----------| | |
| | | |
FE PL FE TML FEM CEM CE TML CE PL
| | | | | |
| | | | | Bootup |
| | | | |<-------------------|
| Bootup | | | | |
|----------->| | |get CEM info| |
| |get FEM info | |<-----------| |
| |------------>| ~ ~ |
| ~ ~ |----------->| |
| |<------------| | |
| | |-initialize TML |
| | |-create the 3 chans.|
| | | to listen to FEs |
| | | |
| |-initialize TML |Bootup success |
| |-create the 3 chans. locally |------------------->|
| |-connect 3 chans. remotely | |
| |------------------------------>| |
| ~ ~ - FE TML connected ~
| ~ ~ - FE TML info init ~
| | channels connected | |
| |<------------------------------| |
| Bootup | | |
| succeeded | | |
|<-----------| | |
| | | |
Figure 6: SCTP TML Bootstrapping
图6:SCTP TML引导
On the CE, things are slightly different. After initializing from the CEM, the TML on the CE side proceeds to initialize the three channels to listen to remote connections from the FEs. The success or failure indication is passed on to the CE PL (in the same manner as was done in the FE).
在CE方面，情况略有不同。从CEM初始化后，CE侧的TML继续初始化三个通道，以侦听来自FEs的远程连接。成功或失败指示将传递给CE PL（与FE中的方式相同）。
Post bootup, the CE TML waits for connections from the FEs. Upon a successful connection by an FE, the CE TML level keeps track of the transport-level details of the FE. Note, at this stage only transport-level connection has been established; ForCES-level association follows using send/receive PL-TML interfaces (refer to Appendix B.3 and Figure 8).
启动后，CE TML等待来自FEs的连接。FE成功连接后，CE TML级别将跟踪FE的传输级别详细信息。注意，在此阶段，仅建立了传输级连接；使用发送/接收PL-TML接口进行部队级别关联（参考附录B.3和图8）。
Figure 7 shows an example of an FE shutting down the TML. It is assumed at this point that the ForCES Association Teardown has been issued by the CE. It should also be noted that different implementations may have different procedures for cleaning up state, etc.
图7显示了FE关闭TML的示例。在这一点上，假设CE已经发布了部队协会拆卸。还应该注意的是，不同的实现可能有不同的清除状态等过程。
When the FE PL issues a shutdown to its TML for a specific PL ID, the TML releases all the channel connections to the CE. This is achieved by closing the sockets used to communicate to the CE. This results in the stack sending a SCTP shutdown, which is received on the CE.
当FE PL针对特定PL ID向其TML发出关机时，TML将释放到CE的所有通道连接。这是通过关闭用于与CE通信的插座来实现的。这导致堆栈发送SCTP关闭，该关闭在CE上接收。
FE PL FE TML CE TML CE PL
| | | |
| Shutdown | | |
|----------->| | |
| |-disconnect 3 chans. | |
| |-SCTP level shutdown | |
| |------------------------>| |
| | | |
| | |TML detects shutdown|
| | |-FE TML info cleanup|
| | |-optionally tell PL |
| | |------------------->|
| | | |
| |- clean up any state of | |
| |-channels disconnected | |
| |<------------------------| |
| |-SCTP shutdown ACK | |
| | | |
| Shutdown | | |
| succeeded | | |
|<-----------| | |
| | | |
FE PL FE TML CE TML CE PL
| | | |
| Shutdown | | |
|----------->| | |
| |-disconnect 3 chans. | |
| |-SCTP level shutdown | |
| |------------------------>| |
| | | |
| | |TML detects shutdown|
| | |-FE TML info cleanup|
| | |-optionally tell PL |
| | |------------------->|
| | | |
| |- clean up any state of | |
| |-channels disconnected | |
| |<------------------------| |
| |-SCTP shutdown ACK | |
| | | |
| Shutdown | | |
| succeeded | | |
|<-----------| | |
| | | |
Figure 7: FE Shutting Down
图7：FE关闭
On the CE side, a TML disconnection would result in possible cleanup of the FE state. Optionally, depending on the implementation, there may be need to inform the PL about the TML disconnection. The CE-stack-level SCTP sends an acknowledgement to the FE TML in response to the earlier SCTP shutdown.
在CE端，TML断开可能导致FE状态的清除。或者，根据实现情况，可能需要通知PL TML断开。CE堆栈级SCTP向FE TML发送确认，以响应先前的SCTP停机。
The TML should be agnostic to the content of the PL messages, or their operations. The PL should provide enough information to the TML for it to assign an appropriate priority and loss behavior to the message. Figure 8 shows an example of a message exchange originated at the FE and sent to the CE (such as a ForCES association message), which illustrates all the necessary service interfaces for sending and receiving.
TML应该不知道PL消息的内容或它们的操作。PL应该向TML提供足够的信息，以便为消息分配适当的优先级和丢失行为。图8显示了一个源于FE并发送到CE的消息交换示例（如ForCES association消息），该示例说明了发送和接收所需的所有服务接口。
When the FE PL sends a message to the TML, the TML is expected to pick one of HP/MP/LP channels and send out the ForCES message.
FE PL向TML发送消息时，TML应选择一个HP/MP/LP通道并发送ForCES消息。
FE PL FE TML CE TML CE PL
| | | |
|PL send | | |
|----------->| | |
| | | |
| | | |
| |-pick channel | |
| |-TML Send | |
| |------------->| |
| | | |
| | |-TML Receive on chan. |
| | |- mux to PL/PL recv |
| | |--------------------->|
| | | ~
| | | ~ PL Process
| | | ~
| | | PL send |
| | |<---------------------|
| | |-pick chan to send on |
| | |-TML send |
| |<-------------| |
| |-TML Receive | |
| |-mux to PL | |
| PL Recv | | |
|<---------- | | |
| | | |
FE PL FE TML CE TML CE PL
| | | |
|PL send | | |
|----------->| | |
| | | |
| | | |
| |-pick channel | |
| |-TML Send | |
| |------------->| |
| | | |
| | |-TML Receive on chan. |
| | |- mux to PL/PL recv |
| | |--------------------->|
| | | ~
| | | ~ PL Process
| | | ~
| | | PL send |
| | |<---------------------|
| | |-pick chan to send on |
| | |-TML send |
| |<-------------| |
| |-TML Receive | |
| |-mux to PL | |
| PL Recv | | |
|<---------- | | |
| | | |
Figure 8: Send and Recv Flow
图8：发送和接收流
When the CE TML receives the ForCES message on the channel on which it was sent, it demultiplexes the message to the CE PL.
当CE TML在其发送的信道上接收到ForCES消息时，它将该消息解复用到CE PL。
The CE PL, after some processing (in this example, dealing with the FE's association), sends the TML the response. As in the case of FE PL, the CE TML picks the channel to send on before sending.
经过一些处理（在本例中，处理FE的关联）后，CE PL向TML发送响应。与FE PL的情况一样，CE TML在发送之前选择要发送的信道。
The processing of the ForCES message upon arrival at the FE TML and delivery to the FE PL is similar to the CE side equivalent as shown above in Appendix B.3.
到达FE TML并交付至FE PL时，ForCES信息的处理类似于上文附录B.3中所示的CE端等效信息。
Authors' Addresses
作者地址
Jamal Hadi Salim Mojatatu Networks Ottawa, Ontario Canada
加拿大安大略省渥太华Jamal Hadi Salim Mojatatu Networks
EMail: hadi@mojatatu.com
EMail: hadi@mojatatu.com
Kentaro Ogawa NTT Corporation 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
日本东京小川健太郎NTT公司3-9-11 Midori cho Musashino shi 180-8585
EMail: ogawa.kentaro@lab.ntt.co.jp
EMail: ogawa.kentaro@lab.ntt.co.jp