Network Working Group H. Khosravi, Ed.
Request for Comments: 3654 T. Anderson, Ed.
Category: Informational Intel
November 2003
Network Working Group H. Khosravi, Ed.
Request for Comments: 3654 T. Anderson, Ed.
Category: Informational Intel
November 2003
Requirements for Separation of IP Control and Forwarding
IP控制和转发分离的要求
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document introduces the Forwarding and Control Element Separation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.
本文档介绍了转发和控制元素分离（ForCES）体系结构，并定义了一组相关术语。本文档还定义了一组体系结构、建模和协议要求，以从逻辑上分离IP（IPv4、IPv6等）网络设备的控制和数据转发平面。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architectural Requirements. . . . . . . . . . . . . . . . . . 5
5. FE Model Requirements . . . . . . . . . . . . . . . . . . . . 7
5.1. Types of Logical Functions. . . . . . . . . . . . . . . 8
5.2. Variations of Logical Functions . . . . . . . . . . . . 8
5.3. Ordering of Logical Functions . . . . . . . . . . . . . 8
5.4. Flexibility . . . . . . . . . . . . . . . . . . . . . . 8
5.5 Minimal Set of Logical Functions. . . . . . . . . . . . 9
6. ForCES Protocol Requirements. . . . . . . . . . . . . . . . . 10
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References. . . . . . . . . . . . . . . . . . 14
7.2. Informative References. . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Authors' Addresses & Acknowledgments. . . . . . . . . . . . . 15
10. Editors' Contact Information. . . . . . . . . . . . . . . . . 17
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 18
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architectural Requirements. . . . . . . . . . . . . . . . . . 5
5. FE Model Requirements . . . . . . . . . . . . . . . . . . . . 7
5.1. Types of Logical Functions. . . . . . . . . . . . . . . 8
5.2. Variations of Logical Functions . . . . . . . . . . . . 8
5.3. Ordering of Logical Functions . . . . . . . . . . . . . 8
5.4. Flexibility . . . . . . . . . . . . . . . . . . . . . . 8
5.5 Minimal Set of Logical Functions. . . . . . . . . . . . 9
6. ForCES Protocol Requirements. . . . . . . . . . . . . . . . . 10
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References. . . . . . . . . . . . . . . . . . 14
7.2. Informative References. . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Authors' Addresses & Acknowledgments. . . . . . . . . . . . . 15
10. Editors' Contact Information. . . . . . . . . . . . . . . . . 17
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 18
An IP network element is composed of numerous logically separate entities that cooperate to provide a given functionality (such as a routing or IP switching) and yet appear as a normal integrated network element to external entities. Two primary types of network element components exist: control-plane components and forwarding-plane components. In general, forwarding-plane components are ASIC, network-processor, or general-purpose processor-based devices that handle all data path operations. Conversely, control-plane components are typically based on general-purpose processors that provide control functionality such as the processing of routing or signaling protocols. A standard set of mechanisms for connecting these components provides increased scalability and allows the control and forwarding planes to evolve independently, thus promoting faster innovation.
IP网元由多个逻辑上独立的实体组成，这些实体相互协作以提供给定的功能（如路由或IP交换），但对于外部实体来说，它们仍然是一个普通的集成网元。存在两种主要类型的网元组件：控制平面组件和转发平面组件。一般来说，转发平面组件是ASIC、网络处理器或处理所有数据路径操作的基于通用处理器的设备。相反，控制平面组件通常基于提供控制功能（例如路由或信令协议的处理）的通用处理器。连接这些组件的一组标准机制提供了更高的可伸缩性，并允许控制和转发平面独立发展，从而促进更快的创新。
For the purpose of illustration, let us consider the architecture of a router to illustrate the concept of separate control and forwarding planes. The architecture of a router is composed of two main parts. These components, while inter-related, perform functions that are largely independent of each other. At the bottom is the forwarding path that operates in the data-forwarding plane and is responsible for per-packet processing and forwarding. Above the forwarding plane is the network operating system that is responsible for operations in the control plane. In the case of a router or switch, the network operating system runs routing, signaling and control protocols (e.g., RIP, OSPF and RSVP) and dictates the forwarding behavior by manipulating forwarding tables, per-flow QoS tables and access control lists. Typically, the architecture of these devices combines all of this functionality into a single functional whole with respect to external entities.
为了说明的目的，让我们考虑路由器的体系结构来说明单独的控制和转发平面的概念。路由器的体系结构由两个主要部分组成。这些组件虽然相互关联，但执行的功能在很大程度上彼此独立。底部是在数据转发平面中运行的转发路径，负责每个数据包的处理和转发。转发平面上方是负责控制平面中操作的网络操作系统。对于路由器或交换机，网络操作系统运行路由、信令和控制协议（例如RIP、OSPF和RSVP），并通过操作转发表、每流QoS表和访问控制列表来指示转发行为。通常，这些设备的体系结构将所有这些功能结合到一个关于外部实体的单一功能整体中。
Addressable Entity (AE) - A physical device 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; and 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, ASIC's, line cards with multiple chips or stand alone box with general-purpose processors.
物理转发元件（PFE）-一种AE，包括用于提供每包处理和处理的硬件。该硬件可能包括（但不限于）网络处理器、ASIC、具有多个芯片的线路卡或具有通用处理器的独立机箱。
Physical Control Element (PCE) - An AE that includes hardware used to provide control functionality. This hardware typically includes a general-purpose processor.
物理控制元件（PCE）-包括用于提供控制功能的硬件的AE。该硬件通常包括一个通用处理器。
Forwarding Element (FE) - A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per-packet processing and handling as directed/controlled by 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 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）-实现ForCES协议并使用它指示一个或多个FEs如何处理数据包的逻辑实体。CEs处理控制和信令协议的执行等功能。CE可以由PCE分区或整个PCE组成。
Pre-association Phase - The period of time during which a FE Manager (see below) and a CE Manager (see below) are determining which FE and CE should be part of the same network element. Any partitioning of PFEs and PCEs occurs during this phase.
预关联阶段-FE经理（见下文）和CE经理（见下文）确定哪些FE和CE应属于同一网元的时间段。在此阶段，PFE和PCE发生任何分区。
Post-association Phase - The period of time during which a FE does know 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.
强制关联后阶段协议-用于CEs和FEs之间关联后阶段通信的协议。本协议不适用于CE-to-CE通信、FE-to-FE通信或FE与CE经理之间的通信。ForCES协议是一种主从协议，其中FEs是从协议，ce是主协议。该协议包括通信信道的管理（例如，连接建立、心跳）和控制消息本身。该协议可以是单个协议，也可以由多个协议组成。
FE Model - A model that describes the logical processing functions of a FE.
FE模型-描述FE逻辑处理功能的模型。
FE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which CE(s) a FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. A FE manager may use anything from a static configuration to a pre-association
FE Manager—在关联前阶段运行的逻辑实体，负责确定FE应与哪些CE通信。此过程称为CE发现，可能涉及FE经理学习可用CE的能力。FE管理器可以使用任何东西，从静态配置到预关联
phase protocol (see below) to determine which CE to use. However, this pre-association phase protocol is currently out of scope. Being a logical entity, a FE manager might be physically combined with any of the other logical entities mentioned in this section.
确定使用哪个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. Again, this pre-association phase protocol 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) what is used within the ForCES protocol (see Section 6, requirement #1). However, the two capability discovery mechanisms may utilize the same FE model (see Section 5). Pre-association phase protocols are not discussed further in this document.
预关联阶段协议-FE管理器和CE管理器之间的协议，用于确定使用哪个CE或FEs。预关联阶段协议可包括CE和/或FE能力发现机制。请注意，该能力发现过程完全独立于（且不取代）部队协议中使用的内容（见第6节，需求#1）。然而，两种能力发现机制可能使用相同的FE模型（见第5节）。本文档中不再进一步讨论预关联阶段协议。
ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. To entities outside a NE, the NE represents a single point of management. Similarly, a NE usually hides its internal organization from external entities.
强制网元（NE）-由一个或多个CE和一个或多个FEs组成的实体。对于网元之外的实体，网元表示单个管理点。类似地，网元通常对外部实体隐藏其内部组织。
ForCES Protocol Element - A FE or CE.
强制协议元素-FE或CE。
High Touch Capability - This term will be used to apply to the capabilities found in some forwarders to take action on the contents or headers of a packet based on content other than what is found in the IP header. Examples of these capabilities include NAT-PT, firewall, and L7 content recognition.
高接触能力-该术语将用于应用于某些转发器中发现的基于IP报头中发现的内容以外的内容对数据包的内容或报头采取行动的能力。这些功能的示例包括NAT-PT、防火墙和L7内容识别。
The chief components of a NE architecture are the CE, the FE, and the interconnect protocol. The CE is responsible for operations such as signaling and control protocol processing and the implementation of management protocols. Based on the information acquired through control processing, the CE(s) dictates the packet-forwarding behavior of the FE(s) via the interconnect protocol. For example, the CE might control a FE by manipulating its forwarding tables, the state of its interfaces, or by adding or removing a NAT binding.
网元架构的主要组件是CE、FE和互连协议。CE负责诸如信令和控制协议处理以及管理协议的实施等操作。基于通过控制处理获得的信息，CE（s）通过互连协议指示FE（s）的分组转发行为。例如，CE可以通过操纵FE的转发表、接口状态或添加或删除NAT绑定来控制FE。
The FE operates in the forwarding plane and is responsible for per-packet processing and handling. By allowing the control and forwarding planes to evolve independently, different types of FEs can be developed - some general purpose and others more specialized. Some functions that FEs could perform include layer 3 forwarding, metering, shaping, firewall, NAT, encapsulation (e.g., tunneling), decapsulation, encryption, accounting, etc. Nearly all combinations of these functions may be present in practical FEs.
FE在转发平面中运行，负责每个数据包的处理和处理。通过允许控制和转发平面独立发展，可以开发不同类型的FEs——一些是通用的，而另一些则更专业。FEs可以执行的一些功能包括第3层转发、计量、整形、防火墙、NAT、封装（例如隧道）、去封装、加密、记帐等。这些功能的几乎所有组合都可能出现在实际FEs中。
Below is a diagram illustrating an example NE composed of a CE and two FEs. Both FEs and CE require minimal configuration as part of the pre-configuration process and this may be done by FE Manager and CE Manager respectively. Apart from this, there is no defined role for FE Manager and CE Manager. These components are out of scope of the architecture and requirements for the ForCES protocol, which only involves CEs and FEs.
下面是示出由一个CE和两个FEs组成的示例NE的图。作为预配置过程的一部分，FEs和CE都需要最少的配置，这可以分别由FE经理和CE经理完成。除此之外，FE经理和CE经理没有明确的角色。这些组件超出了ForCES协议的体系结构和要求范围，该协议仅涉及CEs和FEs。
--------------------------------
| NE |
| ------------- |
| | CE | |
| ------------- |
| / \ |
| / \ |
| / \ |
| / \ |
| ----------- ----------- |
| | FE | | FE | |
| ----------- ----------- |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
--------------------------------
| | | | | | | |
| | | | | | | |
--------------------------------
| NE |
| ------------- |
| | CE | |
| ------------- |
| / \ |
| / \ |
| / \ |
| / \ |
| ----------- ----------- |
| | FE | | FE | |
| ----------- ----------- |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
--------------------------------
| | | | | | | |
| | | | | | | |
The following are the architectural requirements:
以下是架构要求：
1) CEs and FEs MUST be able to connect by a variety of interconnect technologies. Examples of interconnect technologies used in current architectures include Ethernet, bus backplanes, and ATM (cell) fabrics. FEs MAY be connected to each other via a different technology than that used for CE/FE communication.
1) CEs和FEs必须能够通过各种互连技术进行连接。当前架构中使用的互连技术示例包括以太网、总线背板和ATM（信元）结构。FEs可以通过与CE/FE通信不同的技术相互连接。
2) FEs MUST support a minimal set of capabilities necessary for establishing network connectivity (e.g., interface discovery, port up/down functions). Beyond this minimal set, the ForCES architecture MUST NOT restrict the types or numbers of capabilities that FEs may contain.
2) FEs必须支持建立网络连接所需的最小功能集（例如，接口发现、端口上/下功能）。除此之外，部队体系结构不得限制FEs可能包含的能力类型或数量。
3) Packets MUST be able to arrive at the NE by one FE and leave the NE via a different FE.
3) 数据包必须能够通过一个FE到达网元，并通过另一个FE离开网元。
4) A NE MUST support the appearance of a single functional device. For example, in a router, the TTL of the packet should be decremented only once as it traverses the NE regardless of how many FEs through which it passes. However, external entities (e.g., FE managers and CE managers) MAY have direct access to individual ForCES protocol elements for providing information to transition them from the pre-association to post-association phase.
4) 网元必须支持单个功能设备的外观。例如，在路由器中，当数据包通过网元时，无论它通过多少个FEs，它的TTL应该只减少一次。但是，外部实体（如FE经理和CE经理）可以直接访问各个部队协议元素，以提供信息，将其从关联前阶段过渡到关联后阶段。
5) The architecture MUST provide a way to prevent unauthorized ForCES protocol elements from joining a NE. (For more protocol details, refer to section 6 requirement #2)
5) 该体系结构必须提供一种防止未经授权的强制协议元素加入网元的方法。（有关更多协议详情，请参阅第6节要求#2）
6) A FE MUST be able to asynchronously inform the CE of a failure or increase/decrease in available resources or capabilities on the FE. Thus, the FE MUST support error monitoring and reporting. (Since there is not a strict 1-to-1 mapping between FEs and PFEs, it is possible for the relationship between a FE and its physical resources to change over time). For example, the number of physical ports or the amount of memory allocated to a FE may vary over time. The CE needs to be informed of such changes so that it can control the FE in an accurate way.
6) FE必须能够异步通知CE FE上的可用资源或能力出现故障或增加/减少。因此，FE必须支持错误监控和报告。（由于FEs和PFE之间没有严格的1:1映射，FE与其物理资源之间的关系可能会随时间而变化）。例如，分配给FE的物理端口数或内存量可能随时间而变化。需要通知CE此类变更，以便其能够准确地控制FE。
7) The architecture MUST support mechanisms for CE redundancy or CE failover. This includes the ability for CEs and FEs to determine when there is a loss of association between them, ability to restore association and efficient state (re)synchronization mechanisms. This also includes the ability to preset the actions an FE will take in reaction to loss of association to its CE e.g., whether the FE will continue to forward packets or whether it will halt operations.
7) 该体系结构必须支持CE冗余或CE故障切换机制。这包括CE和FEs确定它们之间何时失去关联的能力、恢复关联的能力以及有效的状态（重新）同步机制。这还包括预设FE在其CE失去关联时将采取的行动的能力，例如，FE是否将继续转发数据包或是否将停止操作。
8) FEs MUST be able to redirect control packets (such as RIP, OSPF messages) addressed to their interfaces to the CE. They MUST also redirect other relevant packets (e.g., such as those with Router Alert Option set) to their CE. The CEs MUST be able to configure the packet redirection information/filters on the FEs. The CEs MUST also be able to create packets and have its FEs deliver them.
8) FEs必须能够将寻址到其接口的控制数据包（如RIP、OSPF消息）重定向到CE。他们还必须将其他相关数据包（例如，设置了路由器警报选项的数据包）重定向到他们的CE。CEs必须能够在FEs上配置数据包重定向信息/过滤器。CEs还必须能够创建数据包，并让其FEs交付数据包。
9) Any proposed ForCES architectures MUST explain how that architecture supports all of the router functions as defined in [RFC1812]. IPv4 Forwarding functions such IP header validation, performing longest prefix match algorithm, TTL decrement, Checksum calculation, generation of ICMP error messages, etc defined in RFC 1812 should be explained.
9) 任何建议的ForCES架构必须解释该架构如何支持[RFC1812]中定义的所有路由器功能。应解释RFC 1812中定义的IPv4转发功能，如IP报头验证、执行最长前缀匹配算法、TTL减量、校验和计算、生成ICMP错误消息等。
10) In a ForCES NE, the CE(s) MUST be able to learn the topology by which the FEs in the NE are connected.
10） 在强制网元中，CE必须能够了解网元中FEs的连接拓扑。
11) The ForCES NE architecture MUST be capable of supporting (i.e., must scale to) at least hundreds of FEs and tens of thousands of ports.
11） ForCES NE架构必须能够支持（即，必须扩展到）至少数百个FE和数万个端口。
12) The ForCES architecture MUST allow FEs AND CEs to join and leave NEs dynamically.
12） ForCES架构必须允许FEs和CEs动态加入和离开网元。
13) The ForCES NE architecture MUST support multiple CEs and FEs. However, coordination between CEs is out of scope of ForCES.
13） ForCES NE架构必须支持多个CE和FEs。然而，CEs之间的协调超出了部队的范围。
14) For pre-association phase setup, monitoring, configuration issues, it MAY be useful to use standard management mechanisms for CEs and FEs. The ForCES architecture and requirements do not preclude this. In general, for post-association phase, most management tasks SHOULD be done through interaction with the CE. In certain conditions (e.g., CE/FE disconnection), it may be useful to allow management tools (e.g., SNMP) to be used to diagnose and repair problems. The following guidelines MUST be observed:
14） 对于关联前阶段的设置、监视和配置问题，使用CEs和FEs的标准管理机制可能很有用。部队架构和要求并不排除这一点。一般来说，对于关联后阶段，大多数管理任务都应该通过和CE的交互来完成。在某些情况下（例如CE/FE断开连接），允许使用管理工具（例如SNMP）来诊断和修复问题可能很有用。必须遵守以下准则：
1. The ability for a management tool (e.g., SNMP) to be used to read (but not change) the state of FE SHOULD NOT be precluded. 2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to change the state of a FE in a manner that affects overall NE behavior without the CE being notified.
1. 不应排除使用管理工具（如SNMP）读取（但不更改）FE状态的能力。2.在未通知CE的情况下，管理工具（如SNMP等）不得以影响整个网元行为的方式更改FE的状态。
The variety of FE functionality that the ForCES architecture allows poses a potential problem for CEs. In order for a CE to effectively control a FE, the CE must understand how the FE processes packets. We therefore REQUIRE that a FE model be created that can express the logical packet processing capabilities of a FE. This model will be used in the ForCES protocol to describe FE capabilities (see Section 6, requirement #1). The FE model MUST define both a capability model and a state model, which expresses the current configuration of the device. The FE model MUST also support multiple FEs in the NE architecture.
ForCES体系结构允许的各种FE功能为CEs带来了潜在问题。为了让CE有效地控制FE，CE必须了解FE如何处理数据包。因此，我们需要创建一个FE模型来表示FE的逻辑数据包处理能力。该模型将在部队协议中用于描述FE能力（见第6节，需求#1）。FE模型必须定义能力模型和状态模型，以表示设备的当前配置。FE模型还必须支持NE架构中的多个FE。
The FE model MUST express what logical functions can be applied to packets as they pass through a FE. Logical functions are the packet processing functions that are applied to the packets as they are forwarded through a FE. Examples of logical functions are layer 3 forwarding, firewall, NAT, and shaping. Section 5.5 defines the minimal set of logical functions that the FE Model MUST support.
FE模型必须表示当数据包通过FE时可以应用于数据包的逻辑函数。逻辑功能是当数据包通过FE转发时应用于数据包的数据包处理功能。逻辑功能的示例包括第3层转发、防火墙、NAT和整形。第5.5节定义了FE模型必须支持的最小逻辑功能集。
The FE model MUST be capable of supporting/allowing variations in the way logical functions are implemented on a FE. For example, on a certain FE the forwarding logical function might have information about both the next hop IP address and the next hop MAC address, while on another FE these might be implemented as separate logical functions. Another example would be NAT functionality that can have several flavors such as Traditional/Outbound NAT, Bi-directional NAT, Twice NAT, and Multihomed NAT [RFC2663]. The model must be flexible enough to allow such variations in functions.
FE模型必须能够支持/允许在FE上实现逻辑功能的方式发生变化。例如，在某个FE上，转发逻辑功能可能具有关于下一跳IP地址和下一跳MAC地址的信息，而在另一个FE上，这些可能作为单独的逻辑功能实现。另一个例子是NAT功能，可以有几种风格，如传统/出站NAT、双向NAT、两次NAT和多宿NAT[RFC2663]。模型必须足够灵活，以允许功能上的这种变化。
The model MUST be capable of describing the order in which these logical functions are applied in a FE. The ordering of logical functions is important in many cases. For example, a NAT function may change a packet's source or destination IP address. Any number of other logical functions (e.g., layer 3 forwarding, ingress/egress firewall, shaping, and accounting) may make use of the source or destination IP address when making decisions. The CE needs to know whether to configure these logical functions with the pre-NAT or post-NAT IP address. Furthermore, the model MUST be capable of expressing multiple instances of the same logical function in a FE's processing path. Using NAT again as an example, one NAT function is typically performed before the forwarding decision (packets arriving externally have their public addresses replaced with private addresses) and one NAT function is performed after the forwarding decision (for packets exiting the domain, their private addresses are replaced by public ones).
模型必须能够描述这些逻辑函数在FE中应用的顺序。在许多情况下，逻辑函数的顺序很重要。例如，NAT功能可以更改数据包的源或目标IP地址。任何数量的其他逻辑功能（例如，第3层转发、入口/出口防火墙、整形和记帐）可在作出决策时使用源或目的地IP地址。CE需要知道是否使用前NAT或后NAT IP地址配置这些逻辑功能。此外，该模型必须能够表示FE处理路径中相同逻辑函数的多个实例。再次使用NAT作为示例，通常在转发决策之前执行一个NAT功能（外部到达的数据包的公共地址替换为私有地址），在转发决策之后执行一个NAT功能（对于退出域的数据包，其私有地址替换为公共地址）。
Finally, the FE model SHOULD provide a flexible infrastructure in which new logical functions and new classification, action, and parameterization data can be easily added. In addition, the FE model MUST be capable of describing the types of statistics gathered by each logical function.
最后，FE模型应该提供一个灵活的基础设施，在其中可以轻松添加新的逻辑功能和新的分类、操作和参数化数据。此外，FE模型必须能够描述每个逻辑函数收集的统计数据类型。
The rest of this section defines a minimal set of logical functions that any FE model MUST support. This minimal set DOES NOT imply that all FEs must provide this functionality. Instead, these requirements only specify that the model must be capable of expressing the capabilities that FEs may choose to provide.
本节的其余部分定义了任何FE模型必须支持的最小逻辑函数集。此最小集合并不意味着所有FEs都必须提供此功能。相反，这些需求只指定模型必须能够表达FEs可能选择提供的功能。
1) Port Functions The FE model MUST be capable of expressing the number of ports on the device, the static attributes of each port (e.g., port type, link speed), and the configurable attributes of each port (e.g., IP address, administrative status).
1) 端口功能FE模型必须能够表示设备上的端口数量、每个端口的静态属性（例如，端口类型、链路速度）以及每个端口的可配置属性（例如，IP地址、管理状态）。
2) Forwarding Functions The FE model MUST be capable of expressing the data that can be used by the forwarding function to make a forwarding decision. Support for IPv4 and IPv6 unicast and multicast forwarding functions MUST be provided by the model.
2) 转发功能FE模型必须能够表达转发功能可用于做出转发决策的数据。模型必须提供对IPv4和IPv6单播和多播转发功能的支持。
3) QoS Functions The FE model MUST allow a FE to express its QoS capabilities in terms of, e.g., metering, policing, shaping, and queuing functions. The FE model MUST be capable of expressing the use of these functions to provide IntServ or DiffServ functionality as described in [RFC2211], [RFC2212], [RFC2215], [RFC2475], and [RFC3290].
3) QoS功能FE模型必须允许FE在计量、监管、成形和排队功能等方面表达其QoS功能。FE模型必须能够表达这些函数的使用，以提供[RFC2211]、[RFC2212]、[RFC2215]、[RFC2475]和[RFC3290]中所述的IntServ或DiffServ功能。
4) Generic Filtering Functions The FE model MUST be capable of expressing complex sets of filtering functions. The model MUST be able to express the existence of these functions at arbitrary points in the sequence of a FE's packet processing functions. The FE model MUST be capable of expressing a wide range of classification abilities from single fields (e.g., destination address) to arbitrary n-tuples. Similarly, the FE model MUST be capable of expressing what actions these filtering functions can perform on packets that the classifier matches.
4) 通用过滤函数FE模型必须能够表达复杂的过滤函数集。该模型必须能够表示FE数据包处理函数序列中任意点上这些函数的存在性。FE模型必须能够表达从单个字段（例如，目标地址）到任意n元组的各种分类能力。类似地，FE模型必须能够表示这些过滤函数可以对分类器匹配的数据包执行哪些操作。
5) Vendor-Specific Functions The FE model SHOULD be extensible so that new, currently unknown FE functionality can be expressed. The FE Model SHOULD NOT be extended to express standard/common functions in a proprietary manner. This would NOT be ForCES compliant.
5) 特定于供应商的功能FE模型应具有可扩展性，以便能够表达当前未知的新FE功能。FE模型不应扩展为以专有方式表示标准/通用功能。这将不符合部队的要求。
6) High-Touch Functions The FE model MUST be capable of expressing the encapsulation and tunneling capabilities of a FE. The FE model MUST support functions
6) 高接触功能FE模型必须能够表达FE的封装和隧穿能力。FE模型必须支持功能
that mark the class of service that a packet should receive (i.e., IPv4 header TOS octet or the IPv6 Traffic Class octet). The FE model MAY support other high touch functions (e.g., NAT, ALG).
标记数据包应接收的服务类别（即IPv4报头TOS八位字节或IPv6流量类别八位字节）。FE模型可支持其他高接触功能（例如NAT、ALG）。
7) Security Functions The FE model MUST be capable of expressing the types of encryption that may be applied to packets in the forwarding path.
7) 安全功能FE模型必须能够表示可应用于转发路径中的数据包的加密类型。
8) Off-loaded Functions Per-packet processing can leave state in the FE, so that logical functions executed during packet processing can perform in a consistent manner (for instance, each packet may update the state of the token bucket occupancy of a give policer). In addition, the FE Model MUST allow logical functions to execute asynchronously from packet processing, according to a certain finite-state machine, in order to perform functions that are, for instance, off-loaded from the CE to the FE. The FE model MUST be capable of expressing these asynchronous functions. Examples of such functions include the finite-state machine execution required by TCP termination or OSPF Hello processing, triggered not only by packet events, but by timer events as well. This Does NOT mean off-loading of any piece of code to an FE, just that the FE Model should be able to express existing Off-loaded functions on an FE.
8) 每个分组处理的卸载功能可以在FE中留下状态，以便在分组处理期间执行的逻辑功能可以以一致的方式执行（例如，每个分组可以更新给定策略的令牌桶占用的状态）。此外，FE模型必须允许逻辑功能根据特定的有限状态机从数据包处理异步执行，以便执行从CE卸载到FE的功能。FE模型必须能够表达这些异步函数。此类功能的示例包括TCP终止或OSPF Hello处理所需的有限状态机执行，不仅由数据包事件触发，还由计时器事件触发。这并不意味着向FE卸载任何代码，只是FE模型应该能够表达FE上现有的卸载函数。
9) IPFLOW/PSAMP Functions Several applications such as, Usage-based Accounting, Traffic engineering, require flow-based IP traffic measurements from Network Elements. [IPFLOW] defines architecture for IP traffic flow monitoring, measuring and exporting. The FE model SHOULD be able to express metering functions and flow accounting needed for exporting IP traffic flow information. Similarly to support measurement-based applications, [PSAMP] describes a framework to define a standard set of capabilities for network elements to sample subsets of packets by statistical and other methods. The FE model SHOULD be able to express statistical packet filtering functions and packet information needed for supporting packet sampling applications.
9) IPFLOW/PSAMP功能一些应用程序，如基于使用情况的计费、流量工程，需要从网络元素进行基于流量的IP流量测量。[IPFLOW]定义了IP流量监视、测量和导出的体系结构。FE模型应能够表示导出IP流量信息所需的计量功能和流量计算。类似地，为了支持基于测量的应用程序，[PSAMP]描述了一个框架，用于定义一组标准功能，以便网络元素通过统计和其他方法对数据包子集进行采样。FE模型应能够表达支持数据包采样应用所需的统计数据包过滤功能和数据包信息。
This section specifies some of the requirements that the ForCES protocol MUST meet.
本节规定了ForCES协议必须满足的一些要求。
1) Configuration of Modeled Elements The ForCES protocol MUST allow the CEs to determine the capabilities of each FE. These capabilities SHALL be expressed using the FE model whose requirements are defined in Section 5. Furthermore, the protocol MUST provide a means for the CEs to control all the FE
1) 建模元素的配置部队协议必须允许CEs确定每个FE的能力。这些能力应使用FE模型表示，其要求见第5节。此外，协议必须提供CEs控制所有FE的方法
capabilities that are discovered through the FE model. The protocol MUST be able to add/remove classification/action entries, set/delete parameters, query statistics, and register for and receive events.
通过FE模型发现的能力。协议必须能够添加/删除分类/操作条目、设置/删除参数、查询统计信息以及注册和接收事件。
2) Support for Secure Communication a) FE configuration will contain information critical to the functioning of a network (e.g., IP Forwarding Tables). As such, it MUST be possible to ensure the integrity of all ForCES protocol messages and protect against man-in-the-middle attacks. b) FE configuration information may also contain information derived from business relationships (e.g., service level agreements). Because of the confidential nature of the information, it MUST be possible to secure (make private) all ForCES protocol messages. c) In order to ensure that authorized CEs and FEs are participating in a NE and defend against CE or FE impersonation attacks, the ForCES architecture MUST select a means of authentication for CEs and FEs. d) In some deployments ForCES is expected to be deployed between CEs and FEs connected to each other inside a box over a backplane, where physical security of the box ensures that man-in-the-middle, snooping, and impersonation attacks are not possible. In such scenarios the ForCES architecture MAY rely on the physical security of the box to defend against these attacks and protocol mechanisms May be turned off. e) In the case when CEs and FEs are connected over a network, security mechanisms MUST be specified or selected that protect the ForCES protocol against such attacks. Any security solution used for ForCES MUST specify how it deals with such attacks.
2) 对安全通信的支持a）FE配置将包含对网络功能至关重要的信息（如IP转发表）。因此，必须能够确保所有部队协议消息的完整性，并防止中间人攻击。b） FE配置信息还可能包含从业务关系（例如，服务级别协议）衍生的信息。由于信息的机密性，必须能够保护（保密）所有ForCES协议消息。c） 为了确保授权的CE和FEs参与网元并防御CE或FE模拟攻击，部队架构必须为CE和FEs选择身份验证方式。d） 在某些部署中，部队预计将部署在通过背板的机箱内相互连接的CEs和FEs之间，其中机箱的物理安全性确保不可能进行中间人、窥探和模拟攻击。在这种情况下，部队体系结构可能依赖机箱的物理安全性来抵御这些攻击，协议机制可能会关闭。e） 在CEs和FEs通过网络连接的情况下，必须指定或选择安全机制，以保护ForCES协议免受此类攻击。部队使用的任何安全解决方案都必须指定如何应对此类攻击。
3) Scalability The ForCES protocol MUST be capable of supporting (i.e., must scale to) at least hundreds of FEs and tens of thousands of ports. For example, the ForCES protocol field sizes corresponding to FE or port numbers SHALL be large enough to support the minimum required numbers. This requirement does not relate to the performance of a NE as the number of FEs or ports in the NE grows.
3) 可扩展性ForCES协议必须能够支持（即必须扩展到）至少数百个FEs和数万个端口。例如，对应于FE或端口号的ForCES协议字段大小应足够大，以支持所需的最小数量。随着网元中FEs或端口数量的增加，此要求与网元的性能无关。
4) Multihop When the CEs and FEs are separated beyond a single L3 routing hop, the ForCES protocol will make use of an existing RFC2914 compliant L4 protocol with adequate reliability, security and congestion control (e.g., TCP, SCTP) for transport purposes.
4) 多跳当CEs和FEs在单个L3路由跳之外分离时，ForCES协议将利用现有的RFC2914兼容L4协议，具有足够的可靠性、安全性和拥塞控制（例如TCP、SCTP）用于传输目的。
5) Message Priority The ForCES protocol MUST provide a means to express the protocol message priorities.
5) 消息优先级ForCES协议必须提供一种表示协议消息优先级的方法。
6) Reliability a) The ForCES protocol will be used to transport information that requires varying levels of reliability. By strict or robust reliability in this requirement we mean, no losses, no corruption, no re-ordering of information being transported and delivery in a timely fashion. b) Some information or payloads, such as redirected packets or packet sampling, may not require robust reliability (can tolerate some degree of losses). For information of this sort, ForCES MUST NOT be restricted to strict reliability. c) Payloads such as configuration information, e.g., ACLs, FIB entries, or FE capability information (described in section 6, (1)) are mission critical and must be delivered in a robust reliable fashion. Thus, for information of this sort, ForCES MUST either provide built-in protocol mechanisms or use a reliable transport protocol for achieving robust/strict reliability. d) Some information or payloads, such as heartbeat packets that may be used to detect loss of association between CE and FEs (see section 6, (8)), may prefer timeliness over reliable delivery. For information of this sort, ForCES MUST NOT be restricted to strict reliability. e) When ForCES is carried over multi-hop IP networks, it is a requirement that ForCES MUST use a [RFC2914]-compliant transport protocol. f) In cases where ForCES is not running over an IP network such as an Ethernet or cell fabric between CE and FE, then reliability still MUST be provided when carrying critical information of the types specified in (c) above, either by the underlying link/network/transport layers or by built-in protocol mechanisms.
6) 可靠性a）ForCES协议将用于传输需要不同可靠性级别的信息。在这一要求中，严格或稳健的可靠性意味着不丢失、不损坏、不重新订购及时传输和交付的信息。b） 某些信息或有效载荷，如重定向数据包或数据包采样，可能不需要可靠的可靠性（可以承受一定程度的损失）。对于这类信息，部队不应受到严格可靠性的限制。c） 有效载荷，如配置信息，例如ACL、FIB条目或FE能力信息（如第6（1）节所述）是任务关键型的，必须以可靠的方式交付。因此，对于此类信息，部队必须提供内置协议机制或使用可靠的传输协议，以实现稳健/严格的可靠性。d） 一些信息或有效载荷，例如可用于检测CE和FEs之间关联丢失的心跳数据包（见第6节，（8）），可能更喜欢及时性而不是可靠的交付。对于这类信息，部队不应受到严格可靠性的限制。e） 当部队通过多跳IP网络传输时，部队必须使用符合[RFC2914]的传输协议。f） 如果部队未在IP网络（如CE和FE之间的以太网或蜂窝结构）上运行，则在承载上述（c）中规定类型的关键信息时，仍然必须通过底层链路/网络/传输层或内置协议机制提供可靠性。
7) Interconnect Independence The ForCES protocol MUST support a variety of interconnect technologies. (refer to section 4, requirement #1)
7) 互连独立性ForCES协议必须支持多种互连技术。（参考第4节，要求#1）
8) CE redundancy or CE failover The ForCES protocol MUST support mechanisms for CE redundancy or CE failover. This includes the ability for CEs and FEs to determine when there is a loss of association between them, ability to restore association and efficient state (re)synchronization mechanisms. This also includes the ability to preset the actions an FE will take in
8) CE冗余或CE故障切换ForCES协议必须支持CE冗余或CE故障切换机制。这包括CE和FEs确定它们之间何时失去关联的能力、恢复关联的能力以及有效的状态（重新）同步机制。这还包括预设FE将采取的行动的能力
reaction to loss of association to its CE, e.g., whether the FE will continue to forward packets or whether it will halt operations. (refer to section 4, requirement #7)
对其CE关联丢失的反应，例如FE是否将继续转发数据包或是否将停止操作。（参考第4节，要求#7）
9) Packet Redirection/Mirroring a) The ForCES protocol MUST define a way to redirect packets from the FE to the CE and vice-versa. Packet redirection terminates any further processing of the redirected packet at the FE. b) The ForCES protocol MUST define a way to mirror packets from the FE to the CE. Mirroring allows the packet duplicated by the FE at the mirroring point to be sent to the CE while the original packet continues to be processed by the FE.
9) 数据包重定向/镜像a）ForCES协议必须定义将数据包从FE重定向到CE的方法，反之亦然。包重定向终止FE处对重定向包的任何进一步处理。b） ForCES协议必须定义将数据包从FE镜像到CE的方法。镜像允许FE在镜像点复制的数据包发送到CE，同时FE继续处理原始数据包。
Examples of packets that may be redirected or mirrored include control packets (such as RIP, OSPF messages) addressed to the interfaces or any other relevant packets (such as those with Router Alert Option set). The ForCES protocol MUST also define a way for the CE to configure the behavior of a) and b) (above), to specify which packets are affected by each.
可重定向或镜像的分组的示例包括寻址到接口的控制分组（例如RIP、OSPF消息）或任何其他相关分组（例如设置了路由器警报选项的分组）。ForCES协议还必须为CE定义一种方式来配置a）和b）（如上）的行为，以指定哪些数据包受各自的影响。
10) Topology Exchange The ForCES protocol or information carried in the ForCES protocol MUST allow those FEs which have inter-FE topology information to provide that information to the CE(s).
10） 拓扑交换部队协议或部队协议中包含的信息必须允许具有FE间拓扑信息的FE向CE提供该信息。
11) Dynamic Association The ForCES protocol MUST allow CEs and FEs to join and leave a NE dynamically. (refer to section 4, requirement #12)
11） 动态关联强制协议必须允许CEs和FEs动态加入和离开网元。（参考第4节，要求#12）
12) Command Bundling The ForCES protocol MUST be able to group an ordered set of commands to a FE. Each such group of commands SHOULD be sent to the FE in as few messages as possible. Furthermore, the protocol MUST support the ability to specify if a command group MUST have all-or-nothing semantics.
12） 命令绑定ForCES协议必须能够将一组有序的命令分组到FE。每一组这样的命令都应该以尽可能少的消息发送给FE。此外，协议必须支持指定命令组是否必须具有全部或无语义的能力。
13) Asynchronous Event Notification The ForCES protocol MUST be able to asynchronously notify the CE of events on the FE such as failures or change in available resources or capabilities. (refer to section 4, requirement #6)
13） 异步事件通知ForCES协议必须能够异步通知CE FE上的事件，如可用资源或功能的故障或更改。（参考第4节，要求#6）
14) Query Statistics The ForCES protocol MUST provide a means for the CE to be able to query statistics (monitor performance) from the FE.
14） 查询统计数据ForCES协议必须为CE提供一种能够从FE查询统计数据（监控性能）的方法。
15) Protection against Denial of Service Attacks (based on CPU overload or queue overflow) Systems utilizing the ForCES protocol can be attacked using denial of service attacks based on CPU overload or queue overflow. The ForCES protocol could be exploited by such attacks to cause the CE to become unable to control the FE or appropriately communicate with other routers and systems. The ForCES protocol MUST therefore provide mechanisms for controlling FE capabilities that can be used to protect against such attacks. FE capabilities that MUST be manipulated via ForCES include the ability to install classifiers and filters to detect and drop attack packets, as well as to be able to install rate limiters that limit the rate of packets which appear to be valid but may be part of an attack (e.g., bogus BGP packets).
15） 针对拒绝服务攻击（基于CPU过载或队列溢出）的保护利用ForCES协议的系统可以使用基于CPU过载或队列溢出的拒绝服务攻击进行攻击。此类攻击可能利用ForCES协议，导致CE无法控制FE或与其他路由器和系统进行适当通信。因此，ForCES协议必须提供控制FE能力的机制，以防止此类攻击。必须通过武力操纵的FE能力包括安装分类器和过滤器以检测和丢弃攻击数据包的能力，以及能够安装速率限制器以限制看似有效但可能是攻击一部分的数据包的速率（例如，伪造BGP数据包）。
[RFC3290] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for DiffServ Routers", RFC 3290, May 2002.
[RFC3290]Bernet，Y.，Blake，S.，Grossman，D.和A.Smith，“区分服务路由器的非正式管理模型”，RFC 32902002年5月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211]Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[RFC2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[RFC2215]Shenker，S.和J.Wroclawski，“综合业务网元的一般特征参数”，RFC 2215，1997年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weisss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weisss，“差异化服务架构”，RFC 24751998年12月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 14, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 14，RFC 2914，2000年9月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC3532] Anderson, T. and J. Buerkle, "Requirements for the Dynamic Partitioning of Switching Elements", RFC 3532, May 2003.
[RFC3532]Anderson，T.和J.Buerkle，“开关元件动态分区的要求”，RFC 3532，2003年5月。
[IPFLOW] Quittek, et al., "Requirements for IP Flow Information Export", Work in Progress, February 2003.
[IPFLOW]Quittek等人，“IP流信息导出的要求”，正在进行的工作，2003年2月。
[PSAMP] Duffield, et al., "A Framework for Passive Packet Measurement ", Work in Progress, March 2003.
[PSAMP]Duffield等人，“被动数据包测量框架”，正在进行的工作，2003年3月。
See architecture requirement #5 and protocol requirement #2.
参见架构要求5和协议要求2。
This document was written by the ForCES Requirements design team:
本文件由部队需求设计团队编写：
Todd A. Anderson (Editor)
托德·安德森（编辑）
Ed Bowen IBM Zurich Research Laboratory Saumerstrasse 4 CH-8803 Rueschlikon Switzerland
Ed Bowen IBM苏黎世研究实验室Saumerstrasse 4 CH-8803 Rueschlikon瑞士
Phone: +41 1 724 83 68
EMail: edbowen@us.ibm.com
Phone: +41 1 724 83 68
EMail: edbowen@us.ibm.com
Ram Dantu Department of Computer Science University of North Texas, Denton, Texas, 76203
RAM丹徒北得克萨斯大学计算机系，丹顿，德克萨斯，76203
Phone: 940 565 2822 EMail: rdantu@unt.edu
电话：9405652822电子邮件：rdantu@unt.edu
Avri Doria ETRI 161 Gajeong-dong, Yuseong-gu Deajeon 305-350 Korea
Avri Doria ETRI 161，韩国玉成古道田Gajeong dong 305-350
EMail: avri@acm.org
EMail: avri@acm.org
Ram Gopal Nokia Research Center 5, Wayside Road, Burlington, MA 01803
马萨诸塞州伯灵顿韦赛德路5号Ram Gopal诺基亚研究中心01803
Phone: 1-781-993-3685 EMail: ram.gopal@nokia.com
电话：1-781-993-3685电子邮件：ram。gopal@nokia.com
Jamal Hadi Salim Znyx Networks Ottawa, Ontario Canada
加拿大安大略省渥太华Jamal Hadi Salim Znyx网络公司
EMail: hadi@znyx.com
EMail: hadi@znyx.com
Hormuzd Khosravi (Editor)
霍姆兹德·科斯拉维（编辑）
Muneyb Minhazuddin Avaya Inc. 123, Epping road, North Ryde, NSW 2113, Australia Phone: +61 2 9352 8620 EMail: muneyb@avaya.com
Muneyb Minhazuddin Avaya Inc.地址：澳大利亚新南威尔士州莱德北部埃平路123号邮编：2113电话：+61 2 9352 8620电子邮件：muneyb@avaya.com
Margaret Wasserman Nokia Research Center 5 Wayside Road Burlington, MA 01803 Phone: +1 781 993 3858 EMail: margaret.wasserman@nokia.com
Margaret Wasserman诺基亚研究中心5 Wayside Road Burlington，MA 01803电话：+1 781 993 3858电子邮件：Margaret。wasserman@nokia.com
The authors would like to thank Vip Sharma and Lily Yang for their valuable contributions.
作者要感谢Vip Sharma和Lily Yang的宝贵贡献。
Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
美国希尔斯伯勒第25大道东北2111号霍尔木兹德科斯拉维英特尔公司，邮编：97124
Phone: +1 503 264 0334
EMail: hormuzd.m.khosravi@intel.com
Phone: +1 503 264 0334
EMail: hormuzd.m.khosravi@intel.com
Todd A. Anderson Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
美国希尔斯伯勒第25大道东北2111号托德·A·安德森英特尔公司，邮编：97124
Phone: +1 503 712 1760
EMail: todd.a.anderson@intel.com
Phone: +1 503 712 1760
EMail: todd.a.anderson@intel.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。