Network Working Group L. Yang
Request for Comments: 3746 Intel Corp.
Category: Informational R. Dantu
Univ. of North Texas
T. Anderson
Intel Corp.
R. Gopal
Nokia
April 2004
Network Working Group L. Yang
Request for Comments: 3746 Intel Corp.
Category: Informational R. Dantu
Univ. of North Texas
T. Anderson
Intel Corp.
R. Gopal
Nokia
April 2004
Forwarding and Control Element Separation (ForCES) Framework
转发和控制元素分离（ForCES）框架
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions.
本文件定义了部队（转发和控制元素分离）网络元素的架构框架，并确定了相关实体及其交互。
Table of Contents
目录
1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 2
1.2. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction to Forwarding and Control Element Separation
(ForCES) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Control Elements and Fr Reference Point . . . . . . . . . 10
3.2. Forwarding Elements and Fi reference point. . . . . . . . 11
3.3. CE Managers . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. FE Managers . . . . . . . . . . . . . . . . . . . . . . . 14
4. Operational Phases . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Pre-association Phase . . . . . . . . . . . . . . . . . . 15
4.1.1. Fl Reference Point . . . . . . . . . . . . . . . . 15
4.1.2. Ff Reference Point . . . . . . . . . . . . . . . . 16
4.1.3. Fc Reference Point . . . . . . . . . . . . . . . . 17
4.2. Post-association Phase and Fp reference point . . . . . . 17
4.2.1. Proximity and Interconnect between CEs and FEs . . 18
1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 2
1.2. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction to Forwarding and Control Element Separation
(ForCES) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Control Elements and Fr Reference Point . . . . . . . . . 10
3.2. Forwarding Elements and Fi reference point. . . . . . . . 11
3.3. CE Managers . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. FE Managers . . . . . . . . . . . . . . . . . . . . . . . 14
4. Operational Phases . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Pre-association Phase . . . . . . . . . . . . . . . . . . 15
4.1.1. Fl Reference Point . . . . . . . . . . . . . . . . 15
4.1.2. Ff Reference Point . . . . . . . . . . . . . . . . 16
4.1.3. Fc Reference Point . . . . . . . . . . . . . . . . 17
4.2. Post-association Phase and Fp reference point . . . . . . 17
4.2.1. Proximity and Interconnect between CEs and FEs . . 18
4.2.2. Association Establishment. . . . . . . . . . . . . 18
4.2.3. Steady-state Communication . . . . . . . . . . . . 19
4.2.4. Data Packets across Fp reference point . . . . . . 21
4.2.5. Proxy FE . . . . . . . . . . . . . . . . . . . . . 22
4.3. Association Re-establishment. . . . . . . . . . . . . . . 22
4.3.1. CE graceful restart. . . . . . . . . . . . . . . . 23
4.3.2. FE restart . . . . . . . . . . . . . . . . . . . . 24
5. Applicability to RFC 1812. . . . . . . . . . . . . . . . . . . 25
5.1. General Router Requirements . . . . . . . . . . . . . . . 25
5.2. Link Layer. . . . . . . . . . . . . . . . . . . . . . . . 26
5.3. Internet Layer Protocols. . . . . . . . . . . . . . . . . 27
5.4. Internet Layer Forwarding . . . . . . . . . . . . . . . . 27
5.5. Transport Layer . . . . . . . . . . . . . . . . . . . . . 28
5.6. Application Layer -- Routing Protocols. . . . . . . . . . 29
5.7. Application Layer -- Network Management Protocol. . . . . 29
6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 30
8.1. Analysis of Potential Threats Introduced by ForCES. . . . 31
8.1.1. "Join" or "Remove" Message Flooding on CEs . . . . 31
8.1.2. Impersonation Attack . . . . . . . . . . . . . . . 31
8.1.3. Replay Attack. . . . . . . . . . . . . . . . . . . 31
8.1.4. Attack during Fail Over. . . . . . . . . . . . . . 32
8.1.5. Data Integrity . . . . . . . . . . . . . . . . . . 32
8.1.6. Data Confidentiality . . . . . . . . . . . . . . . 32
8.1.7. Sharing security parameters. . . . . . . . . . . . 33
8.1.8. Denial of Service Attack via External Interface. . 33
8.2. Security Recommendations for ForCES . . . . . . . . . . . 33
8.2.1. Using TLS with ForCES. . . . . . . . . . . . . . . 34
8.2.2. Using IPsec with ForCES. . . . . . . . . . . . . . 35
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References. . . . . . . . . . . . . . . . . . . 37
9.2. Informative References. . . . . . . . . . . . . . . . . . 37
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 40
4.2.2. Association Establishment. . . . . . . . . . . . . 18
4.2.3. Steady-state Communication . . . . . . . . . . . . 19
4.2.4. Data Packets across Fp reference point . . . . . . 21
4.2.5. Proxy FE . . . . . . . . . . . . . . . . . . . . . 22
4.3. Association Re-establishment. . . . . . . . . . . . . . . 22
4.3.1. CE graceful restart. . . . . . . . . . . . . . . . 23
4.3.2. FE restart . . . . . . . . . . . . . . . . . . . . 24
5. Applicability to RFC 1812. . . . . . . . . . . . . . . . . . . 25
5.1. General Router Requirements . . . . . . . . . . . . . . . 25
5.2. Link Layer. . . . . . . . . . . . . . . . . . . . . . . . 26
5.3. Internet Layer Protocols. . . . . . . . . . . . . . . . . 27
5.4. Internet Layer Forwarding . . . . . . . . . . . . . . . . 27
5.5. Transport Layer . . . . . . . . . . . . . . . . . . . . . 28
5.6. Application Layer -- Routing Protocols. . . . . . . . . . 29
5.7. Application Layer -- Network Management Protocol. . . . . 29
6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 30
8.1. Analysis of Potential Threats Introduced by ForCES. . . . 31
8.1.1. "Join" or "Remove" Message Flooding on CEs . . . . 31
8.1.2. Impersonation Attack . . . . . . . . . . . . . . . 31
8.1.3. Replay Attack. . . . . . . . . . . . . . . . . . . 31
8.1.4. Attack during Fail Over. . . . . . . . . . . . . . 32
8.1.5. Data Integrity . . . . . . . . . . . . . . . . . . 32
8.1.6. Data Confidentiality . . . . . . . . . . . . . . . 32
8.1.7. Sharing security parameters. . . . . . . . . . . . 33
8.1.8. Denial of Service Attack via External Interface. . 33
8.2. Security Recommendations for ForCES . . . . . . . . . . . 33
8.2.1. Using TLS with ForCES. . . . . . . . . . . . . . . 34
8.2.2. Using IPsec with ForCES. . . . . . . . . . . . . . 35
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References. . . . . . . . . . . . . . . . . . . 37
9.2. Informative References. . . . . . . . . . . . . . . . . . 37
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 40
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 BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
A set of terminology associated with the ForCES requirements is defined in [4] and we only include the definitions that are most relevant to this document here.
[4]中定义了一组与部队要求相关的术语，我们在此仅包括与本文件最相关的定义。
Addressable Entity (AE) - An entity that is directly addressable given some interconnect technology. For example, on IP networks, it is a device to which we can communicate using an IP address; on a switch fabric, it is a device to which we can communicate using a switch fabric port number.
可寻址实体（AE）-给定某种互连技术可直接寻址的实体。例如，在IP网络上，它是我们可以使用IP地址与之通信的设备；在交换机结构上，它是一种我们可以使用交换机结构端口号与之通信的设备。
Physical Forwarding Element (PFE) - An AE that includes hardware used to provide per-packet processing and handling. This hardware may consist of (but is not limited to) network processors, ASICs (Application-Specific Integrated Circuits), or general purpose processors, installed on line cards, daughter boards, mezzanine cards, or in stand-alone boxes.
物理转发元件（PFE）-一种AE，包括用于提供每包处理和处理的硬件。该硬件可能包括（但不限于）网络处理器、ASIC（专用集成电路）或通用处理器，安装在线路卡、子板、夹层卡或独立机箱中。
PFE Partition - A logical partition of a PFE consisting of some subset of each of the resources (e.g., ports, memory, forwarding table entries) available on the PFE. This concept is analogous to that of the resources assigned to a virtual switching element as described in [9].
PFE分区-PFE的逻辑分区，由PFE上可用的每个资源（例如端口、内存、转发表项）的某些子集组成。此概念类似于分配给虚拟交换元件的资源，如[9]中所述。
Physical Control Element (PCE) - An AE that includes hardware used to provide control functionality. This hardware typically includes a general purpose processor.
物理控制元件（PCE）-包括用于提供控制功能的硬件的AE。该硬件通常包括一个通用处理器。
PCE Partition - A logical partition of a PCE consisting of some subset of each of the resources available on the PCE.
PCE分区-PCE的逻辑分区，由PCE上每个可用资源的某些子集组成。
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 by a CE via the ForCES Protocol. FEs may happen to be a single blade (or PFE), a partition of a PFE, or multiple PFEs.
转发元素（FE）-实现ForCES协议的逻辑实体。FEs使用底层硬件，按照CE通过ForCES协议的指示，提供每个数据包的处理和处理。FEs可能恰好是单个刀片（或PFE）、PFE的分区或多个PFE。
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. CEs may consist of PCE partitions or whole PCEs.
控制元素（CE）-实现强制协议的逻辑实体，并使用它指示一个或多个FEs如何处理数据包。CEs处理控制和信令协议的执行等功能。CE可以由PCE分区或整个PCE组成。
ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. An NE usually hides its internal organization from external entities and represents a single point of management to entities outside the NE.
强制网元（NE）-由一个或多个CE和一个或多个FEs组成的实体。网元通常对外部实体隐藏其内部组织，并表示对网元外部实体的单一管理点。
Pre-association Phase - The period of time during which an FE Manager (see below) and a CE Manager (see below) are determining whether an FE and a CE should be part of the same network element. It is possible for some elements of the NE to be in pre-association phase while other elements are in the post-association phase.
预关联阶段-FE管理器（见下文）和CE管理器（见下文）确定FE和CE是否应属于同一网元的时间段。网元的某些元素可能处于关联前阶段，而其他元素处于关联后阶段。
Post-association Phase - The period of time during which an FE knows which CE is to control it and vice versa, including the time during which the CE and FE are establishing communication with one another.
关联后阶段-FE知道哪个CE控制它的时间段，反之亦然，包括CE和FE彼此建立通信的时间段。
ForCES Protocol - While there may be multiple protocols used within the overall ForCES architecture, the term "ForCES Protocol" refers only to the ForCES post-association phase protocol (see below).
部队协议-虽然在整个部队体系结构中可能使用多个协议，但术语“部队协议”仅指部队关联后阶段协议（见下文）。
ForCES Post-Association Phase Protocol - The protocol used for post-association phase communication between CEs and FEs. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers. The ForCES Protocol is a master-slave protocol in which FEs are slaves and CEs are masters. This protocol includes both the management of the communication channel (e.g., connection establishment, heartbeats) and the control messages themselves. This protocol could be a single protocol or could consist of multiple protocols working together, and may be unicast or multicast based. A separate protocol document will specify this information.
强制关联后阶段协议-用于CEs和FEs之间关联后阶段通信的协议。本协议不适用于CE-to-CE通信、FE-to-FE通信或FE与CE经理之间的通信。ForCES协议是一种主从协议，其中FEs是从协议，ce是主协议。该协议包括通信信道的管理（例如，连接建立、心跳）和控制消息本身。该协议可以是单个协议，也可以由多个协议组成，可以是单播的，也可以是基于多播的。单独的协议文件将指定此信息。
FE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which CE(s) an FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. An FE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which CE(s) to use; however, this is currently out of scope. Being a logical entity, an FE manager might be physically combined with any of the other logical entities mentioned in this section.
FE管理器-在关联前阶段运行的逻辑实体，负责确定FE应与哪些CE通信。此过程称为CE发现，可能涉及FE经理学习可用CE的能力。FE经理可以使用从静态配置到预关联阶段协议（见下文）的任何方法来确定要使用的CE；然而，这目前超出了范围。作为一个逻辑实体，FE管理器可以与本节中提到的任何其他逻辑实体进行物理组合。
CE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which FE(s) a CE should communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs. A CE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which FE to use; however, this is currently out of scope. Being a logical entity, a CE manager might be physically combined with any of the other logical entities mentioned in this section.
CE管理器-在预关联阶段运行的逻辑实体，负责确定CE应与哪些FE通信。此过程称为FE发现，可能涉及CE经理了解可用FE的能力。CE管理器可以使用从静态配置到预关联阶段协议（见下文）的任何方法来确定使用哪个FE；然而，这目前超出了范围。作为一个逻辑实体，CE管理器可以与本节中提到的任何其他逻辑实体进行物理组合。
Pre-association Phase Protocol - A protocol between FE managers and CE managers that is used to determine which CEs or FEs to use. A pre-association phase protocol may include a CE and/or FE capability discovery mechanism. Note that this capability discovery process is wholly separate from (and does not replace) that used within the ForCES Protocol. However, the two capability discovery mechanisms may utilize the same FE model.
预关联阶段协议-FE管理器和CE管理器之间的协议，用于确定使用哪个CE或FEs。预关联阶段协议可包括CE和/或FE能力发现机制。请注意，此能力发现过程与ForCES协议中使用的能力发现过程完全分离（且不替换）。然而，两种能力发现机制可能使用相同的有限元模型。
FE Model - A model that describes the logical processing functions of an FE.
FE模型-描述FE逻辑处理功能的模型。
ForCES Protocol Element - An FE or CE.
强制协议元素-FE或CE。
Intra-FE topology - Representation of how a single FE is realized by combining possibly multiple logical functional blocks along multiple data paths. This is defined by the FE model.
内部FE拓扑-表示单个FE如何通过沿多条数据路径组合可能的多个逻辑功能块来实现。这是由有限元模型定义的。
FE Topology - Representation of how the multiple FEs in a single NE are interconnected. Sometimes it is called inter-FE topology, to be distinguished from intra-FE topology used by the FE model.
FE拓扑-表示单个网元中多个FE的互连方式。有时称为内部FE拓扑，以区别于FE模型使用的内部FE拓扑。
Inter-FE topology - See FE Topology.
内部FE拓扑-请参见FE拓扑。
An IP network element (NE) appears to external entities as a monolithic piece of network equipment, e.g., a router, NAT, firewall, or load balancer. Internally, however, an IP network element (NE) (such as a router) is composed of numerous logically separated entities that cooperate to provide a given functionality (such as routing). Two types of network element components exist: control element (CE) in control plane and forwarding element (FE) in forwarding plane (or data plane). Forwarding elements are typically ASIC, network-processor, or general-purpose processor-based devices that handle data path operations for each packet. Control elements are typically based on general-purpose processors that provide control functionality, like routing and signaling protocols.
IP网元（NE）在外部实体看来是网络设备的一个整体，例如路由器、NAT、防火墙或负载平衡器。然而，在内部，IP网元（例如路由器）由许多逻辑上分离的实体组成，这些实体相互协作以提供给定的功能（例如路由）。存在两种类型的网元组件：控制平面中的控制元素（CE）和转发平面（或数据平面）中的转发元素（FE）。转发元件通常是ASIC、网络处理器或基于通用处理器的设备，用于处理每个分组的数据路径操作。控制元件通常基于提供控制功能的通用处理器，如路由和信令协议。
ForCES aims to define a framework and associated protocol(s) to standardize information exchange between the control and forwarding plane. Having standard mechanisms allows CEs and FEs to become physically separated standard components. This physical separation accrues several benefits to the ForCES architecture. Separate components would allow component vendors to specialize in one component without having to become experts in all components. Standard protocol also allows the CEs and FEs from different component vendors to interoperate with each other and hence it becomes possible for system vendors to integrate together the CEs and
ForCES旨在定义一个框架和相关协议，以标准化控制和转发平面之间的信息交换。有了标准机制，CEs和FEs可以成为物理上分离的标准组件。这种物理分离为部队体系结构带来了一些好处。单独的组件将允许组件供应商专注于一个组件，而不必成为所有组件的专家。标准协议还允许来自不同组件供应商的CEs和FEs彼此互操作，因此系统供应商可以将CEs和FEs集成在一起
FEs from different component suppliers. This interoperability translates into increased design choices and flexibility for the system vendors. Overall, ForCES will enable rapid innovation in both the control and forwarding planes while maintaining interoperability. Scalability is also easily provided by this architecture in that additional forwarding or control capacity can be added to existing network elements without the need for forklift upgrades.
来自不同部件供应商的FEs。这种互操作性为系统供应商带来了更多的设计选择和灵活性。总体而言，部队将在保持互操作性的同时，在控制和转发飞机上实现快速创新。这种体系结构还可以很容易地提供可扩展性，因为可以向现有网络元素添加额外的转发或控制能力，而无需升级。
------------------------- -------------------------
| Control Blade A | | Control Blade B |
| (CE) | | (CE) |
------------------------- -------------------------
^ | ^ |
| | | |
| V | V
---------------------------------------------------------
| Switch Fabric Backplane |
---------------------------------------------------------
^ | ^ | ^ |
| | | | . . . | |
| V | V | V
------------ ------------ ------------
|Router | |Router | |Router |
|Blade #1 | |Blade #2 | |Blade #N |
| (FE) | | (FE) | | (FE) |
------------ ------------ ------------
^ | ^ | ^ |
| | | | . . . | |
| V | V | V
------------------------- -------------------------
| Control Blade A | | Control Blade B |
| (CE) | | (CE) |
------------------------- -------------------------
^ | ^ |
| | | |
| V | V
---------------------------------------------------------
| Switch Fabric Backplane |
---------------------------------------------------------
^ | ^ | ^ |
| | | | . . . | |
| V | V | V
------------ ------------ ------------
|Router | |Router | |Router |
|Blade #1 | |Blade #2 | |Blade #N |
| (FE) | | (FE) | | (FE) |
------------ ------------ ------------
^ | ^ | ^ |
| | | | . . . | |
| V | V | V
Figure 1. A router configuration example with separate blades.
图1。具有独立刀片的路由器配置示例。
One example of such physical separation is at the blade level. Figure 1 shows such an example configuration of a router, with two control blades and multiple forwarding blades, all interconnected into a switch fabric backplane. In such a chassis configuration, the control blades are the CEs while the router blades are the FEs, and the switch fabric backplane provides the physical interconnect for all the blades. Control blade A may be the primary CE while control blade B may be the backup CE providing redundancy. It is also possible to have a redundant switch fabric for high availability support. Routers today with this kind of configuration use proprietary interfaces for messaging between CEs and FEs. The goal of ForCES is to replace such proprietary interfaces with a standard protocol. With a standard protocol like ForCES implemented on all blades, it becomes possible for control blades from vendor X and forwarding blades from vendor Y to work seamlessly together in one chassis.
这种物理分离的一个例子是在叶片级别。图1显示了路由器的这种示例配置，其中有两个控制刀片和多个转发刀片，它们都互连到交换机结构背板中。在这种机箱配置中，控制刀片是CEs，而路由器刀片是FEs，交换机结构背板为所有刀片提供物理互连。控制刀片A可以是主CE，而控制刀片B可以是提供冗余的备份CE。还可以使用冗余交换机结构来支持高可用性。如今，采用这种配置的路由器使用专有接口在CEs和FEs之间进行消息传递。ForCES的目标是用标准协议替换此类专有接口。通过在所有刀片服务器上实施标准协议（如强制），供应商X的控制刀片服务器和供应商Y的转发刀片服务器可以在一个机箱中无缝协作。
------- -------
| CE1 | | CE2 |
------- -------
^ ^
| |
V V
============================================ Ethernet
^ ^ . . . ^
| | |
V V V
------- ------- --------
| FE#1| | FE#2| | FE#n |
------- ------- --------
^ | ^ | ^ |
| | | | | |
| V | V | V
------- -------
| CE1 | | CE2 |
------- -------
^ ^
| |
V V
============================================ Ethernet
^ ^ . . . ^
| | |
V V V
------- ------- --------
| FE#1| | FE#2| | FE#n |
------- ------- --------
^ | ^ | ^ |
| | | | | |
| V | V | V
Figure 2. A router configuration example with separate boxes.
图2。一个路由器配置示例，带有单独的框。
Another level of physical separation between the CEs and FEs can be at the box level. In such a configuration, all the CEs and FEs are physically separated boxes, interconnected with some kind of high speed LAN connection (like Gigabit Ethernet). These separated CEs and FEs are only one hop away from each other within a local area network. The CEs and FEs communicate to each other by running ForCES, and the collection of these CEs and FEs together become one routing unit to the external world. Figure 2 shows such an example.
CEs和FEs之间的另一个物理分离级别可以是盒子级别。在这种配置中，所有的CEs和FEs都是物理上分开的盒子，通过某种高速LAN连接（如千兆以太网）互连。在局域网内，这些分离的ce和FEs彼此之间仅相隔一跳。CEs和FEs通过运行力相互通信，这些CEs和FEs的集合成为外部世界的一个路由单元。图2显示了这样一个示例。
In both examples shown here, the same physical interconnect is used for both CE-to-FE and FE-to-FE communication. However, that does not have to be the case. One reason to use different interconnects is that the CE-to-FE interconnect does not have to be as fast as the FE-to-FE interconnect, so the more faster and more expensive connections can be saved for FE-to-FE. The separate interconnects may also provide reliability and redundancy benefits for the NE.
在这里显示的两个示例中，相同的物理互连用于CE到FE和FE到FE通信。然而，情况并非如此。使用不同互连的一个原因是CE-to-FE互连不必像FE-to-FE互连那样快，因此可以为FE-to-FE节省更快、更昂贵的连接。独立互连还可以为网元提供可靠性和冗余优势。
Some examples of control functions that can be implemented in the CE include routing protocols like RIP, OSPF, and BGP, control and signaling protocols like RSVP (Resource Reservation Protocol), LDP (Label Distribution Protocol) for MPLS, etc. Examples of forwarding functions in the FE include LPM (longest prefix match) forwarder, classifiers, traffic shaper, meter, NAT (Network Address Translators), etc. Figure 3 provides example functions in both CE and FE. Any given NE may contain one or many of these CE and FE functions in it. The diagram also shows that the ForCES Protocol is used to transport both the control messages for ForCES itself and the
可在CE中实现的控制功能的一些示例包括诸如RIP、OSPF和BGP的路由协议、诸如RSVP（资源保留协议）、用于MPLS的LDP（标签分发协议）等的控制和信令协议。FE中的转发功能的示例包括LPM（最长前缀匹配）转发器、分类器、以及，流量整形器、计量器、NAT（网络地址转换器）等。图3提供了CE和FE中的示例功能。任何给定的NE中可能包含一个或多个CE和FE函数。该图还显示了ForCES协议用于传输ForCES自身和服务器的控制消息
data packets that are originated/destined from/to the control functions in the CE (e.g., routing packets). Section 4.2.4 provides more detail on this.
从CE中的控制功能发起/发往CE中的控制功能的数据分组（例如，路由分组）。第4.2.4节对此进行了详细说明。
-------------------------------------------------
| | | | | | |
|OSPF |RIP |BGP |RSVP |LDP |. . . |
| | | | | | |
-------------------------------------------------
| ForCES Interface |
-------------------------------------------------
^ ^
ForCES | |data
control | |packets
messages| |(e.g., routing packets)
v v
-------------------------------------------------
| ForCES Interface |
-------------------------------------------------
| | | | | | |
|LPM Fwd|Meter |Shaper |NAT |Classi-|. . . |
| | | | |fier | |
-------------------------------------------------
| FE resources |
-------------------------------------------------
-------------------------------------------------
| | | | | | |
|OSPF |RIP |BGP |RSVP |LDP |. . . |
| | | | | | |
-------------------------------------------------
| ForCES Interface |
-------------------------------------------------
^ ^
ForCES | |data
control | |packets
messages| |(e.g., routing packets)
v v
-------------------------------------------------
| ForCES Interface |
-------------------------------------------------
| | | | | | |
|LPM Fwd|Meter |Shaper |NAT |Classi-|. . . |
| | | | |fier | |
-------------------------------------------------
| FE resources |
-------------------------------------------------
Figure 3. Examples of CE and FE functions.
图3。CE和FE函数的示例。
A set of requirements for control and forwarding separation is identified in [4]. This document describes a ForCES architecture that satisfies the architectural requirements of [4] and defines a framework for ForCES network elements and the associated entities to facilitate protocol definition. Whenever necessary, this document uses many examples to illustrate the issues and/or possible solutions in ForCES. These examples are intended to be just examples, and should not be taken as the only or definite ways of doing certain things. It is expected that a separate document will be produced by the ForCES working group to specify the ForCES Protocol.
[4]中确定了控制和转发分离的一组要求。本文件描述了满足[4]体系结构要求的部队体系结构，并定义了部队网络元素和相关实体的框架，以便于协议定义。必要时，本文件使用许多示例来说明部队中的问题和/或可能的解决方案。这些例子只是例子，不应该被视为做某些事情的唯一或明确的方式。预计部队工作组将编制一份单独的文件，具体说明部队议定书。
This section defines the ForCES architectural framework and the associated logical components. This ForCES framework defines components of ForCES NEs, including several ancillary components. These components may be connected in different kinds of topologies for flexible packet processing.
本节定义了ForCES体系结构框架和相关逻辑组件。该部队框架定义了部队的组成部分，包括若干辅助组成部分。这些组件可以以不同类型的拓扑连接，以实现灵活的分组处理。
---------------------------------------
| ForCES Network Element |
-------------- Fc | -------------- -------------- |
| CE Manager |---------+-| CE 1 |------| CE 2 | |
-------------- | | | Fr | | |
| | -------------- -------------- |
| Fl | | | Fp / |
| | Fp| |----------| / |
| | | |/ |
| | | | |
| | | Fp /|----| |
| | | /--------/ | |
-------------- Ff | -------------- -------------- |
| FE Manager |---------+-| FE 1 | Fi | FE 2 | |
-------------- | | |------| | |
| -------------- -------------- |
| | | | | | | | | |
----+--+--+--+----------+--+--+--+-----
| | | | | | | |
| | | | | | | |
Fi/f Fi/f
---------------------------------------
| ForCES Network Element |
-------------- Fc | -------------- -------------- |
| CE Manager |---------+-| CE 1 |------| CE 2 | |
-------------- | | | Fr | | |
| | -------------- -------------- |
| Fl | | | Fp / |
| | Fp| |----------| / |
| | | |/ |
| | | | |
| | | Fp /|----| |
| | | /--------/ | |
-------------- Ff | -------------- -------------- |
| FE Manager |---------+-| FE 1 | Fi | FE 2 | |
-------------- | | |------| | |
| -------------- -------------- |
| | | | | | | | | |
----+--+--+--+----------+--+--+--+-----
| | | | | | | |
| | | | | | | |
Fi/f Fi/f
Fp: CE-FE interface Fi: FE-FE interface Fr: CE-CE interface Fc: Interface between the CE Manager and a CE Ff: Interface between the FE Manager and an FE Fl: Interface between the CE Manager and the FE Manager Fi/f: FE external interface
Fp:CE-FE接口Fi:FE-FE接口Fr:CE-CE接口Fc:CE管理器和CE Ff之间的接口：FE管理器和FE Fl之间的接口：CE管理器和FE管理器之间的接口Fi/f:FE外部接口
Figure 4. ForCES Architectural Diagram
图4。部队架构图
The diagram in Figure 4 shows the logical components of the ForCES architecture and their relationships. There are two kinds of components inside a ForCES network element: control element (CE) and forwarding element (FE). The framework allows multiple instances of CE and FE inside one NE. Each FE contains one or more physical media interfaces for receiving and transmitting packets from/to the external world. The aggregation of these FE interfaces becomes the NE's external interfaces. In addition to the external interfaces, there must also exist some kind of interconnect within the NE so that the CE and FE can communicate with each other, and one FE can forward packets to another FE. The diagram also shows two entities outside of the ForCES NE: CE Manager and FE Manager. These two ancillary entities provide configuration to the corresponding CE or FE in the pre-association phase (see Section 4.1).
图4中的图表显示了ForCES架构的逻辑组件及其关系。ForCES网元中有两种组件：控制元素（CE）和转发元素（FE）。该框架允许在一个网元内有多个CE和FE实例。每个FE包含一个或多个物理媒体接口，用于从外部世界接收和发送数据包。这些FE接口的聚合成为网元的外部接口。除了外部接口之外，网元内还必须存在某种互连，以便CE和FE可以彼此通信，并且一个FE可以将数据包转发给另一个FE。该图还显示了ForCES NE之外的两个实体：CE Manager和FE Manager。这两个辅助实体在关联前阶段为相应的CE或FE提供配置（见第4.1节）。
For convenience, the logical interactions between these components are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi, as shown in Figure 4. The FE external interfaces are labeled as Fi/f. More detail is provided in Section 3 and 4 for each of these reference points. All these reference points are important in understanding the ForCES architecture, however, the ForCES Protocol is only defined over one reference point -- Fp.
为方便起见，这些组件之间的逻辑交互通过参考点Fp、Fc、Ff、Fr、Fl和Fi进行标记，如图4所示。FE外部接口标记为Fi/f。第3节和第4节提供了每个参考点的更多细节。所有这些参考点对于理解ForCES体系结构都很重要，但是，ForCES协议仅在一个参考点（Fp）上定义。
The interface between two ForCES NEs is identical to the interface between two conventional routers and these two NEs exchange the protocol packets through the external interfaces at Fi/f. ForCES NEs connect to existing routers transparently.
两个网元之间的接口与两个常规路由器之间的接口相同，这两个网元通过Fi/f的外部接口交换协议包。强制网元透明地连接到现有路由器。
It is not necessary to define any protocols across the Fr reference point to enable control and forwarding separation for simple configurations like single CE and multiple FEs. However, this architecture permits multiple CEs to be present in a network element. In cases where an implementation uses multiple CEs, the invariant that the CEs and FEs together appear as a single NE must be maintained.
没有必要跨Fr参考点定义任何协议，以便为简单配置（如单个CE和多个FEs）实现控制和转发分离。然而，该架构允许在网络元件中存在多个ce。在实现使用多个CE的情况下，必须保持CEs和FEs一起显示为单个网元的不变。
Multiple CEs may be used for redundancy, load sharing, distributed control, or other purposes. Redundancy is the case where one or more CEs are prepared to take over should an active CE fail. Load sharing is the case where two or more CEs are concurrently active and any request that can be serviced by one of the CEs can also be serviced by any of the other CEs. For both redundancy and load sharing, the CEs involved are equivalently capable. The only difference between these two cases is in terms of how many active CEs there are simultaneously. Distributed control is the case where two or more CEs are concurrently active but certain requests can only be serviced by certain CEs.
多个CE可用于冗余、负载共享、分布式控制或其他目的。冗余是一个或多个CE准备在活动CE出现故障时接管的情况。负载共享是指两个或多个ce同时处于活动状态，并且可以由其中一个ce服务的任何请求也可以由任何其他ce服务的情况。对于冗余和负载共享，涉及的CE具有同等能力。这两种情况之间的唯一区别在于同时有多少个活动CE。分布式控制是指两个或多个CE同时处于活动状态，但某些请求只能由某些CE提供服务的情况。
When multiple CEs are employed in a ForCES NE, their internal organization is considered an implementation issue that is beyond the scope of ForCES. CEs are wholly responsible for coordinating amongst themselves via the Fr reference point to provide consistency and synchronization. However, ForCES does not define the implementation or protocols used between CEs, nor does it define how to distribute functionality among CEs. Nevertheless, ForCES will support mechanisms for CE redundancy or fail over, and it is expected that vendors will provide redundancy or fail over solutions within this framework.
当一个部队NE中使用多个CE时，其内部组织被认为是一个实施问题，超出了部队的范围。CEs完全负责通过Fr参考点相互协调，以提供一致性和同步性。然而，ForCES没有定义CE之间使用的实现或协议，也没有定义如何在CE之间分配功能。然而，ForCES将支持CE冗余或故障转移机制，预计供应商将在此框架内提供冗余或故障转移解决方案。
An FE is a logical entity that implements the ForCES Protocol and uses the underlying hardware to provide per-packet processing and handling as directed by a CE. It is possible to partition one physical FE into multiple logical FEs. It is also possible for one FE to use multiple physical FEs. The mapping between physical FE(s) and logical FE(s) is beyond the scope of ForCES. For example, a logical partition of a physical FE can be created by assigning some portion of each of the resources (e.g., ports, memory, forwarding table entries) available on the ForCES physical FE to each of the logical FEs. Such a concept of FE virtualization is analogous to a virtual switching element as described in [9]. If FE virtualization occurs only in the pre-association phase, it has no impact on ForCES. However, if FE virtualization results in a resource change taken from an existing FE (already participating in ForCES post-association phase), the ForCES Protocol needs to be able to inform the CE of such a change via asynchronous messages (see [4], Section 5, requirement #6).
FE是一个逻辑实体，它实现ForCES协议，并使用底层硬件按照CE的指示提供每个数据包的处理和处理。可以将一个物理FE划分为多个逻辑FE。一个FE也可以使用多个物理FE。物理FE和逻辑FE之间的映射超出了力的范围。例如，可以通过将物理FE上可用的每个资源（例如，端口、内存、转发表条目）的某些部分分配给每个逻辑FE来创建物理FE的逻辑分区。FE虚拟化的这种概念类似于[9]中所述的虚拟交换元件。如果FE虚拟化仅发生在关联前阶段，则不会对部队产生影响。但是，如果FE虚拟化导致从现有FE（已参与部队后关联阶段）获取资源更改，则部队协议需要能够通过异步消息通知CE此类更改（请参见[4]，第5节，需求#6）。
FEs perform all packet processing functions as directed by CEs. FEs have no initiative of their own. Instead, FEs are slaves and only do as they are told. FEs may communicate with one or more CEs concurrently across reference point Fp. FEs have no notion of CE redundancy, load sharing, or distributed control. Instead, FEs accept commands from any CE authorized to control them, and it is up to the CEs to coordinate among themselves to achieve redundancy, load sharing, or distributed control. The idea is to keep FEs as simple and dumb as possible so that FEs can focus their resources on the packet processing functions. Unless otherwise configured or determined by a ForCEs Protocol exchange, each FE will process authorized incoming commands directed at it as it receives them on a first come first serve basis.
FEs按照CEs的指示执行所有数据包处理功能。联邦政府没有自己的主动权。相反，非政府组织是奴隶，他们只会按命令行事。FEs可跨参考点Fp与一个或多个CE并发通信。FEs没有CE冗余、负载共享或分布式控制的概念。相反，FEs接受来自授权控制它们的任何CE的命令，由CE相互协调以实现冗余、负载共享或分布式控制。这样做的目的是使FEs尽可能简单和愚蠢，以便FEs可以将资源集中在数据包处理功能上。除非ForCEs协议交换另有配置或确定，否则每个FE将在接收到授权传入命令时，以先到先得的方式处理直接向其发出的命令。
For example, in Figure 5, FE1 and FE2 can be configured to accept commands from both the primary CE (CE1) and the backup CE (CE2). Upon detection of CE1 failure, perhaps across the Fr or Fp reference point, CE2 is configured to take over activities of CE1. This is beyond the scope of ForCES and is not discussed further.
例如，在图5中，可以将FE1和FE2配置为接受来自主CE（CE1）和备份CE（CE2）的命令。在检测到CE1故障时，可能在Fr或Fp参考点上，CE2被配置为接管CE1的活动。这超出了力的范围，不再进一步讨论。
Distributed control can be achieved in a similar fashion, without much intelligence on the part of FEs. For example, FEs can be configured to detect RSVP and BGP protocol packets, and forward RSVP packets to one CE and BGP packets to another CE. Hence, FEs may need to do packet filtering for forwarding packets to specific CEs.
分布式控制也可以以类似的方式实现，FEs没有多少智能。例如，FEs可被配置为检测RSVP和BGP协议分组，并将RSVP分组转发给一个CE，将BGP分组转发给另一个CE。因此，FEs可能需要进行分组过滤以将分组转发到特定ce。
------- Fr -------
| CE1 | ------| CE2 |
------- -------
| \ / |
| \ / |
| \ / |
| \/Fp |
| /\ |
| / \ |
| / \ |
------- Fi -------
| FE1 |<----->| FE2 |
------- -------
------- Fr -------
| CE1 | ------| CE2 |
------- -------
| \ / |
| \ / |
| \ / |
| \/Fp |
| /\ |
| / \ |
| / \ |
------- Fi -------
| FE1 |<----->| FE2 |
------- -------
Figure 5. CE redundancy example.
图5。CE冗余示例。
This architecture permits multiple FEs to be present in an NE. [4] dictates that the ForCES Protocol must be able to scale to at least hundreds of FEs (see [4] Section 5, requirement #11). Each of these FEs may potentially have a different set of packet processing functions, with different media interfaces. FEs are responsible for basic maintenance of layer-2 connectivity with other FEs and with external entities. Many layer-2 media include sophisticated control protocols. The FORCES Protocol (over the Fp reference point) will be able to carry messages for such protocols so that, in keeping with the dumb FE model, the CE can provide appropriate intelligence and control over these media.
该架构允许在一个网元中存在多个FEs。[4] 规定部队协议必须能够扩展到至少数百个FE（见[4]第5节，要求11）。这些FEs中的每一个可能具有具有不同媒体接口的不同分组处理功能集。FEs负责与其他FEs和外部实体的第2层连接的基本维护。许多第二层介质包括复杂的控制协议。FORCES协议（通过Fp参考点）将能够承载此类协议的消息，以便CE能够根据dumb FE模型对这些媒体提供适当的情报和控制。
When multiple FEs are present, ForCES requires that packets must be able to arrive at the NE by one FE and leave the NE via a different FE (See [4], Section 5, Requirement #3). Packets that enter the NE via one FE and leave the NE via a different FE are transferred between FEs across the Fi reference point. The Fi reference point could be used by FEs to discover their (inter-FE) topology, perhaps during the pre-association phase. The Fi reference point is a separate protocol from the Fp reference point and is not currently defined by the ForCES Protocol.
当存在多个FE时，ForCES要求数据包必须能够通过一个FE到达网元，并通过不同的FE离开网元（参见[4]，第5节，要求#3）。通过一个FE进入网元并通过另一个FE离开网元的数据包通过Fi参考点在各FE之间传输。可能在预关联阶段，FEs可以使用Fi参考点来发现其（FE间）拓扑。Fi参考点是一个独立于Fp参考点的协议，目前未由ForCES协议定义。
FEs could be connected in different kinds of topologies and packet processing may spread across several FEs in the topology. Hence, logical packet flow may be different from physical FE topology. Figure 6 provides some topology examples. When it is necessary to forward packets between FEs, the CE needs to understand the FE topology. The FE topology may be queried from the FEs by the CEs via the ForCES Protocol, but the FEs are not required to provide that information to the CEs. So, the FE topology information may also be gathered by other means outside of the ForCES Protocol (like inter-FE topology discovery protocol).
FEs可以以不同类型的拓扑连接，并且数据包处理可以跨拓扑中的多个FEs进行。因此，逻辑分组流可能不同于物理FE拓扑。图6提供了一些拓扑示例。当需要在FEs之间转发数据包时，CE需要了解FE拓扑。FE拓扑可由CEs通过ForCES协议从FEs查询，但FEs无需向CEs提供该信息。因此，FE拓扑信息也可以通过ForCES协议之外的其他方式收集（如FE拓扑发现协议）。
-----------------
| CE |
-----------------
^ ^ ^
/ | \
/ v \
/ ------- \
/ +->| FE3 |<-+ \
/ | | | | \
v | ------- | v
------- | | -------
| FE1 |<-+ +->| FE2 |
| |<--------------->| |
------- -------
^ | ^ |
| | | |
| v | v
-----------------
| CE |
-----------------
^ ^ ^
/ | \
/ v \
/ ------- \
/ +->| FE3 |<-+ \
/ | | | | \
v | ------- | v
------- | | -------
| FE1 |<-+ +->| FE2 |
| |<--------------->| |
------- -------
^ | ^ |
| | | |
| v | v
(a) Full mesh among FE1, FE2, and FE3
(a) FE1、FE2和FE3之间的完整网格
-----------
| CE |
-----------
^ ^ ^ ^
/ | | \
/------ | | ------\
v v v v
------- ------- ------- -------
| FE1 |<->| FE2 |<->| FE3 |<->| FE4 |
------- ------- ------- -------
^ | ^ | ^ | ^ |
| | | | | | | |
| v | v | v | v
-----------
| CE |
-----------
^ ^ ^ ^
/ | | \
/------ | | ------\
v v v v
------- ------- ------- -------
| FE1 |<->| FE2 |<->| FE3 |<->| FE4 |
------- ------- ------- -------
^ | ^ | ^ | ^ |
| | | | | | | |
| v | v | v | v
(b) Multiple FEs in a daisy chain
(b) 菊花链中的多个FEs
^ |
| v
-----------
| FE1 |<-----------------------|
----------- |
^ ^ |
/ \ |
| ^ / \ ^ | V
v | v v | v ----------
--------- --------- | |
| FE2 | | FE3 |<------------>| CE |
--------- --------- | |
^ ^ ^ ----------
| \ / ^ ^
| \ / | |
| v v | |
| ----------- | |
| | FE4 |<----------------------| |
| ----------- |
| | ^ |
| v | |
| |
|----------------------------------------|
^ |
| v
-----------
| FE1 |<-----------------------|
----------- |
^ ^ |
/ \ |
| ^ / \ ^ | V
v | v v | v ----------
--------- --------- | |
| FE2 | | FE3 |<------------>| CE |
--------- --------- | |
^ ^ ^ ----------
| \ / ^ ^
| \ / | |
| v v | |
| ----------- | |
| | FE4 |<----------------------| |
| ----------- |
| | ^ |
| v | |
| |
|----------------------------------------|
(c) Multiple FEs connected by a ring
(c) 由环连接的多个FEs
Figure 6. Some examples of FE topology
图6。有限元拓扑的几个例子
CE managers are responsible for determining which FEs a CE should control. It is legitimate for CE managers to be hard-coded with the knowledge of with which FEs its CEs should communicate with. A CE manager may also be physically embedded into a CE and be implemented as a simple keypad or other direct configuration mechanism on the CE. Finally, CE managers may be physically and logically separate entities that configure the CE with FE information via such mechanisms as COPS-PR [7] or SNMP [5].
首席执行官经理负责确定首席执行官应控制哪些FEs。对于CE经理来说，硬编码了解其CE应与哪些FEs沟通是合理的。CE管理器还可以物理地嵌入到CE中，并且被实现为CE上的简单键盘或其他直接配置机制。最后，CE管理器可以是物理上和逻辑上独立的实体，通过诸如COPS-PR[7]或SNMP[5]等机制使用FE信息配置CE。
FE managers are responsible for determining with which CE any particular FE should initially communicate. Like CE managers, no restrictions are placed on how an FE manager decides with which CE its FEs should communicate, nor are restrictions placed on how FE managers are implemented. Each FE should have one and only one FE
FE经理负责确定任何特定FE最初应与哪个CE沟通。与CE经理一样，对于FE经理如何决定其FEs应与哪个CE沟通，也没有任何限制，对于FE经理如何实施也没有任何限制。每个FE应具有且仅具有一个FE
manager, while different FEs may have the same or different FE manager(s). Each manager can choose to exist and operate independently of other manager.
经理，而不同的FE可能具有相同或不同的FE经理。每个管理者都可以选择独立于其他管理者生存和运作。
Both FEs and CEs require some configuration to be in place before they can start information exchange and function as a coherent network element. Two operational phases are identified in this framework: pre-association and post-association.
FEs和CEs都需要一些配置到位，然后才能开始信息交换，并作为一个连贯的网元发挥作用。该框架确定了两个操作阶段：关联前和关联后。
The Pre-association phase is the period of time during which an FE Manager and a CE Manager are determining whether an FE and a CE should be part of the same network element. The protocols used during this phase may include all or some of the message exchange over Fl, Ff, and Fc reference points. However, all these may be optional and none of this is within the scope of the ForCES Protocol.
预关联阶段是FE管理器和CE管理器确定FE和CE是否应属于同一网元的时间段。此阶段使用的协议可能包括Fl、Ff和Fc参考点上的全部或部分消息交换。然而，所有这些都可能是可选的，并且所有这些都不在《部队议定书》的范围之内。
CE managers and FE managers may communicate across the Fl reference point in the pre-association phase in order to determine whether an individual CE and FE, or a set of CEs and FEs should be associated. Communication across the Fl reference point is optional in this architecture. No requirements are placed on this reference point.
CE经理和FE经理可在关联前阶段通过Fl参考点进行沟通，以确定是否应关联单个CE和FE或一组CE和FE。在该架构中，通过Fl参考点的通信是可选的。没有对该参考点提出任何要求。
CE managers and FE managers may be operated by different entities. The operator of the CE manager may not want to divulge, except to specified FE managers, any characteristics of the CEs it manages. Similarly, the operator of the FE manager may not want to divulge FE characteristics, except to authorized entities. As such, CE managers and FE managers may need to authenticate one another. Subsequent communication between CE managers and FE managers may require other security functions such as privacy, non-repudiation, freshness, and integrity.
CE经理和FE经理可能由不同的实体运营。CE经理的运营商可能不想透露其管理的CE的任何特征，但向指定FE经理透露的除外。类似地，FE经理的操作员可能不想泄露FE特征，但授权实体除外。因此，CE经理和FE经理可能需要相互验证。CE经理和FE经理之间的后续通信可能需要其他安全功能，如隐私、不可否认性、新鲜度和完整性。
FE Manager FE CE Manager CE
| | | |
| | | |
|(security exchange) | |
1|<------------------------------>| |
| | | |
|(a list of CEs and their attributes) |
2|<-------------------------------| |
| | | |
|(a list of FEs and their attributes) |
3|------------------------------->| |
| | | |
| | | |
|<----------------Fl------------>| |
FE Manager FE CE Manager CE
| | | |
| | | |
|(security exchange) | |
1|<------------------------------>| |
| | | |
|(a list of CEs and their attributes) |
2|<-------------------------------| |
| | | |
|(a list of FEs and their attributes) |
3|------------------------------->| |
| | | |
| | | |
|<----------------Fl------------>| |
Figure 7. An example of a message exchange over the Fl reference point
图7。Fl参考点上的消息交换示例
Once the necessary security functions have been performed, the CE and FE managers communicate to determine which CEs and FEs should communicate with each other. At the very minimum, the CE and FE managers need to learn of the existence of available FEs and CEs respectively. This discovery process may entail one or both managers learning the capabilities of the discovered ForCES protocol elements. Figure 7 shows an example of a possible message exchange between the CE manager and FE manager over the Fl reference point.
一旦执行了必要的安全功能，CE和FE经理将进行通信，以确定哪些CE和FE应相互通信。CE和FE经理至少需要分别了解可用FE和CE的存在。该发现过程可能需要一名或两名管理人员学习发现的部队协议元素的能力。图7显示了CE管理器和FE管理器之间通过Fl参考点可能进行的消息交换示例。
The Ff reference point is used to inform forwarding elements of the association decisions made by the FE manager in the pre-association phase. Only authorized entities may instruct an FE with respect to which CE should control it. Therefore, privacy, integrity, freshness, and authentication are necessary between the FE manager and FEs when the FE manager is remote to the FE. Once the appropriate security has been established, the FE manager instructs the FEs across this reference point to join a new NE or to disconnect from an existing NE. The FE Manager could also assign unique FE identifiers to the FEs using this reference point. The FE identifiers are useful in the post association phase to express FE topology. Figure 8 shows example of a message exchange over the Ff reference point.
Ff参考点用于通知转发元素FE经理在关联前阶段做出的关联决策。只有经授权的实体才可以向FE发出CE应控制的指令。因此，当FE manager距离FE较远时，FE manager和FEs之间需要隐私、完整性、新鲜度和身份验证。一旦建立了适当的安全性，FE经理将指示该参考点上的FE加入新的网元或断开与现有网元的连接。FE管理器还可以使用该参考点为FEs分配唯一的FE标识符。FE标识符在关联后阶段用于表示FE拓扑。图8显示了Ff参考点上的消息交换示例。
FE Manager FE CE Manager CE
| | | |
| | | |
|(security exchange) |(security exchange)
1|<------------>|authentication 1|<----------->|authentication
| | | |
|(FE ID, attributes) |(CE ID, attributes)
2|<-------------|request 2|<------------|request
| | | |
3|------------->|response 3|------------>|response
|(corresponding CE ID) |(corresponding FE ID)
| | | |
| | | |
|<-----Ff----->| |<-----Fc---->|
FE Manager FE CE Manager CE
| | | |
| | | |
|(security exchange) |(security exchange)
1|<------------>|authentication 1|<----------->|authentication
| | | |
|(FE ID, attributes) |(CE ID, attributes)
2|<-------------|request 2|<------------|request
| | | |
3|------------->|response 3|------------>|response
|(corresponding CE ID) |(corresponding FE ID)
| | | |
| | | |
|<-----Ff----->| |<-----Fc---->|
Figure 8. Examples of a message exchange over the Ff and Fc reference points
图8。Ff和Fc参考点上的消息交换示例
Note that the FE manager function may be co-located with the FE (such as by manual keypad entry of the CE IP address), in which case this reference point is reduced to a built-in function.
请注意，FE管理器功能可能与FE位于同一位置（例如通过手动键盘输入CE IP地址），在这种情况下，该参考点被减少为内置功能。
The Fc reference point is used to inform control elements of the association decisions made by CE managers in the pre-association phase. When the CE manager is remote, only authorized entities may instruct a CE to control certain FEs. Privacy, integrity, freshness, and authentication are also required across this reference point in such a configuration. Once appropriate security has been established, the CE manager instructs the CEs as to which FEs they should control and how they should control them. Figure 8 shows example of a message exchange over the Fc reference point.
Fc参考点用于将CE经理在关联前阶段做出的关联决策告知控制要素。当CE管理器处于远程时，只有授权实体可以指示CE控制某些FEs。在这种配置中，此参考点还需要隐私、完整性、新鲜度和身份验证。一旦建立了适当的安全性，CE经理将指示CE控制哪些FEs以及如何控制它们。图8显示了通过Fc参考点进行消息交换的示例。
As with the FE manager and FEs, configurations are possible where the CE manager and CE are co-located and no protocol is used for this function.
与FE管理器和FEs一样，在CE管理器和CE位于同一位置且此功能不使用协议的情况下，可以进行配置。
The Post-association phase is the period of time during which an FE and CE have been configured with information necessary to contact each other and includes both association establishment and steady-state communication. The communication between CE and FE is performed across the Fp ("p" meaning protocol) reference point. ForCES Protocol is exclusively used for all communication across the Fp reference point.
后关联阶段是FE和CE配置有相互联系所需信息的时间段，包括关联建立和稳态通信。CE和FE之间的通信通过Fp（“p”表示协议）参考点执行。ForCES协议专用于Fp参考点上的所有通信。
The ForCES Working Group has made a conscious decision that the first version of ForCES will be focused on "very close" CE/FE localities in IP networks. Very Close localities consist of control and forwarding elements that are either components in the same physical box, or separated at most by one local network hop ([8]). CEs and FEs can be connected by a variety of interconnect technologies, including Ethernet connections, backplanes, ATM (cell) fabrics, etc. ForCES should be able to support each of these interconnects (see [4] Section 5, requirement #1). When the CEs and FEs are separated beyond a single L3 routing hop, the ForCES Protocol will make use of an existing RFC 2914 [3] compliant L4 protocol with adequate reliability, security, and congestion control (e.g., TCP, SCTP) for transport purposes.
部队工作组已作出一项明智的决定，即部队的第一个版本将集中于IP网络中“非常接近”的CE/FE地点。非常接近的位置由控制和转发元素组成，这些元素要么是同一物理框中的组件，要么最多由一个本地网络跃点（[8]）分隔。CEs和FEs可以通过各种互连技术连接，包括以太网连接、背板、ATM（信元）结构等。部队应能够支持每种互连（见[4]第5节，要求1）。当CEs和FEs在单个L3路由跃点之外分离时，ForCES协议将利用现有的符合RFC 2914[3]的L4协议，该协议具有足够的可靠性、安全性和拥塞控制（例如TCP、SCTP）用于传输目的。
FE CE
| |
|(Security exchange.) |
1|<--------------------->|
| |
|(Let me join the NE please.)
2|---------------------->|
| |
|(What kind of FE are you? -- capability query)
3|<----------------------|
| |
|(Here is my FE functions/state: use model to
describe)
4|---------------------->|
| |
|(Initial config for FE -- optional)
5|<----------------------|
| |
|(I am ready to go. Shall I?)
6|---------------------->|
| |
|(Go ahead!) |
7|<----------------------|
| |
FE CE
| |
|(Security exchange.) |
1|<--------------------->|
| |
|(Let me join the NE please.)
2|---------------------->|
| |
|(What kind of FE are you? -- capability query)
3|<----------------------|
| |
|(Here is my FE functions/state: use model to
describe)
4|---------------------->|
| |
|(Initial config for FE -- optional)
5|<----------------------|
| |
|(I am ready to go. Shall I?)
6|---------------------->|
| |
|(Go ahead!) |
7|<----------------------|
| |
Figure 9. Example of a message exchange between CE and FE over Fp to establish an NE association
图9。CE和FE之间通过Fp交换消息以建立NE关联的示例
As an example, figure 9 shows some of the message exchange that may happen before the association between the CE and FE is fully established. Either the CE or FE can initiate the connection.
例如，图9显示了在CE和FE之间的关联完全建立之前可能发生的一些消息交换。CE或FE均可启动连接。
Security handshake is necessary to authenticate the two communication endpoints to each other before any further message exchange can happen. The security handshake should include mutual authentication and authorization between the CE and FE, but the exact details depend on the security solution chosen by the ForCES Protocol. Authorization can be as simple as checking against the list of authorized end points provided by the FE or CE manager during the pre-association phase. Both authentication and authorization must be successful before the association can be established. If either authentication or authorization fails, the end point must not be allowed to join the NE. After the successful security handshake, message authentication and confidentiality are still necessary for the on-going information exchange between the CE and FE, unless some form of physical security exists. Whenever a packet fails authentication, it must be dropped and a notification may be sent to alert the sender of the potential attack. Section 8 provides more details on the security considerations for ForCES.
在进行任何进一步的消息交换之前，必须进行安全握手以相互验证两个通信端点。安全握手应包括CE和FE之间的相互认证和授权，但具体细节取决于ForCES协议选择的安全解决方案。授权可以非常简单，如在预关联阶段检查FE或CE经理提供的授权端点列表。在建立关联之前，身份验证和授权都必须成功。如果身份验证或授权失败，则不得允许端点加入网元。在成功的安全握手之后，除非存在某种形式的物理安全，否则CE和FE之间正在进行的信息交换仍然需要消息认证和机密性。每当数据包未能通过身份验证时，必须将其丢弃，并发送通知以提醒发送方潜在的攻击。第8节提供了关于部队安全考虑的更多细节。
After the successful security handshake, the FE needs to inform the CE of its own capability and optionally its topology in relation to other FEs. The capability of the FE shall be represented by the FE model, as required in [4] (Section 6, requirement #1). The model would allow an FE to describe what kind of packet processing functions it contains, in what order the processing happens, what kinds of configurable parameters it allows, what statistics it collects, and what events it might throw, etc. Once such information is available to the CE, the CE may choose to send some initial or default configuration to the FE so that the FE can start receiving and processing packets correctly. Such initialization may not be necessary if the FE already obtains the information from its own bootstrap process. Once the necessary initial information is exchanged, the process of association is completed. Packet processing and forwarding at the FE cannot begin until association is established. After the association is established, the CE and FE enter steady-state communication.
在成功的安全握手之后，FE需要通知CE其自身的能力以及可选地其相对于其他FE的拓扑。FE的能力应由FE模型表示，如[4]（第6节，要求#1）所述。该模型允许FE描述其包含的数据包处理功能类型、处理顺序、允许的可配置参数类型、收集的统计信息以及可能引发的事件等。一旦CE获得此类信息，CE可以选择向FE发送一些初始或默认配置，以便FE可以开始正确地接收和处理分组。如果FE已经从自己的引导过程中获得信息，则可能不需要进行此类初始化。一旦交换了必要的初始信息，关联过程就完成了。在建立关联之前，FE上的数据包处理和转发无法开始。关联建立后，CE和FE进入稳态通信。
Once an association is established between the CE and FE, the ForCES Protocol is used by the CE and FE over the Fp reference point to exchange information to facilitate packet processing.
一旦CE和FE之间建立了关联，CE和FE通过Fp参考点使用ForCES协议来交换信息以促进数据包处理。
FE CE
| |
|(Add these new routes.)|
1|<----------------------|
| |
|(Successful.) |
2|---------------------->|
| |
| |
|(Query some stats.) |
1|<----------------------|
| |
|(Reply with stats collected.)
2|---------------------->|
| |
| |
|(My port is down, with port #.)
1|---------------------->|
| |
|(Here is a new forwarding table)
2|<----------------------|
| |
FE CE
| |
|(Add these new routes.)|
1|<----------------------|
| |
|(Successful.) |
2|---------------------->|
| |
| |
|(Query some stats.) |
1|<----------------------|
| |
|(Reply with stats collected.)
2|---------------------->|
| |
| |
|(My port is down, with port #.)
1|---------------------->|
| |
|(Here is a new forwarding table)
2|<----------------------|
| |
Figure 10. Examples of a message exchange between CE and FE over Fp during steady-state communication
图10。稳态通信期间，CE和FE之间通过Fp进行消息交换的示例
Based on the information acquired through CEs' control processing, CEs will frequently need to manipulate the packet-forwarding behaviors of their FE(s) by sending instructions to FEs. For example, Figure 10 shows message exchange examples in which the CE sends new routes to the FE so that the FE can add them to its forwarding table. The CE may query the FE for statistics collected by the FE and the FE may notify the CE of important events such as port failure.
基于通过CEs控制处理获得的信息，CEs将经常需要通过向FEs发送指令来操纵其FE的数据包转发行为。例如，图10显示了消息交换示例，其中CE向FE发送新路由，以便FE可以将它们添加到其转发表中。CE可向FE查询FE收集的统计数据，FE可将端口故障等重要事件通知CE。
--------------------- ----------------------
| | | |
| +--------+ | | +--------+ |
| |CE(BGP) | | | |CE(BGP) | |
| +--------+ | | +--------+ |
| | | | ^ |
| |Fp | | |Fp |
| v | | | |
| +--------+ | | +--------+ |
| | FE | | | | FE | |
| +--------+ | | +--------+ |
| | | | ^ |
| Router | | | Router | |
| A | | | B | |
---------+----------- -----------+----------
v ^
| |
| |
------------------->---------------
--------------------- ----------------------
| | | |
| +--------+ | | +--------+ |
| |CE(BGP) | | | |CE(BGP) | |
| +--------+ | | +--------+ |
| | | | ^ |
| |Fp | | |Fp |
| v | | | |
| +--------+ | | +--------+ |
| | FE | | | | FE | |
| +--------+ | | +--------+ |
| | | | ^ |
| Router | | | Router | |
| A | | | B | |
---------+----------- -----------+----------
v ^
| |
| |
------------------->---------------
Figure 11. Example to show data packet flow between two NEs.
图11。示例显示两个网元之间的数据包流。
Control plane protocol packets (such as RIP, OSPF messages) addressed to any of NE's interfaces are typically redirected by the receiving FE to its CE, and CE may originate packets and have its FE deliver them to other NEs. Therefore, the ForCES Protocol over Fp not only transports the ForCES Protocol messages between CEs and FEs, but also encapsulates the data packets from control plane protocols. Moreover, one FE may be controlled by multiple CEs for distributed control. In this configuration, the control protocols supported by the FORCES NEs may spread across multiple CEs. For example, one CE may support routing protocols like OSPF and BGP, while a signaling and admission control protocol like RSVP is supported in another CE. FEs are configured to recognize and filter these protocol packets and forward them to the corresponding CE.
寻址到任何网元接口的控制平面协议包（例如RIP、OSPF消息）通常由接收FE重定向到其CE，并且CE可以发起包并让其FE将其传递到其他网元。因此，Fp上的ForCES协议不仅在CEs和FEs之间传输ForCES协议消息，而且封装了来自控制平面协议的数据包。此外，一个FE可由多个CE控制以进行分布式控制。在该配置中，由力ne支持的控制协议可以分布在多个ce上。例如，一个CE可以支持诸如OSPF和BGP之类的路由协议，而另一个CE支持诸如RSVP之类的信令和接纳控制协议。FEs被配置为识别和过滤这些协议包，并将它们转发给相应的CE。
Figure 11 shows one example of how the BGP packets originated by router A are passed to router B. In this example, the ForCES Protocol is used to transport the packets from the CE to the FE inside router A, and then from the FE to the CE inside router B. In light of the fact that the ForCES Protocol is responsible for transporting both the control messages and the data packets between the CE and FE over the Fp reference point, it is possible to use either a single protocol or multiple protocols.
图11显示了路由器A发起的BGP数据包如何传递给路由器B的一个示例。在这个示例中，ForCES协议用于将数据包从CE传输到路由器A内的FE，然后从FE到路由器B内的CE。鉴于ForCES协议负责通过Fp参考点在CE和FE之间传输控制消息和数据包，因此可以使用单个协议或多个协议。
In the case where a physical FE cannot implement (e.g., due to the lack of a general purpose CPU) the ForCES Protocol directly, a proxy FE can be used to terminate the Fp reference point instead of the physical FE. This allows the CE to communicate to the physical FE via the proxy by using ForCES, while the proxy manipulates the physical FE using some intermediary form of communication (e.g., a non-ForCES protocol or DMA). In such an implementation, the combination of the proxy and the physical FE becomes one logical FE entity. It is also possible for one proxy to act on behalf of multiple physical FEs.
如果物理FE无法直接实现（例如，由于缺少通用CPU），则可以使用代理FE来终止Fp参考点，而不是物理FE。这允许CE通过使用力经由代理与物理FE通信，而代理使用某种中间通信形式（例如，非力协议或DMA）操纵物理FE。在这种实现中，代理和物理FE的组合成为一个逻辑FE实体。一个代理也可以代表多个物理FEs。
One needs to be aware of the security implication introduced by the proxy FE. Since the physical FE is not capable of implementing ForCES itself, the security mechanism of ForCES can only secure the communication channel between the CE and the proxy FE, but not all the way to the physical FE. It is recommended that other security mechanisms (including physical security property) be employed to ensure the security between the CE and the physical FE.
需要注意代理FE引入的安全含义。由于物理FE本身无法实现部队，部队的安全机制只能保护CE和代理FE之间的通信信道，但不能一直保护物理FE。建议采用其他安全机制（包括物理安全属性），以确保CE和物理FE之间的安全。
FEs and CEs may join and leave NEs dynamically (see [4] Section 5, requirements #12). When an FE or CE leaves the NE, the association with the NE is broken. If the leaving party rejoins an NE later, to re-establish the association, it may need to re-enter the pre-association phase. Loss of association can also happen unexpectedly due to a loss of connection between the CE and the FE. Therefore, the framework allows the bi-directional transition between these two phases, but the ForCES Protocol is only applicable for the post-association phase. However, the protocol should provide mechanisms to support association re-establishment. This includes the ability for CEs and FEs to determine when there is a loss of association between them, and to restore association and efficient state (re)synchronization mechanisms (see [4] Section 5, requirement #7). Note that security association and state must also be re-established to guarantee the same level of security (including both authentication and authorization) exists before and after the association re-establishment.
FEs和CE可以动态加入和离开网元（参见[4]第5节，要求12）。当FE或CE离开NE时，与NE的关联被打破。如果离开方稍后重新加入一个网元，为了重新建立关联，它可能需要重新进入预关联阶段。由于CE和FE之间的连接丢失，也可能意外发生关联丢失。因此，该框架允许在这两个阶段之间进行双向转换，但ForCES协议仅适用于关联后阶段。然而，该协议应提供支持关联重建的机制。这包括CE和FEs确定它们之间何时失去关联的能力，以及恢复关联和有效状态（重新）同步机制的能力（见[4]第5节，要求7）。请注意，还必须重新建立安全关联和状态，以确保在关联重新建立之前和之后存在相同级别的安全性（包括身份验证和授权）。
When an FE leaves or joins an existing NE that is already in operation, the CE needs to be aware of the impact on FE topology and deal with the change accordingly.
当FE离开或加入已在运行的现有网元时，CE需要意识到对FE拓扑的影响，并相应地处理更改。
The failure and restart of the CE in a router can potentially cause much stress and disruption on the control plane throughout a network because in restarting a CE for any reason, the router loses routing adjacencies or sessions with its routing neighbors. Neighbors who detect the lost adjacency normally re-compute new routes and then send routing updates to their own neighbors to communicate the lost adjacency. Their neighbors do the same thing to propagate throughout the network. In the meantime, the restarting router cannot receive traffic from other routers because the neighbors have stopped using the router's previously advertised routes. When the restarting router restores adjacencies, neighbors must once again re-compute new routes and send out additional routing updates. The restarting router is unable to forward packets until it has re-established routing adjacencies with neighbors, received route updates through these adjacencies, and computed new routes. Until convergence takes place throughout the network, packets may be lost in transient black holes or forwarding loops.
路由器中CE的故障和重新启动可能会在整个网络的控制平面上造成很大的压力和中断，因为在出于任何原因重新启动CE时，路由器会丢失与其路由邻居的路由邻接或会话。检测到丢失邻接的邻居通常会重新计算新的路由，然后向自己的邻居发送路由更新，以传递丢失的邻接。他们的邻居也做同样的事情在网络中传播。同时，重新启动的路由器无法接收来自其他路由器的流量，因为邻居已经停止使用路由器先前公布的路由。当重新启动的路由器恢复邻接时，邻居必须再次重新计算新路由并发送额外的路由更新。重新启动的路由器在与邻居重新建立路由邻接、通过这些邻接接收路由更新并计算新路由之前无法转发数据包。在整个网络发生聚合之前，数据包可能会在瞬态黑洞或转发环路中丢失。
A high availability mechanism known as the "graceful restart" has been used by the IP routing protocols (OSPF [11], BGP [12], IS-IS [13]) and MPLS label distribution protocol (LDP [10]) to help minimize the negative effects on routing throughout an entire network caused by a restarting router. Route flap on neighboring routers is avoided, and a restarting router can continue to forward packets that would otherwise be dropped.
IP路由协议（OSPF[11]、BGP[12]、IS-IS[13]）和MPLS标签分发协议（LDP[10]）使用了一种称为“优雅重启”的高可用性机制，以帮助最小化重启路由器对整个网络路由的负面影响。避免了相邻路由器上的路由翻转，重新启动的路由器可以继续转发否则将被丢弃的数据包。
While the details differ from protocol to protocol, the general idea behind the graceful restart mechanism remains the same. With the graceful restart, a restarting router can inform its neighbors when it restarts. The neighbors may detect the lost adjacency but do not recompute new routes or send routing updates to their neighbors. The neighbors also hold on to the routes received from the restarting router before restart and assume they are still valid for a limited time. By doing so, the restarting router's FEs can also continue to receive and forward traffic from other neighbors for a limited time by using the routes they already have. The restarting router then re-establishes routing adjacencies, downloads updated routes from all its neighbors, recomputes new routes, and uses them to replace the older routes it was using. It then sends these updated routes to its neighbors and signals the completion of the graceful restart process.
虽然各个协议的细节有所不同，但优雅重启机制背后的总体思路保持不变。通过优雅的重新启动，重新启动的路由器可以在重新启动时通知其邻居。邻居可能会检测到丢失的邻接，但不会重新计算新路由或向其邻居发送路由更新。邻居也会在重新启动前保留从重新启动的路由器接收到的路由，并假设它们在有限的时间内仍然有效。通过这样做，重新启动路由器的FEs还可以使用其他邻居已有的路由在有限的时间内继续接收和转发来自其他邻居的流量。重新启动的路由器然后重新建立路由邻接，从其所有邻居下载更新的路由，重新计算新路由，并使用它们替换它使用的旧路由。然后，它将这些更新的路由发送给它的邻居，并发出信号，表示优雅的重启过程已经完成。
Non-stop forwarding is a requirement for graceful restart. It is necessary so a router can continue to forward packets while it is downloading routing information and recomputing new routes. This ensures that packets will not be dropped. As one can see, one of the benefits afforded by the separation of CE and FE is exactly the
不停止转发是优雅重启的必要条件。这是必要的，以便路由器在下载路由信息和重新计算新路由时可以继续转发数据包。这确保了数据包不会被丢弃。正如人们所看到的，分离铈和铁所带来的好处之一就是
ability of non-stop forwarding in the face of the CE failure and restart. The support of dynamic changes to CE/FE association in ForCES also makes it compatible with high availability mechanisms, such as graceful restart.
在面临CE故障和重启时不间断转发的能力。支持对ForCES中的CE/FE关联进行动态更改，还使其与高可用性机制（如优雅重启）兼容。
ForCES should be able to support a CE graceful restart easily. When the association is established the first time, the CE must inform the FEs what to do in the case of a CE failure. If graceful restart is not supported, the FEs may be told to stop packet processing all together if its CE fails. If graceful restart is supported, the FEs should be told to cache and hold on to its FE state, including the forwarding tables across the restarts. A timer must be included so that the timeout causes such a cached state to eventually expire. Those timers should be settable by the CE.
部队应能够轻松支持CE优雅重启。当首次建立关联时，CE必须通知FEs在CE故障的情况下应采取的措施。如果不支持优雅重启，则可能会通知FEs在其CE失败时停止所有数据包处理。如果支持优雅重启，则应告知FEs缓存并保持其FE状态，包括重启期间的转发表。必须包含计时器，以便超时导致缓存状态最终过期。这些计时器应由CE设置。
In the same example in Figure 5, assuming CE1 is the working CE for the moment, what would happen if one of the FEs, say FE1, leaves the NE temporarily? FE1 may voluntarily decide to leave the association. Alternatively, FE1 may stop functioning simply due to unexpected failure. In the former case, CE1 receives a "leave-association request" from FE1. In the latter, CE1 detects the failure of FE1 by some other means. In both cases, CE1 must inform the routing protocols of such an event, most likely prompting a reachability and SPF (Shortest Path First) recalculation and associated downloading of new FIBs from CE1 to the other remaining FEs (only FE2 in this example). Such recalculation and FIB updates will also be propagated from CE1 to the NE's neighbors that are affected by the connectivity of FE1.
在图5中的同一示例中，假设CE1是当前的工作CE，如果其中一个FE（比如FE1）暂时离开NE会发生什么？FE1可自愿决定离开协会。或者，FE1可能仅仅由于意外故障而停止运行。在前一种情况下，CE1从FE1接收“休假关联请求”。在后者中，CE1通过其他方式检测FE1的故障。在这两种情况下，CE1必须将此类事件通知路由协议，最有可能提示可达性和SPF（最短路径优先）重新计算，并将新FIB从CE1下载到其他剩余FEs（本例中仅FE2）。这种重新计算和FIB更新也将从CE1传播到受FE1连接影响的网元邻居。
When FE1 decides to rejoin again, or when it restarts again after the failure, FE1 needs to re-discover its master (CE). This can be achieved by several means. It may re-enter the pre-association phase and get that information from its FE manager. It may retrieve the previous CE information from its cache, if it can validate the information freshness. Once it discovers its CE, it starts message exchange with the CE to re-establish the association, as outlined in Figure 9, with the possible exception that it might be able to bypass the transport of the complete initial configuration. Suppose that FE1 still has its routing table and other state information from the last association. Instead of re-sending all the information, it may be able to use a more efficient mechanism to re-sync the state with its CE, if such a mechanism is supported by the ForCES Protocol. For example, CRC-32 of the state might give a quick indication of whether or not the state is in-sync with its CE. By comparing its state with the CE first, it sends an information update
当FE1决定再次加入时，或者当它在失败后再次重新启动时，FE1需要重新发现它的主机（CE）。这可以通过几种方式实现。它可能会重新进入关联前阶段，并从FE经理处获取该信息。如果可以验证信息的新鲜度，它可以从缓存中检索以前的CE信息。一旦发现其CE，它将启动与CE的消息交换以重新建立关联，如图9所示，但可能的例外是它可能能够绕过完整初始配置的传输。假设FE1仍然具有其路由表和来自上一个关联的其他状态信息。如果ForCES协议支持这样一种机制，那么它可以使用更有效的机制将状态与其CE重新同步，而不是重新发送所有信息。例如，该状态的CRC-32可以快速指示该状态是否与其CE同步。通过将其状态与CE first进行比较，它将发送信息更新
only if it is needed. The ForCES Protocol may choose to implement similar optimization mechanisms, but it may also choose not to, as this is not a requirement.
只有在需要的时候。ForCES协议可以选择实现类似的优化机制，但也可以选择不实现，因为这不是一个要求。
[4] Section 5, requirement #9 dictates "Any proposed ForCES architecture must explain how that architecture supports all of the router functions as defined in RFC 1812." RFC 1812 [2] discusses many important requirements for IPv4 routers from the link layer to the application layer. This section addresses the relevant requirements in RFC 1812 for implementing IPv4 routers based on ForCES architecture and explains how ForCES satisfies these requirements by providing guidelines on how to separate the functionalities required into the forwarding plane and control plane.
[4] 第5节，要求#9规定“任何建议的部队体系结构必须解释该体系结构如何支持RFC 1812中定义的所有路由器功能。”RFC 1812[2]讨论了从链路层到应用层的IPv4路由器的许多重要要求。本节介绍了RFC 1812中关于基于ForCES体系结构实现IPv4路由器的相关要求，并解释了ForCES如何通过提供有关如何将所需功能分离到转发平面和控制平面的指南来满足这些要求。
In general, the forwarding plane carries out the bulk of the per-packet processing that is required at line speed, while the control plane carries most of the computationally complex operations that are typical of the control and signaling protocols. However, it is impossible to draw a rigid line to divide the processing into CEs and FEs cleanly and the ForCES architecture should not limit the innovative approaches in control and forwarding plane separation. As more and more processing power is available in the FEs, some of the control functions that traditionally are performed by CEs may now be moved to FEs for better performance and scalability. Such offloaded functions may include part of ICMP or TCP processing, or part of routing protocols. Once off-loaded onto the forwarding plane, such CE functions, even though logically belonging to the control plane, now become part of the FE functions. Just like the other logical functions performed by FEs, such off-loaded functions must be expressed as part of the FE model so that the CEs can decide how to best take advantage of these off-loaded functions when present on the FEs.
通常，转发平面执行以线路速度所需的大部分每个分组处理，而控制平面执行控制和信令协议典型的大多数计算复杂操作。然而，不可能划出一条严格的线来将处理划分为CEs和FEs，部队体系结构不应限制控制和转发平面分离的创新方法。随着FEs中的处理能力越来越强，传统上由CEs执行的一些控制功能现在可以移动到FEs以获得更好的性能和可伸缩性。此类卸载功能可包括ICMP或TCP处理的一部分，或路由协议的一部分。一旦卸载到转发平面上，这样的CE功能，即使在逻辑上属于控制平面，现在也成为FE功能的一部分。与FEs执行的其他逻辑功能一样，此类卸载功能必须表示为FE模型的一部分，以便CEs可以决定如何在FEs上最好地利用这些卸载功能。
Routers have at least two or more logical interfaces. When CEs and FEs are separated by ForCES within a single NE, some additional interfaces are needed for intra-NE communications, as illustrated in figure 12. This NE contains one CE and two FEs. Each FE has four interfaces; two of them are used for receiving and transmitting packets to the external world, while the other two are for intra-NE connections. CE has two logical interfaces #9 and #10, connected to interfaces #3 and #6 from FE1 and FE2, respectively. Interface #4 and #5 are connected for FE1-FE2 communication. Therefore, this router NE provides four external interfaces (#1, 2, 7, and 8).
路由器至少有两个或多个逻辑接口。当CEs和FEs被单个网元内的力分开时，需要一些额外的接口来进行网元内通信，如图12所示。此网元包含一个CE和两个FEs。每个FE有四个接口；其中两个用于接收数据包并将其发送到外部世界，而另外两个用于网元内连接。CE有两个逻辑接口#9和#10，分别连接到FE1和FE2的接口#3和#6。接口#4和#5连接用于FE1-FE2通信。因此，该路由器网元提供四个外部接口（#1、2、7和8）。
---------------------------------
| router NE |
| ----------- ----------- |
| | FE1 | | FE2 | |
| ----------- ----------- |
| 1| 2| 3| 4| 5| 6| 7| 8| |
| | | | | | | | | |
| | | | +----+ | | | |
| | | | | | | |
| | | 9| 10| | | |
| | | -------------- | | |
| | | | CE | | | |
| | | -------------- | | |
| | | | | |
-----+--+----------------+--+----
| | | |
| | | |
---------------------------------
| router NE |
| ----------- ----------- |
| | FE1 | | FE2 | |
| ----------- ----------- |
| 1| 2| 3| 4| 5| 6| 7| 8| |
| | | | | | | | | |
| | | | +----+ | | | |
| | | | | | | |
| | | 9| 10| | | |
| | | -------------- | | |
| | | | CE | | | |
| | | -------------- | | |
| | | | | |
-----+--+----------------+--+----
| | | |
| | | |
Figure 12. A router NE example with four interfaces.
图12。具有四个接口的路由器网元示例。
IPv4 routers must implement IP to support its packet forwarding function, which is driven by its FIB (Forwarding Information Base). This Internet layer forwarding (see RFC 1812 [2] Section 5) functionality naturally belongs to FEs in the ForCES architecture.
IPv4路由器必须实现IP以支持其由其FIB（转发信息库）驱动的数据包转发功能。这种互联网层转发（参见RFC 1812[2]第5节）功能自然属于ForCES架构中的FEs。
A router may implement transport layer protocols (like TCP and UDP) that are required to support application layer protocols (see RFC 1812 [2] Section 6). One important class of application protocols is routing protocols (see RFC 1812 [2] Section 7). In the ForCES architecture, routing protocols are naturally implemented by CEs. Routing protocols require that routers communicate with each other. This communication between CEs in different routers is supported in ForCES by FEs' ability to redirect data packets addressed to routers (i.e., NEs), and the CEs' ability to originate packets and have them delivered by their FEs. This communication occurs across the Fp reference point inside each router and between neighboring routers' external interfaces, as illustrated in Figure 11.
路由器可以实现支持应用层协议所需的传输层协议（如TCP和UDP）（参见RFC 1812[2]第6节）。一类重要的应用协议是路由协议（参见RFC 1812[2]第7节）。在ForCES体系结构中，路由协议自然由CEs实现。路由协议要求路由器相互通信。不同路由器中的CEs之间的这种通信是由FEs重定向寻址到路由器（即，网元）的数据包的能力以及CEs发起数据包并由其FEs传送数据包的能力强制支持的。这种通信发生在每个路由器内部的Fp参考点和相邻路由器的外部接口之间，如图11所示。
Since FEs own all the external interfaces for the router, FEs need to conform to the link layer requirements in RFC 1812 [2]. Arguably, ARP support may be implemented in either CEs or FEs. As we will see later, a number of behaviors that RFC 1812 mandates fall into this category -- they may be performed by the FE and may be performed by the CE. A general guideline is needed to ensure interoperability between separated control and forwarding planes. The guideline we offer here is that CEs MUST be capable of these kinds of operations
由于FEs拥有路由器的所有外部接口，FEs需要符合RFC 1812[2]中的链路层要求。可以说，ARP支持可以在CEs或FEs中实现。正如我们稍后将看到的，RFC 1812委托书中的许多行为都属于这一类——它们可能由FE执行，也可能由CE执行。需要一个通用指南来确保分离的控制平面和转发平面之间的互操作性。我们在此提供的指导原则是，CEs必须能够进行此类操作
while FEs MAY choose to implement them. The FE model should indicate its capabilities in this regard so that CEs can decide where these functions are implemented.
而FEs可能会选择实施它们。FE模型应表明其在这方面的能力，以便CEs能够决定在何处实现这些功能。
Interface parameters, including MTU, IP address, etc., must be configurable by CEs via ForCES. CEs must be able to determine whether a physical interface in an FE is available to send packets or not. FEs must also inform CEs of the status change of the interfaces (like link up/down) via ForCES.
接口参数，包括MTU、IP地址等，必须由CEs通过ForCES进行配置。CEs必须能够确定FE中的物理接口是否可用于发送数据包。FEs还必须通过强制通知CEs接口的状态变化（如连接上/下）。
Both FEs and CEs must implement the IP protocol and all mandatory extensions as RFC 1812 specified. CEs should implement IP options like source route and record route while FEs may choose to implement those as well. The timestamp option should be implemented by FEs to insert the timestamp most accurately. The FE must interpret the IP options that it understands and preserve the rest unchanged for use by CEs. Both FEs and CEs might choose to silently discard packets without sending ICMP errors, but such events should be logged and counted. FEs may report statistics for such events to CEs via ForCES.
FEs和CEs必须按照RFC 1812的规定实施IP协议和所有强制性扩展。CEs应实施源路由和记录路由等IP选项，而FEs也可选择实施这些选项。时间戳选项应由FEs实现，以最准确地插入时间戳。FE必须解释其理解的IP选项，并保持其余选项不变，以供CEs使用。FEs和CEs都可以选择在不发送ICMP错误的情况下以静默方式丢弃数据包，但应记录和统计此类事件。FEs可通过部队向CEs报告此类事件的统计数据。
When multiple FEs are involved to process packets, the appearance of a single NE must be strictly maintained. For example, Time-To-Live (TTL) must be decremented only once within a single NE. For example, it can be always decremented by the last FE with egress function.
当涉及多个FE来处理数据包时，必须严格保持单个网元的外观。例如，生存时间（TTL）必须在单个网元内仅递减一次。例如，它总是可以通过使用出口函数的最后一个FE递减。
FEs must receive and process normally any packets with a broadcast destination address or a multicast destination address that the router has asked to receive. When IP multicast is supported in routers, IGMP is implemented in CEs. CEs are also required of ICMP support, while it is optional for FEs to support ICMP. Such an option can be communicated to CEs as part of the FE model. Therefore, FEs can always rely upon CEs to send out ICMP error messages, but FEs also have the option of generating ICMP error messages themselves.
FEs必须接收并正常处理路由器要求接收的具有广播目的地地址或多播目的地地址的任何数据包。当路由器支持IP多播时，IGMP在CEs中实现。CE还需要ICMP支持，而FEs支持ICMP是可选的。该选项可作为FE模型的一部分传达给CEs。因此，FEs可以始终依赖CEs发送ICMP错误消息，但FEs也可以选择自己生成ICMP错误消息。
IP forwarding is implemented by FEs. When the routing table is updated at the CEs, ForCES is used to send the new route entries from the CEs to FEs. Each FE has its own forwarding table and uses this table to direct packets to the next hop interface.
IP转发由FEs实现。当路由表在CEs更新时，ForCES用于将新路由条目从CEs发送到FEs。每个FE都有自己的转发表，并使用该表将数据包定向到下一跳接口。
Upon receiving IP packets, the FE verifies the IP header and processes most of the IP options. Some options cannot be processed until the routing decision has been made. The routing decision is made after examining the destination IP address. If the destination
在接收到IP数据包后，FE验证IP报头并处理大多数IP选项。在做出路由决定之前，无法处理某些选项。路由决定是在检查目标IP地址后作出的。如果到达目的地
address belongs to the router itself, the packets are filtered and either processed locally or forwarded to the CE, depending upon the instructions set-up by the CE. Otherwise, the FE determines the next hop IP address by looking in its forwarding table. The FE also determines the network interface it uses to send the packets. Sometimes an FE may need to forward the packets to another FE before packets can be forwarded out to the next hop. Right before packets are forwarded out to the next hop, the FE decrements TTL by 1 and processes any IP options that could not be processed before. The FE performs IP fragmentation if necessary, determines the link layer address (e.g., by ARP), and encapsulates the IP datagram (or each of the fragments thereof) in an appropriate link layer frame and queues it for output on the interface selected.
地址属于路由器本身，根据CE设置的指令，对数据包进行过滤、本地处理或转发给CE。否则，FE通过查找其转发表来确定下一跳IP地址。FE还确定用于发送数据包的网络接口。有时，FE可能需要将数据包转发到另一FE，然后才能将数据包转发到下一跳。就在数据包转发到下一跳之前，FE将TTL递减1，并处理以前无法处理的任何IP选项。FE在必要时执行IP分段，确定链路层地址（例如，通过ARP），并将IP数据报（或其每个片段）封装在适当的链路层帧中，并将其排队以便在所选接口上输出。
Other options mentioned in RFC 1812 [2] for IP forwarding may also be implemented at FEs, for example, packet filtering.
RFC 1812[2]中提到的用于IP转发的其他选项也可以在FEs处实现，例如，分组过滤。
FEs typically forward packets destined locally to CEs. FEs may also forward exceptional packets (packets that FEs do not know how to handle) to CEs. CEs are required to handle packets forwarded by FEs for whatever reason. It might be necessary for ForCES to attach some meta-data with the packets to indicate the reasons of forwarding from FEs to CEs. Upon receiving packets with meta-data from FEs, CEs can decide to either process the packets themselves, or pass the packets to the upper layer protocols including routing and management protocols. If CEs are to process the packets by themselves, CEs may choose to discard the packets, or modify and re-send the packets. CEs may also originate new packets and deliver them to FEs for further forwarding.
FEs通常将目的地为本地的数据包转发给CEs。FEs还可以将异常数据包（FEs不知道如何处理的数据包）转发给CEs。CE需要处理FEs出于任何原因转发的数据包。可能需要强制将一些元数据附加到数据包中，以指示从FEs转发到CEs的原因。当从FEs接收到带有元数据的数据包时，CEs可以决定自己处理数据包，或者将数据包传递给上层协议，包括路由和管理协议。如果CEs要自己处理分组，则CEs可以选择丢弃分组，或者修改并重新发送分组。CEs还可以发起新数据包并将其交付给FEs以进行进一步转发。
Any state change during router operation must also be handled correctly according to RFC 1812. For example, when an FE ceases forwarding, the entire NE may continue forwarding packets, but it needs to stop advertising routes that are affected by the failed FE.
路由器运行期间的任何状态变化也必须根据RFC 1812正确处理。例如，当FE停止转发时，整个网元可以继续转发分组，但需要停止受故障FE影响的广告路由。
The Transport layer is typically implemented at CEs to support higher layer application protocols like routing protocols. In practice, this means that most CEs implement both the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP).
传输层通常在CEs上实现，以支持更高层的应用协议，如路由协议。实际上，这意味着大多数CE同时实现传输控制协议（TCP）和用户数据报协议（UDP）。
Both CEs and FEs need to implement the ForCES Protocol. If some layer-4 transport is used to support ForCES, then both CEs and FEs need to implement the L4 transport and ForCES Protocols.
CEs和FEs都需要实现ForCES协议。如果使用某些第4层传输来支持部队，那么CEs和FEs都需要实现L4传输和部队协议。
Interior and exterior routing protocols are implemented on CEs. The routing packets originated by CEs are forwarded to FEs for delivery. The results of such protocols (like forwarding table updates) are communicated to FEs via ForCES.
内部和外部路由协议在CEs上实现。CEs发起的路由数据包被转发给FEs进行传送。此类协议（如转发表更新）的结果通过ForCES传送给FEs。
For performance or scalability reasons, portions of the control plane functions that need faster response may be moved from the CEs and off-loaded onto the FEs. For example, in OSPF, the Hello protocol packets are generated and processed periodically. When done at the CEs, the inbound Hello packets have to traverse from the external interfaces at the FEs to the CEs via the internal CE-FE channel. Similarly, the outbound Hello packets have to go from the CEs to the FEs and to the external interfaces. Frequent Hello updates place heavy processing overhead on the CEs and can overwhelm the CE-FE channel as well. Since typically there are far more FEs than CEs in a router, the off-loaded Hello packets are processed in a much more distributed and scalable fashion. By expressing such off-loaded functions in the FE model, we can ensure interoperability. However, the exact description of the off-loaded functionality corresponding to the off-loaded functions expressed in the FE model are not part of the model itself and will need to be worked out as a separate specification.
出于性能或可伸缩性原因，需要更快响应的控制平面功能的部分可以从CEs移动并卸载到FEs上。例如，在OSPF中，Hello协议分组被周期性地生成和处理。在CEs完成时，入站Hello数据包必须通过内部CE-FE通道从FEs的外部接口穿过CEs。类似地，出站Hello数据包必须从CEs传输到FEs和外部接口。频繁的Hello更新会给CEs带来沉重的处理开销，也会淹没CE-FE通道。由于路由器中的FEs通常比CEs多得多，因此卸载的Hello数据包以更加分布式和可伸缩的方式进行处理。通过在FE模型中表达这些卸载函数，我们可以确保互操作性。然而，与FE模型中表达的卸载功能相对应的卸载功能的准确描述不是模型本身的一部分，需要作为单独的规范制定。
RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP". In general, for the post-association phase, most external management tasks (including SNMP) should be done through interaction with the CE in order to support the appearance of a single functional device. Therefore, it is recommended that an SNMP agent be implemented by CEs and that the SNMP messages received by FEs be redirected to their CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here such that CEs act in the role of master agent to process SNMP protocol messages while FEs act in the role of subagent to provide access to the MIB objects residing on FEs. AgentX protocol messages between the master agent (CE) and the subagent (FE) are encapsulated and transported via ForCES, just like data packets from any other application layer protocols.
RFC1812[2]还规定“路由器必须由SNMP管理”。一般来说，对于关联后阶段，大多数外部管理任务（包括SNMP）应通过与CE的交互来完成，以支持单个功能设备的外观。因此，建议由CEs实现SNMP代理，并将FEs接收的SNMP消息重定向到其CEs。此处可应用RFC 2741（[6]）中定义的AgentX框架，以便CE以主代理的角色处理SNMP协议消息，而FEs以子代理的角色提供对驻留在FEs上的MIB对象的访问。主代理（CE）和子代理（FE）之间的AgentX协议消息通过FORCE进行封装和传输，就像来自任何其他应用层协议的数据包一样。
This document defines an architectural framework for ForCES. It identifies the relevant components for a ForCES network element, including (one or more) FEs, (one or more) CEs, one optional FE manager, and one optional CE manager. It also identifies the interaction among these components and discusses all the major
本文件定义了部队的体系结构框架。它标识ForCES网元的相关组件，包括（一个或多个）FEs、（一个或多个）CE、一个可选FE管理器和一个可选CE管理器。它还确定了这些组件之间的相互作用，并讨论了所有主要问题
reference points. It is important to point out that, among all the reference points, only the Fp interface between CEs and FEs is within the scope of ForCES. ForCES alone may not be enough to support all desirable NE configurations. However, we believe that ForCES over an Fp interface is the most important element in realizing physical separation and interoperability of CEs and FEs, and hence the first interface that ought to be standardized. Simple and useful configurations can still be implemented with only CE-FE interface being standardized, e.g., single CE with full-meshed FEs.
参考点。必须指出的是，在所有参考点中，只有CEs和FEs之间的Fp接口在力的范围内。单独的力可能不足以支持所有理想的NE配置。然而，我们认为Fp接口上的力是实现CEs和FEs物理分离和互操作性的最重要因素，因此是第一个应该标准化的接口。简单而有用的配置仍然可以通过标准化的CE-FE接口来实现，例如，带有全网状FEs的单一CE。
Joel M. Halpern gave us many insightful comments and suggestions and pointed out several major issues. T. Sridhar suggested that the AgentX protocol could be used with SNMP to manage the ForCES network elements. Susan Hares pointed out the issue of graceful restart with ForCES. Russ Housley, Avri Doria, Jamal Hadi Salim, and many others in the ForCES mailing list also provided valuable feedback.
Joel M.Halpern给了我们许多有见地的评论和建议，并指出了几个主要问题。T.Sridhar建议，AgentX协议可与SNMP一起使用，以管理部队网络元素。Susan Hares指出了使用武力进行优雅重启的问题。Russ Housley、Avri Doria、Jamal Hadi Salim和部队邮件列表中的许多其他人也提供了宝贵的反馈。
The NE administrator has the freedom to determine the exact security configuration that is needed for the specific deployment. For example, ForCES may be deployed between CEs and FEs connected to each other inside a box over a backplane. In such a scenario, physical security of the box ensures that most of the attacks, such as man-in-the-middle, snooping, and impersonation, are not possible, and hence the ForCES architecture may rely on the physical security of the box to defend against these attacks and protocol mechanisms may be turned off. However, it is also shown that denial of service attacks via external interfaces as described below in Section 8.1.8 is still a potential threat, even for such an "all-in-one-box" deployment scenario and hence the rate limiting mechanism is still necessary. This is just one example to show that it is important to assess the security needs of the ForCES-enabled network elements under different deployment scenarios. It should be possible for the administrator to configure the level of security needed for the ForCES Protocol.
网元管理员可以自由确定特定部署所需的确切安全配置。例如，部队可能部署在CEs和FEs之间，在背板上方的盒子内彼此连接。在这种情况下，箱子的物理安全性可确保大多数攻击（如中间人、窥探和模拟）不可能发生，因此部队体系结构可能依赖箱子的物理安全性来抵御这些攻击，并且可能会关闭协议机制。然而，还表明，通过第8.1.8节中所述的外部接口进行的拒绝服务攻击仍然是一种潜在威胁，即使对于这种“一体机”部署场景也是如此，因此速率限制机制仍然是必要的。这仅仅是一个例子，表明评估不同部署场景下启用部队的网元的安全需求非常重要。管理员应该可以配置ForCES协议所需的安全级别。
In general, the physical separation of two entities usually results in a potentially insecure link between the two entities and hence much stricter security measurements are required. For example, we pointed out in Section 4.1 that authentication becomes necessary between the CE manager and FE manager, between the CE and CE manager, and between the FE and FE manager in some configurations. The physical separation of the CE and FE also imposes serious security requirements for the ForCES Protocol over the Fp interface. This section first attempts to describe the security threats that may be
通常，两个实体的物理分离通常会导致两个实体之间存在潜在的不安全链接，因此需要更严格的安全措施。例如，我们在第4.1节中指出，在某些配置中，CE manager和FE manager之间、CE和CE manager之间以及FE和FE manager之间需要进行身份验证。CE和FE的物理分离也对Fp接口上的ForCES协议提出了严格的安全要求。本节首先试图描述可能存在的安全威胁
introduced by the physical separation of the FEs and CEs, and then it provides recommendations and guidelines for the secure operation and management of the ForCES Protocol over the Fp interface based on existing standard security solutions.
介绍了FEs和CEs的物理分离，然后根据现有标准安全解决方案，为Fp接口上的ForCES协议的安全操作和管理提供了建议和指南。
This section provides the threat analysis for ForCES, with a focus on the Fp interface. Each threat is described in detail with the effects on the ForCES Protocol entities or/and the NE as a whole, and the required functionalities that need to be in place to defend the threat.
本节提供部队威胁分析，重点是Fp接口。详细描述了每个威胁对部队协议实体或/和整个网元的影响，以及防御威胁所需的功能。
Threats: A malicious node could send a stream of false "join NE" or "remove from NE" requests on behalf of a non-existent or unauthorized FE to legitimate CEs at a very rapid rate, and thereby creating unnecessary state in the CEs.
威胁：恶意节点可以代表不存在或未经授权的FE以非常快的速度向合法CE发送虚假的“加入NE”或“从NE删除”请求流，从而在CE中创建不必要的状态。
Effects: If maintaining state for non-existent or unauthorized FEs, a CE may become unavailable for other processing and hence suffer from a denial of service (DoS) attack similar to the TCP SYN DoS. If multiple CEs are used, the unnecessary state information may also be conveyed to multiple CEs via the Fr interface (e.g., from the active CE to the stand-by CE) and hence subject multiple CEs to a DoS attack.
影响：如果为不存在或未经授权的FEs保持状态，CE可能无法用于其他处理，因此遭受类似于TCP SYN DoS的拒绝服务（DoS）攻击。如果使用多个CE，则不必要的状态信息也可通过Fr接口传送到多个CE（例如，从活动CE到备用CE），从而使多个CE遭受DoS攻击。
Requirement: A CE that receives a "join" or "remove" request should not create any state information until it has authenticated the FE endpoint.
要求：接收“加入”或“删除”请求的CE在对FE端点进行身份验证之前不应创建任何状态信息。
Threats: A malicious node can impersonate a CE or FE and send out false messages.
威胁：恶意节点可以模拟CE或FE并发送错误消息。
Effects: The whole NE could be compromised.
影响：整个NE可能会受到损害。
Requirement: The CE or FE must authenticate the message as having come from an FE or CE on the list of the authorized ForCES elements (provided by the CE or FE Manager in the pre-association phase) before accepting and processing it.
要求：CE或FE必须在接受和处理消息之前，验证消息是否来自授权部队要素列表中的FE或CE（由CE或FE经理在预关联阶段提供）。
Threat: A malicious node could replay the entire message previously sent by an FE or CE entity to get around authentication.
威胁：恶意节点可能重播FE或CE实体先前发送的整个消息，以绕过身份验证。
Effect: The NE could be compromised.
影响：网元可能会受损。
Requirement: A replay protection mechanism needs to be part of the security solution to defend against this attack.
要求：重播保护机制需要成为安全解决方案的一部分，以抵御此攻击。
Threat: A malicious node may exploit the CE fail-over mechanism to take over the control of NE. For example, suppose two CEs, say CE-A and CE-B, are controlling several FEs. CE-A is active and CE-B is stand-by. When CE-A fails, CE-B is taking over the active CE position. The FEs already had a trusted relationship with CE-A, but the FEs may not have the same trusted relationship established with CE-B prior to the fail-over. A malicious node can take over as CE-B if such a trusted relationship has not been established prior to or during the fail-over.
威胁：恶意节点可能利用CE故障转移机制接管网元控制。例如，假设两个CE（如CE-A和CE-B）控制多个FE。CE-A处于激活状态，CE-B处于备用状态。当CE-A出现故障时，CE-B将接管激活的CE位置。FEs已经与CE-a建立了信任关系，但在故障转移之前，FEs可能没有与CE-B建立相同的信任关系。如果在故障转移之前或期间未建立此类信任关系，则恶意节点可以作为CE-B接管。
Effect: The NE may be compromised after such insecure fail-over.
影响：这种不安全的故障切换可能会危及网元。
Requirement: The level of trust between the stand-by CE and the FEs must be as strong as the one between the active CE and the FEs. The security association between the FEs and the stand-by CE may be established prior to fail-over. If not already in place, such security association must be re-established before the stand-by CE takes over.
要求：备用CE和FEs之间的信任水平必须与主动CE和FEs之间的信任水平一样高。FEs和备用CE之间的安全关联可在故障转移之前建立。如果尚未成立，则必须在候补行政长官接管之前重新建立此类安全协会。
Threats: A malicious node may inject false messages to a legitimate CE or FE.
威胁：恶意节点可能会向合法的CE或FE注入错误消息。
Effect: An FE or CE receives the fabricated packet and performs an incorrect or catastrophic operation.
影响：FE或CE接收制造的数据包并执行错误或灾难性操作。
Requirement: Protocol messages require integrity protection.
要求：协议消息需要完整性保护。
Threat: When FE and CE are physically separated, a malicious node may eavesdrop the messages in transit. Some of the messages are critical to the functioning of the whole network, while others may contain confidential business data. Leaking of such information may result in compromise even beyond the immediate CE or FE.
威胁：当FE和CE物理分离时，恶意节点可能会窃听传输中的消息。其中一些消息对整个网络的功能至关重要，而另一些消息可能包含机密业务数据。泄露此类信息可能导致危害，甚至超出直接CE或FE的范围。
Effect: Sensitive information might be exposed between the CE and FE.
影响：CE和FE之间可能会暴露敏感信息。
Requirement: Data confidentiality between the FE and CE must be available for sensitive information.
要求：FE和CE之间的数据保密性必须适用于敏感信息。
Threat: Consider a scenario where several FEs are communicating to the same CE and sharing the same authentication keys for the Fp interface. If any FE or CE is compromised, all other entities are compromised.
威胁：考虑一个场景，其中几个FES正在向同一CE通信，并为FP接口共享相同的认证密钥。如果任何FE或CE受损，则所有其他实体均受损。
Effect: The whole NE is compromised.
影响：整个NE受到破坏。
Recommendation: To avoid this side effect, it's better to configure different security parameters for each FE-CE communication over the Fp interface.
建议：为了避免这种副作用，最好为Fp接口上的每个FE-CE通信配置不同的安全参数。
Threat: When an FE receives a packet that is destined for its CE, the FE forwards the packet over the Fp interface. A malicious node can generate a huge message storm like routing protocol packets etc. through the external Fi/f interface so that the FE has to process and forward all packets to the CE through the Fp interface.
威胁：当FE接收到一个目的地为其CE的数据包时，FE通过Fp接口转发该数据包。恶意节点可以通过外部Fi/f接口生成巨大的消息风暴，如路由协议数据包等，因此FE必须通过Fp接口处理所有数据包并将其转发给CE。
Effect: The CE encounters resource exhaustion and bandwidth starvation on Fp interface due to an overwhelming number of packets from FEs.
影响：由于来自FEs的大量数据包，CE在Fp接口上遇到资源耗尽和带宽不足。
Requirement: Some sort of rate limiting mechanism MUST be in place at both the FE and CE. The Rate Limiter SHOULD be configured at the FE for each message type being received through the Fi/f interface.
要求：FE和CE必须有某种限速机制。对于通过Fi/f接口接收的每种消息类型，应在FE处配置速率限制器。
The requirements document [4] suggested that the ForCES Protocol should support reliability over the Fp interface, but no particular transport protocol is yet specified for ForCES. This framework document does not intend to specify the particular transport either, and so we only provide recommendations and guidelines based on the existing standard security protocols [18] that can work with the common transport candidates suitable for ForCES.
需求文件[4]建议部队协议应支持Fp接口的可靠性，但尚未为部队指定特定的传输协议。本框架文件也不打算具体说明特定的运输方式，因此我们仅提供基于现有标准安全协议[18]的建议和指南，这些协议可与适用于部队的通用运输备选方案一起使用。
We review two existing security protocol solutions, namely IPsec (IP Security) [15] and TLS (Transport Layer Security) [14]. TLS works with reliable transports such as TCP or SCTP for unicast, while IPsec can be used with any transport (UDP, TCP, SCTP) and supports both unicast and multicast. Both TLS and IPsec can be used potentially to satisfy all of the security requirements for the ForCES Protocol. In addition, other approaches that satisfy the requirements can be used as well, but are not documented here, including the use of L2 security mechanisms for a given L2 interconnect technology.
我们回顾了两种现有的安全协议解决方案，即IPsec（IP安全）[15]和TLS（传输层安全）[14]。TLS与可靠的传输（如TCP或SCTP）配合使用，用于单播，而IPsec可与任何传输（UDP、TCP、SCTP）配合使用，并支持单播和多播。TLS和IPsec均可用于满足ForCES协议的所有安全要求。此外，也可以使用满足要求的其他方法，但此处没有记录，包括对给定L2互连技术使用L2安全机制。
When ForCES is deployed between CEs and FEs inside a box or a physically secured room, authentication, confidentiality, and integrity may be provided by the physical security of the box. Thus, the security mechanisms may be turned off, depending on the networking topology and its administration policy. However, it is important to realize that even if the NE is in a single-box, the DoS attacks as described in Section 8.1.8 can still be launched through the Fi/f interfaces. Therefore, it is important to have the corresponding counter-measurement in place, even for single-box deployment.
当部队部署在箱子或物理安全房间内的CEs和FEs之间时，箱子的物理安全可提供身份验证、机密性和完整性。因此，根据网络拓扑及其管理策略，可以关闭安全机制。但是，重要的是要认识到，即使网元位于单个机箱中，第8.1.8节所述的DoS攻击仍然可以通过Fi/f接口发起。因此，即使是单箱部署，也必须有相应的计数器测量。
TLS [14] can be used if a reliable unicast transport such as TCP or SCTP is used for ForCES over the Fp interface. The TLS handshake protocol is used during the association establishment or re-establishment phase to negotiate a TLS session between the CE and FE. Once the session is in place, the TLS record protocol is used to secure ForCES communication messages between the CE and FE.
如果Fp接口上的部队使用可靠的单播传输（如TCP或SCTP），则可以使用TLS[14]。TLS握手协议在关联建立或重新建立阶段用于协商CE和FE之间的TLS会话。一旦会话就位，TLS记录协议将用于保护CE和FE之间的ForCES通信消息。
A basic outline of how TLS can be used with ForCES is described below. Steps 1) through 7) complete the security handshake as illustrated in Figure 9, while step 8) is for all further communication between the CE and FE, including the rest of the messages after the security handshake shown in Figure 9 and the steady-state communication shown in Figure 10.
TLS如何与力一起使用的基本概述如下所述。步骤1）到7）如图9所示完成安全握手，而步骤8）用于CE和FE之间的所有进一步通信，包括图9所示的安全握手和图10所示的稳态通信之后的其余消息。
1) During the Pre-association phase, all FEs are configured with the CEs (including both the active CE and the standby CE).
1) 在预关联阶段，所有FEs都配置有CE（包括活动CE和备用CE）。
2) The FE establishes a TLS connection with the CE (master) and negotiates a cipher suite.
2) FE与CE（主机）建立TLS连接，并协商密码套件。
3) The FE (slave) gets the CE certificate, validates the signature, checks the expiration date, and checks whether the certificate has been revoked.
3) FE（从属）获取CE证书，验证签名，检查过期日期，并检查证书是否已被吊销。
4) The CE (master) gets the FE certificate and performs the same validation as the FE in step 3).
4) CE（主）获取FE证书，并执行与步骤3）中FE相同的验证。
5) If any of the checks fail in step 3) or step 4), the endpoint must generate an error message and abort.
5) 如果任何检查在步骤3）或步骤4）中失败，端点必须生成错误消息并中止。
6) After successful mutual authentication, a TLS session is established between the CE and FE.
6) 在成功的相互认证之后，在CE和FE之间建立TLS会话。
7) The FE sends a "join NE" message to the CE.
7) FE向CE发送“加入NE”消息。
8) The FE and CE use the TLS session for further communication.
8) FE和CE使用TLS会话进行进一步通信。
Note that there are different ways for the CE and FE to validate a received certificate. One way is to configure the FE Manager or CE Manager or other central component as CA, so that the CE or FE can query this pre-configured CA to validate that the certificate has not been revoked. Another way is to have the CE and FE directly configure a list of valid certificates in the pre-association phase.
请注意，CE和FE有不同的方式来验证收到的证书。一种方法是将FE管理器或CE管理器或其他中心组件配置为CA，以便CE或FE可以查询此预配置的CA以验证证书是否未被吊销。另一种方法是让CE和FE在预关联阶段直接配置有效证书的列表。
In the case of fail-over, it is the responsibility of the active CE and the standby CE to synchronize ForCES states, including the TLS states to minimize the state re-establishment during fail-over. Care must be taken to ensure that the standby CE is also authenticated in the same way as the active CE, either before or during the fail-over.
在故障切换的情况下，主动CE和备用CE负责同步部队状态，包括TLS状态，以尽量减少故障切换期间的状态重建。在故障转移之前或期间，必须注意确保备用CE也以与活动CE相同的方式进行身份验证。
IPsec [15] can be used with any transport protocol, such as UDP, SCTP, and TCP, over the Fp interface for ForCES. When using IPsec, we recommend using ESP in the transport mode for ForCES because message confidentiality is required for ForCES.
IPsec[15]可通过Fp接口与任何传输协议（如UDP、SCTP和TCP）一起使用，以供部队使用。在使用IPsec时，我们建议在ForCES的传输模式下使用ESP，因为ForCES需要消息机密性。
IPsec can be used with both manual and automated SA and cryptographic key management. But IPsec's replay protection mechanisms are not available if manual key management is used. Hence, automatic key management is recommended if replay protection is deemed important. Otherwise, manual key management might be sufficient for some deployment scenarios, especially when the number of CEs and FEs is relatively small. It is recommended that the keys be changed periodically, even for manual key management.
IPsec可用于手动和自动SA和加密密钥管理。但是，如果使用手动密钥管理，则IPsec的重播保护机制不可用。因此，如果认为重播保护很重要，建议使用自动密钥管理。否则，对于某些部署场景，手动密钥管理可能就足够了，特别是当CE和FEs的数量相对较少时。建议定期更换钥匙，即使是手动钥匙管理。
IPsec can support both unicast and multicast transport. At the time this document was published, the MSEC working group was actively working on standardizing protocols to provide multicast security [17]. Multicast-based solutions relying on IPsec should specify how to meet the security requirements in [4].
IPsec可以支持单播和多播传输。在本文件发布时，MSEC工作组正积极致力于标准化协议，以提供多播安全[17]。依赖IPsec的基于多播的解决方案应指定如何满足[4]中的安全要求。
Unlike TLS, IPsec provides security services between the CE and FE at IP level, so the security handshake, as illustrated in Figure 9 amounts to a "no-op" when manual key management is used. The following outlines the steps taken for ForCES in such a case.
与TLS不同，IPsec在IP级别在CE和FE之间提供安全服务，因此，如图9所示，当使用手动密钥管理时，安全握手相当于“无操作”。以下概述了在这种情况下对力采取的步骤。
1) During the Pre-association phase, all the FEs are configured with CEs (including the active CE and standby CE) and SA parameters manually.
1) 在预关联阶段，所有FEs均手动配置CEs（包括主CE和备用CE）和SA参数。
2) The FE sends a "join NE" message to the CE. This message and all others that follow are afforded security service according to the manually configured IPsec SA parameters, but replay protection is not available.
2) FE向CE发送“加入NE”消息。根据手动配置的IPsec SA参数，将为此消息和所有其他消息提供安全服务，但重播保护不可用。
It is up to the administrator to decide whether to share the same key across multiple FE-CE communication, but it is recommended that different keys be used. Similarly, it is recommended that different keys be used for inbound and outbound traffic.
由管理员决定是否在多个FE-CE通信中共享同一密钥，但建议使用不同的密钥。同样，建议对入站和出站流量使用不同的密钥。
If automatic key management is needed, IKE [16] can be used for that purpose. Other automatic key distribution techniques, such as Kerberos, may be used as well. The key exchange process constitutes the security handshake as illustrated in Figure 9. The following shows the steps involved in using IKE with IPsec for ForCES. Steps 1) to 6) constitute the security handshake in Figure 9.
如果需要自动密钥管理，IKE[16]可用于此目的。也可以使用其他自动密钥分发技术，例如Kerberos。密钥交换过程构成安全握手，如图9所示。以下显示了将IKE与IPsec一起用于部队的步骤。步骤1）到6）构成图9中的安全握手。
1) During the Pre-association phase, all FEs are configured with the CEs (including active CE and standby CE), IPsec policy etc.
1) 在预关联阶段，所有FEs都配置了CE（包括活动CE和备用CE）、IPsec策略等。
2) The FE kicks off the IKE process and tries to establish an IPsec SA with the CE (master). The FE (Slave) gets the CE certificate as part of the IKE negotiation. The FE validates the signature, checks the expiration date, and checks whether the certificate has been revoked.
2) FE启动IKE进程，并尝试与CE（主机）建立IPsec SA。FE（从）作为IKE协商的一部分获得CE证书。FE验证签名，检查过期日期，并检查证书是否已被吊销。
3) The CE (master) gets the FE certificate and performs the same check as the FE in step 2).
3) CE（主设备）获取FE证书，并执行与步骤2中FE相同的检查。
4) If any of the checks fail in step 2) or step 3), the endpoint must generate an error message and abort.
4) 如果任何检查在步骤2）或步骤3）中失败，端点必须生成错误消息并中止。
5) After successful mutual authentication, the IPsec session is established between the CE and FE.
5) 成功的相互身份验证后，将在CE和FE之间建立IPsec会话。
6) The FE sends a "join NE" message to the CE. No SADB entry is created in FE yet.
6) FE向CE发送“加入NE”消息。FE中尚未创建SADB条目。
7) The FE and CE use the IPsec session for further communication.
7) FE和CE使用IPsec会话进行进一步通信。
The FE Manager, CE Manager, or other central component can be used as a CA for validating CE and FE certificates during the IKE process. Alternatively, during the pre-association phase, the CE and FE can be configured directly with the required information, such as certificates or passwords etc., depending upon the type of authentication that administrator wants to configure.
FE管理器、CE管理器或其他中心组件可以用作CA，用于在IKE过程中验证CE和FE证书。或者，在预关联阶段，根据管理员想要配置的身份验证类型，可以使用所需信息（例如证书或密码等）直接配置CE和FE。
In the case of fail-over, it is the responsibility of the active CE and standby CE to synchronize ForCES states and IPsec states to minimize the state re-establishment during fail-over. Alternatively, the FE needs to establish a different IPsec SA during the startup operation itself with each CE. This will minimize the periodic state transfer across the IPsec layer though the Fr (CE-CE) Interface.
在故障转移的情况下，主动CE和备用CE负责同步强制状态和IPsec状态，以尽量减少故障转移期间的状态重建。或者，FE需要在每个CE的启动操作期间建立不同的IPsec SA。这将最小化通过Fr（CE-CE）接口跨IPsec层的周期性状态传输。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[2] Baker，F.，Ed.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[3] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[3] Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[4] Khosravi, H. and Anderson, T., Eds., "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.
[4] Khosravi，H.和Anderson，T.，编辑，“IP控制和转发分离的要求”，RFC 3654，2003年11月。
[5] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework", RFC 3410, December 2002.
[5] Case，J.，Mundy，R.，Partain，D.和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 3410，2002年12月。
[6] Daniele, M., Wijnen, B., Ellison, M. and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000.
[6] Daniele，M.，Wijnen，B.，Ellison，M.和D.Francisco，“代理可扩展性（AgentX）协议版本1”，RFC 27412000年1月。
[7] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[7] Chan，K.，Seligson，J.，Durham，D.，Gai，S.，McCloghrie，K.，Herzog，S.，Reichmeyer，F.，Yavatkar，R.和A.Smith，“政策制定的COPS使用（COPS-PR）”，RFC 3084，2001年3月。
[8] Crouch, A. et al., "ForCES Applicability Statement", Work in Progress.
[8] Crouch，A.等人，“部队适用性声明”，正在进行的工作。
[9] Anderson, T. and J. Buerkle, "Requirements for the Dynamic Partitioning of Switching Elements", RFC 3532, May 2003.
[9] Anderson，T.和J.Buerkle，“开关元件动态分区的要求”，RFC 3532，2003年5月。
[10] Leelanivas, M., Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[10] Leelanivas，M.，Rekhter，Y.和R.Aggarwal，“标签分发协议的优雅重启机制”，RFC 3478，2003年2月。
[11] Moy, J., Pillay-Esnault, P. and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[11] Moy，J.，Pillay Esnault，P.和A.Lindem，“优雅的OSPF重启”，RFC 36232003年11月。
[12] Sangli, S. et al., "Graceful Restart Mechanism for BGP", Work in Progress.
[12] Sangli，S.等人，“BGP的优雅重启机制”，正在进行中。
[13] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", Work in Progress.
[13] Shand，M.和L.Ginsberg，“IS-IS的重启信号”，工作正在进行中。
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[14] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[15] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[15] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[16] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[16] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[17] Hardjono, T. and Weis, B. "The Multicast Group Security Architecture", RFC 3740, March 2004.
[17] Hardjono，T.和Weis，B.“多播组安全架构”，RFC3740，2004年3月。
[18] Bellovin, S., Schiller, J. and C. Kaufman, Eds., "Security Mechanisms for the Internet", RFC 3631, December 2003.
[18] Bellovin，S.，Schiller，J.和C.Kaufman编辑，“互联网的安全机制”，RFC 36312003年12月。
L. Lily Yang Intel Corp., MS JF3-206, 2111 NE 25th Avenue Hillsboro, OR 97124, USA
L.Lily Yang Intel Corp.，美国希尔斯堡东北25大道2111号JF3-206女士，邮编：97124
Phone: +1 503 264 8813
EMail: lily.l.yang@intel.com
Phone: +1 503 264 8813
EMail: lily.l.yang@intel.com
Ram Dantu Department of Computer Science, University of North Texas, Denton, TX 76203, USA
丹徒北得克萨斯大学计算机科学系，丹顿，美国76203
Phone: +1 940 565 2822
EMail: rdantu@unt.edu
Phone: +1 940 565 2822
EMail: rdantu@unt.edu
Todd A. Anderson Intel Corp. 2111 NE 25th Avenue Hillsboro, OR 97124, USA
托德·安德森英特尔公司，美国希尔斯伯勒东北25大道2111号，邮编：97124
Phone: +1 503 712 1760
EMail: todd.a.anderson@intel.com
Phone: +1 503 712 1760
EMail: todd.a.anderson@intel.com
Ram Gopal Nokia Research Center 5, Wayside Road, Burlington, MA 01803, USA
美国马萨诸塞州伯灵顿韦赛德路5号Ram Gopal诺基亚研究中心01803
Phone: +1 781 993 3685
EMail: ram.gopal@nokia.com
Phone: +1 781 993 3685
EMail: ram.gopal@nokia.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。