Network Working Group M. Barnes, Ed.
Request for Comments: 4097 Nortel Networks
Category: Informational June 2005
Network Working Group M. Barnes, Ed.
Request for Comments: 4097 Nortel Networks
Category: Informational June 2005
Middlebox Communications (MIDCOM) Protocol Evaluation
中间盒通信（MIDCOM）协议评估
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation.
本文档评估了SNMP（简单网络管理协议）、RSIP（领域特定互联网协议）、Megaco、Diameter和COPS（公共开放策略服务）作为MIDCOM（中间包通信）协议的适用性。提供了针对MIDCOM要求和MIDCOM框架提出的每个协议的摘要。详细说明了每个协议对每个要求的符合性。结论总结了每种方案在评估中的表现。
Table of Contents
目录
Overview.......................................................... 2
Conventions Used in This Document................................. 3
1. Protocol Proposals............................................ 3
1.1. SNMP.................................................... 3
1.2. RSIP.................................................... 5
1.3. Megaco.................................................. 7
1.4. Diameter................................................ 8
1.5. COPS.................................................... 10
2. Item Level Compliance Evaluation.............................. 11
2.1. Protocol Machinery...................................... 11
2.2. Protocol Semantics...................................... 20
2.3. General Security Requirements........................... 27
3. Conclusions................................................... 29
4. Security Considerations....................................... 30
5. References.................................................... 31
5.1. Normative References.................................... 31
5.2. Informative References.................................. 33
6. Acknowledgements.............................................. 33
Overview.......................................................... 2
Conventions Used in This Document................................. 3
1. Protocol Proposals............................................ 3
1.1. SNMP.................................................... 3
1.2. RSIP.................................................... 5
1.3. Megaco.................................................. 7
1.4. Diameter................................................ 8
1.5. COPS.................................................... 10
2. Item Level Compliance Evaluation.............................. 11
2.1. Protocol Machinery...................................... 11
2.2. Protocol Semantics...................................... 20
2.3. General Security Requirements........................... 27
3. Conclusions................................................... 29
4. Security Considerations....................................... 30
5. References.................................................... 31
5.1. Normative References.................................... 31
5.2. Informative References.................................. 33
6. Acknowledgements.............................................. 33
Appendix A - SNMP Overview........................................ 34
Appendix B - RSIP with Tunneling.................................. 35
Appendix C - Megaco Modeling Approach............................. 37
Appendix D - Diameter IPFilter Rule............................... 39
Contributors ..................................................... 42
Appendix A - SNMP Overview........................................ 34
Appendix B - RSIP with Tunneling.................................. 35
Appendix C - Megaco Modeling Approach............................. 37
Appendix D - Diameter IPFilter Rule............................... 39
Contributors ..................................................... 42
Overview
概述
This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. This evaluation provides overviews of the protocols and general statements of applicability based upon the MIDCOM framework [2] and requirements [1] documents.
本文档评估了SNMP（简单网络管理协议）、RSIP（领域特定互联网协议）、Megaco、Diameter和COPS（公共开放策略服务）作为MIDCOM（中间件通信）协议的适用性。该评估提供了基于MIDCOM框架[2]和需求[1]文件的协议概述和适用性一般声明。
The process for the protocol evaluation was fairly straightforward as individuals volunteered to provide an individual document evaluating a specific protocol. Thus, some protocols that might be considered as reasonably applicable as the MIDCOM protocol are not evaluated in this document since there were no volunteers to champion the work. The individual protocol documents for which there were volunteers were submitted for discussion on the list with feedback being incorporated into an updated document. The updated versions of these documents formed the basis for the content of this WG document.
方案评估过程相当简单，因为个人自愿提供评估特定方案的个人文件。因此，由于没有志愿者支持这项工作，因此本文件未对一些可能被视为合理适用于MIDCOM协议的协议进行评估。有志愿者参与的个别方案文件已提交清单讨论，反馈意见已纳入更新文件。这些文件的更新版本构成了本工作组文件内容的基础。
Section 1 contains a list of the proposed protocols submitted for the purposes of the protocol evaluation with some background information on the protocols and similarities and differences with regards to the applicability to the framework [2] provided.
第1节包含为协议评估目的而提交的拟议协议列表，以及协议的一些背景信息，以及与所提供框架[2]适用性相关的异同点。
Section 2 provides the item level evaluation of the proposed protocols against the Requirements [1].
第2节提供了针对需求[1]的拟议协议的项目级评估。
Section 3 provides a summary of the evaluation. A table containing a numerical breakdown for each of the protocols, with regards to its applicability to the requirements, for the following categories is provided: Fully met, Partially met through the use of extensions, Partially met through other changes to the protocol, or Failing to be met. This summary is not meant to provide a conclusive statement of the suitability of the protocols, but rather to provide information to be considered as input into the overall protocol decision process.
第3节提供了评估的摘要。提供了一个表格，其中包含每个协议的数字细分，关于其对以下类别要求的适用性：完全满足、通过使用扩展部分满足、通过协议的其他变更部分满足或未能满足。本总结并非旨在提供协议适用性的结论性陈述，而是提供信息，作为整个协议决策过程的输入。
In order for this document to serve as a complete evaluation of the protocols, some of the background information and more detailed aspects of the proposals documenting enhancements and applications of the protocols to comply with the MIDCOM framework and requirements are included in Appendices.
为了使本文件成为协议的完整评估，附录中包含了一些背景信息和提案的更详细方面，这些提案记录了协议的增强和应用，以符合MIDCOM框架和要求。
Conventions Used in this Document
本文件中使用的公约
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 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[4]中的描述进行解释。
The following protocols were submitted to the MIDCOM WG for consideration:
以下协议已提交MIDCOM工作组审议：
o SNMP o RSIP o Megaco o Diameter o COPS
o SNMP o RSIP o Megaco o直径o COP
The following provides an overview of each of the protocols and the applicability of each protocol to the MIDCOM framework.
以下概述了每种协议以及每种协议对MIDCOM框架的适用性。
This section provides a general statement with regards to the applicability of SNMP as the MIDCOM protocol. A general overview and some specific details of SNMP are provided in Appendix A. This evaluation of SNMP is specific to SNMPv3, which provides the security required for MIDCOM usage. SNMPv1 and SNMPv2c would be inappropriate for MIDCOM since they have been declared Historic, and because their messages have only trivial security. Some specifics with regards to existing support for NAT and Firewall Control are provided in section 1.1.2. The differences between the SNMP framework and the MIDCOM framework are addressed in section 1.1.3.
本节提供了有关SNMP作为MIDCOM协议适用性的一般说明。附录A中提供了SNMP的一般概述和一些具体细节。此SNMP评估特定于SNMPv3，它提供了MIDCOM使用所需的安全性。SNMPv1和SNMPv2c对于MIDCOM来说是不合适的，因为它们已经被宣布为历史性的，并且因为它们的消息只有微不足道的安全性。第1.1.2节提供了有关NAT和防火墙控制的现有支持的一些细节。SNMP框架和MIDCOM框架之间的差异在第1.1.3节中介绍。
The primary advantages of SNMPv3 are that it is a mature, well understood protocol, currently deployed in various scenarios, with mature toolsets available for SNMP managers and agents.
SNMPv3的主要优点是，它是一个成熟、易于理解的协议，目前部署在各种场景中，并为SNMP管理器和代理提供了成熟的工具集。
Application intelligence is captured in MIB modules, rather than in the messaging protocol. MIB modules define a data model of the information that can be collected and configured for a managed functionality. The SNMP messaging protocol transports the data in a standardized format without needing to understand the semantics of the data being transferred. The endpoints of the communication understand the semantics of the data.
应用程序智能在MIB模块中捕获，而不是在消息传递协议中捕获。MIB模块定义了可以为托管功能收集和配置的信息的数据模型。SNMP消息传递协议以标准格式传输数据，而无需了解所传输数据的语义。通信的端点理解数据的语义。
Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly due to variations in configuration requirements across vendors, few MIB modules have been developed that enable standardized configuration of managed devices across vendors. Since monitoring can be done using only a least-common-denominator subset of information across vendors, many MIB modules have been developed to provide standardized monitoring of managed devices. As a result, SNMP has been used primarily for monitoring rather than for configuring network nodes.
部分原因是SNMPv1和SNMPv2c中缺乏安全性，部分原因是不同供应商的配置要求不同，因此开发的MIB模块很少能够跨供应商对受管设备进行标准化配置。由于监控只能使用供应商间信息的最小公分母子集来完成，因此开发了许多MIB模块来提供受管设备的标准化监控。因此，SNMP主要用于监视而不是配置网络节点。
SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c versions. Specifically, SNMPv3 shares the separation of data modeling (MIBs) from the protocol to transfer data, so all existing MIBs can be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, and it shares operations and transport with SNMPv2c. The major difference between SNMPv3 and earlier versions is the addition of strong message security and controlled access to data.
SNMPv3基于广泛部署的SNMPv1和SNMPv2c版本的设计。具体来说，SNMPv3共享数据建模（MIB）与传输数据协议的分离，因此所有现有MIB都可以与SNMPv3一起使用。SNMPv3还使用SMIv2标准，它与SNMPv2c共享操作和传输。SNMPv3与早期版本的主要区别在于增加了强大的消息安全性和对数据的受控访问。
SNMPv3 uses the architecture detailed in RFC 3411 [5], where all SNMP entities are capable of performing certain functions, such as the generation of requests, response to requests, the generation of asynchronous notifications, the receipt of notifications, and the proxy-forwarding of SNMP messages. SNMP is used to read and manipulate virtual databases of managed-application-specific operational parameters and statistics, which are defined in MIB modules.
SNMPv3使用RFC 3411[5]中详述的体系结构，其中所有SNMP实体都能够执行某些功能，例如生成请求、响应请求、生成异步通知、接收通知和代理转发SNMP消息。SNMP用于读取和操作MIB模块中定义的托管应用程序特定操作参数和统计信息的虚拟数据库。
For configuring NATs, a NAT MIB module [16] has been developed. The NAT MIB module meets all of the MIDCOM requirements concerning NAT control with the exception of grouping of policy rules (requirement 2.2.3.). In order to support this, an additional grouping table in the NAT MIB module is required.
为了配置NAT，开发了NAT MIB模块[16]。NAT MIB模块满足与NAT控制有关的所有MIDCOM要求，但策略规则分组除外（要求2.2.3.）。为了支持这一点，NAT MIB模块中需要一个额外的分组表。
Existing work for firewall control with SNMP only considered the monitoring of firewalls and not the configuration. Further work is required towards the development of MIBs for configuring firewalls.
使用SNMP进行防火墙控制的现有工作仅考虑防火墙的监控，而不考虑配置。需要进一步的工作来开发用于配置防火墙的MIB。
The SNMP management framework provides functions equivalent to those defined by the MIDCOM framework, although there are a few architectural differences.
SNMP管理框架提供的功能等同于MIDCOM框架定义的功能，尽管存在一些架构差异。
Traditionally, SNMP entities have been called Manager and Agent. Manager and agent are now recognized as entities designed to support particular configurations of SNMPv3 functions. A traditional manager
传统上，SNMP实体被称为管理器和代理。Manager和agent现在被认为是设计用于支持SNMPv3功能的特定配置的实体。传统的经理
is an entity capable of generating requests and receiving notifications, and a traditional agent is an entity capable of responding to requests and generating notifications. The SNMP use of the term agent is different from its use in the MIDCOM framework: The SNMP Manager corresponds to the MIDCOM agent and the SNMP Agent corresponds to the MIDCOM PDP. The SNMP evaluation assumes that the MIDCOM PDP (SNMP Agent) is physically part of the middlebox, which is allowed by the MIDCOM framework as described in section 6.0 of [2]. Thus, for the purpose of this evaluation, the SNMP agent corresponds to the Middlebox.
是一个能够生成请求和接收通知的实体，而传统代理是一个能够响应请求和生成通知的实体。术语代理的SNMP用法与在MIDCOM框架中的用法不同：SNMP管理器对应于MIDCOM代理，SNMP代理对应于MIDCOM PDP。SNMP评估假设MIDCOM PDP（SNMP代理）在物理上是MIDCOM框架的一部分，如[2]第6.0节所述。因此，为了进行此评估，SNMP代理对应于中间盒。
While this evaluation is based on the assumption that the SNMP agent corresponds to the middlebox, SNMP does not force such a restriction.
虽然此评估基于SNMP代理对应于中间盒的假设，但SNMP不强制执行此限制。
Proxy means many things to many people. SNMP can be deployed using intermediate entities to forward messages, or to help distribute policies to the middlebox, similar to the proxy capabilities of the other candidate protocols. Since proxy adds configuration and deployment complexity and is not necessary to meet the specified MIDCOM requirements, the use of a proxy agent or mid-level manager is not considered in this evaluation. Further details on SNMP proxy capabilities are provided in Appendix A.
代理对很多人来说意味着很多事情。与其他候选协议的代理功能类似，可以使用中间实体来部署SNMP，以转发消息，或帮助将策略分发到中间件。由于代理增加了配置和部署的复杂性，并且不需要满足指定的MIDCOM要求，因此本评估中不考虑使用代理或中级管理器。有关SNMP代理功能的更多详细信息，请参见附录A。
Although the SNMP management framework does not have the concept of a session, session-like associations can be established through the use of managed objects. In order to implement the MIDCOM protocol based on SNMP, a MIDCOM MIB module is required. All requests from the MIDCOM agent to the Middlebox would be performed using write access to managed objects defined in the MIDCOM MIB module. Replies to requests are signaled by the Middlebox (SNMP agent), by modifying the managed objects. The MIDCOM agent (SNMP manager) can receive this information by reading or polling, if required, the corresponding managed object.
尽管SNMP管理框架没有会话的概念，但是可以通过使用托管对象建立类似会话的关联。为了实现基于SNMP的MIDCOM协议，需要一个MIDCOM MIB模块。所有从MIDCOM代理到Middlebox的请求都将使用对MIDCOM MIB模块中定义的托管对象的写访问权限来执行。通过修改托管对象，对请求的响应由中间件（SNMP代理）发出信号。如果需要，MIDCOM代理（SNMP管理器）可以通过读取或轮询相应的托管对象来接收此信息。
The RSIP framework and detailed protocol are defined in RFC 3102 [17] and RFC 3103 [18] respectively.
RSIP框架和详细协议分别在RFC 3102[17]和RFC 3103[18]中定义。
The following framework elements are common to MIDCOM and RSIP listed by their MIDCOM names, with the RSIP name indicated in parenthesis:
以下框架元素对于MIDCOM和RSIP是通用的，按MIDCOM名称列出，RSIP名称用括号表示：
o Hosts o Applications o Middleboxes (RSIP gateways) o Private domain (private realm)
o 主机o应用程序o中间盒（RSIP网关）o私有域（私有领域）
o External domain (public realm) o Middlebox communication protocol (RSIP) o MIDCOM agent registration (host registration) o MIDCOM session (RSIP session) o MIDCOM Filter (local / remote address and port number(s) pairs)
o 外部域（公共领域）o中间盒通信协议（RSIP）o MIDCOM代理注册（主机注册）o MIDCOM会话（RSIP会话）o MIDCOM筛选器（本地/远程地址和端口号对）
The following MIDCOM framework elements are not supported by RSIP:
RSIP不支持以下MIDCOM框架元素：
o Policy actions and rules. RSIP always implicitly assumes a permit action. To support MIDCOM, a more general and explicit action parameter would have to be defined. RSIP requests specifying local / remote address and port number(s) pairs would have to be extended to include an action parameter, in MIDCOM rules.
o 政策行动和规则。RSIP总是隐式地假定一个许可操作。为了支持MIDCOM，必须定义一个更通用、更明确的操作参数。在MIDCOM规则中，指定本地/远程地址和端口号对的RSIP请求必须扩展，以包括操作参数。
o MIDCOM agents. RSIP makes no distinction between applications and agents; address assignment operations can be performed equally by applications and agents.
o MIDCOM代理。RSIP不区分应用程序和代理程序；应用程序和代理程序可以平等地执行地址分配操作。
o Policy Decision Points. RSIP assumes that middleboxes grant or deny requests with reference to a policy known to them; the policy could be determined jointly by the middlebox and a policy decision point; such joint determination is not addressed by the RSIP framework, nor is it specifically precluded.
o 政策决策要点。RSIP假设中间包根据其已知的策略批准或拒绝请求；政策可由中间箱和政策决策点共同确定；RSIP框架未涉及此类共同决定，也未明确排除此类共同决定。
The following elements are unique to the RSIP framework. If RSIP were adopted as the basis for the MIDCOM protocol, they could be added to the MIDCOM framework:
以下元素是RSIP框架所独有的。如果采用RSIP作为MIDCOM协议的基础，则可将其添加到MIDCOM框架中：
o RSIP client: that portion of the application (or agent) that talks to the RSIP gateway using RSIP.
o RSIP客户端：应用程序（或代理）中使用RSIP与RSIP网关通信的部分。
o RSIP server: that portion of an RSIP gateway that talks to applications using RSIP.
o RSIP服务器：RSIP网关中使用RSIP与应用程序对话的部分。
o Realm Specific Address IP (RSA-IP) and Realm Specific Address and Port IP (RSAP-IP): RSIP distinguishes between filters that include all ports on an IP address and those that do not.
o 领域特定地址IP（RSA-IP）和领域特定地址和端口IP（RSAP-IP）：RSIP区分包含IP地址上所有端口的筛选器和不包含这些端口的筛选器。
o Demultiplexing Fields: Any set of packet header or payload fields that an RSIP gateway uses to route an incoming packet to an RSIP host. RSIP allows a gateway to perform, and an application to control, packet routing to hosts in the private domain based on more than IP header fields.
o 解复用字段：RSIP网关用于将传入数据包路由到RSIP主机的任何一组数据包头或有效负载字段。RSIP允许网关根据多个IP头字段执行到私有域中主机的数据包路由，并允许应用程序控制数据包路由。
o Host-to-middlebox tunnels: RSIP assumes that data communicated between a private realm host and a public realm host is transferred through the private realm by a tunnel between the inner host and the middle box, where it is converted to and from native IP based communications to the public realm host.
o 主机到中间盒隧道：RSIP假设在私有领域主机和公共领域主机之间通信的数据通过内部主机和中间盒之间的隧道通过私有领域传输，在该隧道中，数据被转换为基于本机IP的通信并从本机IP的通信传输到公共领域主机。
RSIP with tunneling, has the advantage that the public realm IP addresses and port numbers are known to the private realm host application, thus no translation is needed for protocols such as SDP, the FTP control protocol, RTSP, SMIL, etc. However, this does require that an RSIP server and a tunneling protocol be implemented in the middlebox and an RSIP client and the tunneling protocol be implemented in the private realm host. The host modifications can generally be made without modification to the host application or requiring the implementation of a host application agent. This is viewed as a significant advantage over NAT (Network Address Translation).
带有隧道的RSIP的优点是，私有领域主机应用程序知道公共领域IP地址和端口号，因此不需要对SDP、FTP控制协议、RTSP、SMIL等协议进行转换。但是，这确实需要在中间盒中实现RSIP服务器和隧道协议，在私有领域主机中实现RSIP客户端和隧道协议。主机修改通常可以在不修改主机应用程序或不需要实现主机应用程序代理的情况下进行。这被认为是NAT（网络地址转换）的一个显著优势。
Further details on the evaluation of RSIP with regards to tunneling in the context of NAT support are available in Appendix B of this document.
本文件附录B中提供了与NAT支持背景下隧道相关的RSIP评估的更多详细信息。
Megaco is a master-slave, transaction-oriented protocol defined in RFC 3015 [20] in which Media Gateway Controllers (MGC) control the operation of Media Gateways (MG). Originally designed to control IP Telephony gateways, it is used between an application-unaware device (the Media Gateway) and an intelligent entity (the Media Gateway Controller) having application awareness.
Megaco是RFC 3015[20]中定义的一种主从、面向事务的协议，其中媒体网关控制器（MGC）控制媒体网关（MG）的操作。最初设计用于控制IP电话网关，它用于不知道应用程序的设备（媒体网关）和具有应用程序意识的智能实体（媒体网关控制器）之间。
The Megaco model includes the following key concepts:
Megaco模型包括以下关键概念：
1. Terminations: Logical entities on the MG that act as sources or sink of packet streams. A termination can be physical or ephemeral and is associated with a single MGC.
1. 终止：MG上作为数据包流的源或汇的逻辑实体。终端可以是物理的或短暂的，并且与单个MGC关联。
2. Context: An association between Terminations for sharing media between the Terminations. Terminations can be added, subtracted from a Context and can be moved from one Context to another. A Context and all of its Terminations are associated with a single MGC.
2. 上下文：终端之间的关联，用于在终端之间共享媒体。可以从上下文中添加、减去终止，也可以从一个上下文移动到另一个上下文。上下文及其所有终止都与单个MGC关联。
3. Virtual Media Gateways: A physical MG can be partitioned into multiple virtual MGs allowing multiple Controllers to interact with disjoint sets of Contexts/Terminations within a single physical device.
3. 虚拟媒体网关：物理MG可以划分为多个虚拟MG，允许多个控制器与单个物理设备内不相交的上下文/终端集进行交互。
4. Transactions/Messages: Each Megaco command applies to one Termination within a Context and generates a unique response. Commands may be replicated implicitly so that they act on all Terminations of a given Context through wildcarding of Termination identifiers. Multiple commands addressed to different Contexts can be grouped in a Transaction structure. Similarly, multiple Transactions can be concatenated into a Message.
4. 事务/消息：每个Megaco命令应用于上下文中的一个终端，并生成唯一的响应。命令可以隐式复制，以便它们通过终端标识符的通配符作用于给定上下文的所有终端。可以在一个事务结构中对多个寻址到不同上下文的命令进行分组。类似地，可以将多个事务连接到一条消息中。
5. Descriptors/Properties: A Termination is described by a number of characterizing parameters or Properties, which are grouped in a set of Descriptors that are included in commands and responses.
5. 描述符/属性：终止由许多特征参数或属性描述，这些参数或属性分组在一组描述符中，这些描述符包含在命令和响应中。
6. Events and signals: A Termination can be programmed to perform certain actions or to detect certain events and notify the Agent.
6. 事件和信号：可以对终端进行编程，以执行某些操作或检测某些事件并通知代理。
7. Packages: Packages are groups of properties, events, etc. associated with a Termination. Packages are simple means of extending the protocol to serve various types of devices or Middleboxes.
7. 包：包是与终止相关的属性、事件等的组。包是扩展协议以服务于各种类型的设备或中间盒的简单方法。
In the MIDCOM architecture, the Middlebox plays the role of an application-unaware device being controlled by the application-aware Agent. In the Megaco architecture, the Media Gateway controller serves a role similar to the MIDCOM Agent (MA) and the Media Gateway serves a role similar to the Middlebox (MB). One major difference between the Megaco model and the MIDCOM protocol requirements is that MIDCOM requires that the MIDCOM Agent establish the session. Whereas, the Megaco definition is that a MG (Middlebox) establishes communication with an MGC (MIDCOM Agent).
在MIDCOM体系结构中，中间盒扮演着应用程序感知代理控制的应用程序感知设备的角色。在Megaco体系结构中，媒体网关控制器的作用类似于MIDCOM代理（MA），媒体网关的作用类似于中间盒（MB）。Megaco模型和MIDCOM协议要求之间的一个主要区别是，MIDCOM要求MIDCOM代理建立会话。然而，Megaco的定义是MG（中间箱）与MGC（MIDCOM代理）建立通信。
Diameter is designed to support AAA for network access. It is meant to operate through networks of Diameter nodes, which both act upon and route messages toward their final destinations. Endpoints are characterized as either clients, which perform network access control, or servers, which handle authentication, authorization and accounting requests for a particular realm. Intermediate nodes perform relay, proxy, redirect, and translation services. Design
Diameter设计用于支持AAA网络访问。它意味着通过Diameter节点网络进行操作，这些节点同时作用于消息并将消息路由到它们的最终目的地。端点的特征是执行网络访问控制的客户端，或处理特定领域的身份验证、授权和记帐请求的服务器。中间节点执行中继、代理、重定向和转换服务。设计
requirements for the protocol include robustness in the face of bursty message loads and server failures, resistance to specific DOS attacks and protection of message contents, and extensibility including support for vendor-specific attributes and message types.
该协议的要求包括面对突发消息负载和服务器故障时的健壮性、对特定DOS攻击的抵抗力和对消息内容的保护，以及可扩展性，包括对供应商特定属性和消息类型的支持。
The protocol is designed as a base protocol in RFC 3588 [24] to be supported by all implementations, plus extensions devoted to specific applications. Messages consist of a header and an aggregation of "Attribute-Value Pairs (AVPs)", each of which is a tag-length-value construct. The header includes a command code, which determines the processing of the message and what other AVP types must or may be present. AVPs are strongly typed. Some basic and compound types are provided by the base protocol specification, while others may be added by application extensions. One of the types provided in the base is the IPFilterRule, which may be sufficient to express the Policy Rules that MIDCOM deals with.
该协议在RFC 3588[24]中被设计为一个基本协议，所有实现以及专用于特定应用的扩展都支持该协议。消息由头和“属性值对（AVP）”的聚合组成，每个属性值对都是一个标记长度值构造。报头包括一个命令代码，用于确定消息的处理以及必须或可能存在的其他AVP类型。AVP是强类型的。一些基本类型和复合类型由基本协议规范提供，而其他类型可以通过应用程序扩展添加。基础中提供的类型之一是IPFilterRule，它可能足以表示MIDCOM处理的策略规则。
Messaging takes the form of request-answer exchanges. Some exchanges may take multiple round-trips to complete. The protocol is connection-oriented at both the transport and application levels. In addition, the protocol is tied closely to the idea of sessions, which relate sequences of message exchanges through use of a common session identifier. Each application provides its own definition of the semantics of a session. Multiple sessions may be open simultaneously.
消息传递采用请求-应答交换的形式。一些交换可能需要多次往返才能完成。该协议在传输层和应用层都是面向连接的。此外，该协议与会话的概念密切相关，会话通过使用公共会话标识符来关联消息交换序列。每个应用程序都提供自己的会话语义定义。可以同时打开多个会话。
The MIDCOM Agent does not perform the functions of a Diameter client, nor does the Middlebox support the functions of a Diameter server. Thus the MIDCOM application would introduce two new types of endpoints into the Diameter architecture. Moreover, the MIDCOM requirements do not at this time imply any type of intermediate node.
MIDCOM代理不执行Diameter客户端的功能，也不支持Diameter服务器的功能。因此，MIDCOM应用程序将在Diameter体系结构中引入两种新类型的端点。此外，MIDCOM要求目前并不意味着任何类型的中间节点。
A general assessment might be that Diameter meets and exceeds MIDCOM architectural requirements, however the connection orientation may be too heavy for the number of relationships the Middlebox must support. Certainly the focus on extensibility, request-response messaging orientation, and treatment of the session, are all well-matched to what MIDCOM needs. At this point, MIDCOM is focused on simple point-to-point relationships, so the proxying and forwarding capabilities provided by Diameter are not needed. Most of the commands and AVPs defined in the base protocol are also surplus to MIDCOM requirements.
一般评估可能是Diameter满足并超过了MIDCOM体系结构要求，但连接方向可能过于繁重，无法满足中间盒必须支持的关系数量。当然，对可扩展性、请求-响应消息传递方向和会话处理的关注，都与MIDCOM的需求相匹配。此时，MIDCOM专注于简单的点对点关系，因此不需要Diameter提供的代理和转发功能。基本协议中定义的大多数命令和AVP也超出了MIDCOM要求。
Overall, COPS, defined in RFC 2748 [25], and COPS-PR, defined in RFC 3084 [26], have similar compliancy with regards to the MIDCOM protocol requirements. In this document, references to COPS are generally applicable to both COPS and COPS-PR. However, COPS-PR is explicitly identified to meet two of the requirements. The only other major difference between COPS-PR and COPS, as applied to the MIDCOM protocol, would be the description of the MIDCOM policy rule attributes with COPS-PR MIDCOM PIB attributes rather than COPS MIDCOM client specific objects.
总体而言，RFC 2748[25]中定义的COPS和RFC 3084[26]中定义的COPS-PR在MIDCOM协议要求方面具有类似的合规性。在本文件中，对COPS的引用通常适用于COPS和COPS-PR。但是，明确指出COPS-PR满足其中两个要求。应用于MIDCOM协议的COPS-PR和COPS之间唯一的其他主要区别是使用COPS-PR MIDCOM PIB属性而不是COPS MIDCOM客户端特定对象描述MIDCOM策略规则属性。
COPS is a simple query and response protocol that can be used to exchange policy information between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). COPS was defined to be a simple and extensible protocol. The main characteristics of COPS include the following:
COPS是一种简单的查询和响应协议，可用于在策略服务器（策略决策点或PDP）及其客户端（策略实施点或PEP）之间交换策略信息。COPS被定义为一个简单且可扩展的协议。COP的主要特征包括：
1. The protocol employs a client/server model. The PEP sends requests, updates, and deletions to the remote PDP and the PDP returns decisions back to the PEP.
1. 该协议采用客户机/服务器模型。PEP向远程PDP发送请求、更新和删除，PDP将决策返回给PEP。
2. The protocol uses TCP as its transport protocol for reliable exchange of messages between policy clients and a server.
2. 该协议使用TCP作为其传输协议，以便在策略客户端和服务器之间可靠地交换消息。
3. The protocol is extensible in that it is designed to leverage self-identifying objects and can support diverse client specific information without requiring modification of the COPS protocol.
3. 该协议是可扩展的，因为它旨在利用自识别对象，并且可以支持各种特定于客户端的信息，而无需修改COPS协议。
4. The protocol was created for the general administration, configuration, and enforcement of policies.
4. 该协议是为策略的一般管理、配置和实施而创建的。
5. COPS provides message level security for authentication, replay protection, and message integrity. COPS can make use of existing protocols for security such as IPSEC [22] or TLS [21] to authenticate and secure the channel between the PEP and the PDP.
5. COPS为身份验证、重播保护和消息完整性提供消息级安全性。COP可以利用现有的安全协议（如IPSEC[22]或TLS[21]）来认证和保护PEP和PDP之间的通道。
6. The protocol is stateful in two main aspects:
6. 该协议在两个主要方面是有状态的：
(1) Request/Decision state is shared and kept synchronized in a transactional manner between client and server. Requests from the client PEP are installed or remembered by the remote PDP until they are explicitly deleted by the PEP. At the same time, Decisions from the remote PDP can be generated asynchronously at any time for a currently installed request state.
(1) 请求/决策状态在客户端和服务器之间以事务方式共享并保持同步。来自客户端PEP的请求由远程PDP安装或记忆，直到PEP明确删除这些请求。同时，远程PDP的决策可以在任何时候针对当前安装的请求状态异步生成。
(2) State from various events (Request/Decision pairs) may be inter-associated. The server may respond to new queries differently because of previously installed, related Request/Decision state(s).
(2) 来自各种事件（请求/决策对）的状态可能是相互关联的。由于以前安装的相关请求/决策状态，服务器可能会以不同方式响应新查询。
7. The protocol is also stateful in that it allows the server to push configuration information to the client, and then allows the server to remove such state from the client when it is no longer applicable.
7. 该协议也是有状态的，因为它允许服务器将配置信息推送到客户端，然后允许服务器在不再适用时从客户端删除此类状态。
In the MIDCOM framework, the Middlebox enforces the policy controlled by an application-aware Agent. Thus, when compared to the COPS architecture, the Middlebox serves as the PEP (COPS Client) and the MIDCOM Agent serves as the PDP (COPS Policy Server). One major difference between the COPS protocol model and the MIDCOM protocol requirements is that MIDCOM requires that the MIDCOM Agent establish the session. Whereas, the COPS definition is that a PEP (Middlebox) establishes communication with a PDP (MIDCOM Agent).
在MIDCOM框架中，Middlebox强制执行由应用程序感知代理控制的策略。因此，与COPS体系结构相比，中间盒充当PEP（COPS客户端），而MIDCOM代理充当PDP（COPS策略服务器）。COPS协议模型和MIDCOM协议要求之间的一个主要区别是，MIDCOM要求MIDCOM代理建立会话。鉴于，COPS的定义是PEP（中间箱）与PDP（MIDCOM代理）建立通信。
This section contains a review of the protocol's level of compliance to each of the MIDCOM Requirements [1]. The following key will be used to identify the level of compliancy of each of the individual protocols:
本节回顾了协议对每个MIDCOM要求的合规程度[1]。以下密钥将用于确定每个协议的合规性级别：
T = Total Compliance. Meets the requirement fully.
T=总合规性。完全符合要求。
P+ = Partial Compliance+. Fundamentally meets the requirement through the use of extensions (e.g., packages, additional parameters, etc).
P+=部分合规性+。通过使用扩展（例如，包、附加参数等）从根本上满足要求。
P = Partial Compliance. Meets some aspect of the requirement, however, the necessary changes require more than an extension and/or are inconsistent with the design intent of the protocol.
P=部分合规性。满足要求的某些方面，但是，必要的变更要求的不仅仅是扩展和/或与协议的设计意图不一致。
F = Failed Compliance. Does not meet the requirement.
F=不符合要求。不符合要求。
This section describes the compliancy of the proposed protocols against the protocol machinery requirements from section 2.1 of the requirements document [1]. A short description of each of the protocols is provided to substantiate the evaluation.
本节描述了拟定协议与需求文件[1]第2.1节中协议机械要求的一致性。为证实评估，提供了每个协议的简短描述。
2.1.1. Ability to Establish Association Between Agent and Middlebox.
2.1.1. 能够在代理和中间箱之间建立关联。
SNMP: T, RSIP: P+, Megaco: P, Diameter: T, COPS: P
SNMP: T, RSIP: P+, Megaco: P, Diameter: T, COPS: P
SNMP: SNMPv3 provides mutual authentication at the user level (where the user can be an application or a host if desired) via shared secrets. Each authenticated principal is associated with a group that has access rights that control the principals ability to perform operations on specific subsets of data. Failure to authenticate can generate a SNMP notification (administrator configurable choice).
SNMP:SNMPv3通过共享机密在用户级别（如果需要，用户可以是应用程序或主机）提供相互身份验证。每个经过身份验证的主体都与具有访问权限的组相关联，这些访问权限控制主体对特定数据子集执行操作的能力。身份验证失败会生成SNMP通知（管理员可配置选项）。
RSIP: RSIP allows sessions to be established between middleboxes and applications and MIDCOM agents. Authorization credentials would have to be added to the session establishment request to allow the middlebox to authorize the session requestor.
RSIP:RSIP允许在中间盒、应用程序和MIDCOM代理之间建立会话。必须将授权凭据添加到会话建立请求中，以允许中间盒授权会话请求者。
Megaco: There is a directionality component implicit in this requirement in that the MA initiates the establishment of the authorized session. Megaco defines this association to be established in the opposite direction, i.e., the Middlebox(MG) initiates the establishment. If this restriction is not considered, then Megaco makes the syntax and semantics available for the endpoint to initiate the connection.
Megaco：该要求中隐含了一个方向性组件，即MA启动授权会话的建立。Megaco将此关联定义为以相反方向建立，即，中间箱（MG）发起建立。如果未考虑此限制，则Megaco会使端点可以使用语法和语义来启动连接。
Diameter: Although this is out of scope, the Diameter specification describes several ways to discover a peer. Having done so, a Diameter node establishes a transport connection (TCP, TLS, or SCTP) to the peer. The two peers then exchange Capability Exchange Request/Answer messages to identify each other and determine the Diameter applications each supports.
直径：虽然这超出了范围，但直径规范描述了几种发现对等点的方法。完成此操作后，Diameter节点建立到对等方的传输连接（TCP、TLS或SCTP）。然后，两个对等方交换能力交换请求/应答消息，以相互识别并确定各自支持的应用程序的直径。
If the connection between two peers is lost, Diameter prescribes procedures whereby it may be re-established. To ensure that loss of connectivity is detected quickly, Diameter provides the Device-Watchdog Request/Answer messages, to be used when traffic between the two peers is low.
如果两个对等点之间的连接丢失，Diameter规定了重新建立连接的程序。为确保快速检测到连接丢失，Diameter提供设备看门狗请求/应答消息，在两个对等方之间的通信量较低时使用。
Diameter provides an extensive state machine to govern the relationship between two peers.
Diameter提供了一个广泛的状态机来管理两个对等点之间的关系。
COPS: COPS does not meet the directionality part of the requirement. The definition of COPS allows a PEP (Middlebox) to establish communication with a PDP (MIDCOM Agent). However, nothing explicitly prohibits a PDP from establishing communication
COPS：COPS不符合要求的方向性部分。COP的定义允许PEP（中间箱）与PDP（MIDCOM代理）建立通信。但是，没有任何内容明确禁止PDP建立通信
with a PEP. The PEP could have local policies dictating what action to take when it is contacted by an unknown PDP. These actions, defined in the local policies, would ensure the proper establishment of an authorized association.
打起精神来。政治公众人物可以制定当地政策，规定当未知PDP联系政治公众人物时应采取的行动。当地政策中规定的这些行动将确保适当建立授权协会。
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP: An SNMP manager can communicate simultaneously with several Middleboxes.
SNMP：SNMP管理器可以同时与多个中间盒通信。
RSIP: RSIP sessions are identified by their IP source and destination addresses and their TCP / UDP port numbers. Thus each RSIP client can communicate with multiple servers, and each server can communicate with multiple clients. However, RSIP did not explicitly include agents in its design. The architecture and semantics of RSIP messages do not preclude agents, thus the RSIP architecture could certainly be extended to explicitly include agents; therefore RSIP is deemed partially compliant to this requirement.
RSIP:RSIP会话由其IP源和目标地址以及TCP/UDP端口号标识。因此，每个RSIP客户端可以与多个服务器通信，并且每个服务器可以与多个客户端通信。然而，RSIP并没有在其设计中明确包含代理。RSIP消息的体系结构和语义并不排除代理，因此RSIP体系结构当然可以扩展为显式包含代理；因此，RSIP被视为部分符合该要求。
Megaco: Megaco allows an MA to control several Middleboxes. Each message carries an identifier of the endpoint that transmitted the message allowing the recipient to determine the source.
Megaco:Megaco允许MA控制多个中间盒。每条消息都带有发送消息的端点的标识符，允许接收者确定消息源。
Diameter: Diameter allows connection to more than one peer (and encourages this for improved reliability). Whether the Diameter connection state machine is too heavy to support the number of connections needed is a matter for discussion.
Diameter：Diameter允许连接到多个对等点（并鼓励这样做以提高可靠性）。直径连接状态机是否太重，无法支持所需的连接数，这是一个有待讨论的问题。
COPS: COPS PDPs are designed to communicate with several PEPs.
COPS:COPS PDP设计用于与多个政治公众人物进行通信。
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP: An SNMP agent can communicate with several SNMP managers Simultaneously.
SNMP：SNMP代理可以同时与多个SNMP管理器通信。
RSIP: Refer to 2.1.2.
RSIP：参考2.1.2。
Megaco: Megaco has the concept of Virtual Media Gateways (VMG), allowing multiple MGCs to communicate simultaneously with the same MG. Applying this model to MIDCOM would allow the same middlebox (MG) to have associations with multiple MIDCOM Agents (MGCs).
Megaco:Megaco具有虚拟媒体网关（VMG）的概念，允许多个MGC同时与同一个MG通信。将此模型应用于MIDCOM将允许同一个中间包（MG）与多个MIDCOM代理（MGC）关联。
Diameter: Diameter allows connection to more than one peer and encourages this for improved reliability. Whether the Diameter connection state machine is too heavy to support the number of connections needed is a matter for discussion. The Middlebox and Agent play symmetric roles as far as Diameter peering is concerned.
Diameter：Diameter允许连接到多个对等点，并鼓励这样做以提高可靠性。直径连接状态机是否太重，无法支持所需的连接数，这是一个有待讨论的问题。就直径对等而言，中间盒和代理扮演着对称的角色。
COPS: The COPS-PR framework specifies that a PEP should have a unique PDP in order to achieve effective policy control. The COPS-PR protocol would allow the scenario whereby a PEP establishes communication with multiple PDPs by creating a COPS client instance per PDP.
COPS:COPS-PR框架规定政治公众人物应具有唯一的PDP，以实现有效的政策控制。COPS-PR协议允许这样的场景，即政治公众人物通过为每个PDP创建一个COPS客户端实例来与多个PDP建立通信。
2.1.4. Deterministic Outcome When Multiple Requests are Presented to the Middlebox Simultaneously
2.1.4. 当多个请求同时呈现给中间盒时的确定结果
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: While the architectural design of SNMP can permit race conditions to occur, there are mechanisms defined as part of the SNMPv3 standard, such as view-based access control and advisory locking that can be used to prevent the conditions, and MIB modules may also contain special functionality, such as RMONs OwnerString, to prevent conflicts. Deterministic behavior of SNMP agents when being accessed by multiple managers is important for several management applications and supported by SNMP.
SNMP：虽然SNMP的体系结构设计允许出现竞争条件，但有一些机制被定义为SNMPv3标准的一部分，如基于视图的访问控制和建议锁定，可用于防止出现竞争条件，而MIB模块也可能包含特殊功能，如RMONs OwnerString，以防止冲突。SNMP代理在被多个管理器访问时的确定性行为对于多个管理应用程序非常重要，并且受SNMP支持。
RSIP: All RSIP requests are defined to be atomic. Near simultaneous requests are executed as is they were sequential.
RSIP：所有RSIP请求都定义为原子请求。几乎同时执行的请求按顺序执行。
Megaco: Megaco supports the concept of VMGs to make these interactions deterministic and to avoid resource access conflicts. Each VMG has a single owner, in a MGC, and there can be no overlap between the sets of Terminations belonging to multiple VMGs. The Megaco protocol messages also include the identifier of the sending entity, so that the MG can easily determine to whom to send the response or asynchronously report certain events.
Megaco:Megaco支持VMG的概念，以使这些交互具有确定性并避免资源访问冲突。在MGC中，每个VMG都有一个所有者，属于多个VMG的终端集之间不能有重叠。Megaco协议消息还包括发送实体的标识符，因此MG可以轻松确定向谁发送响应或异步报告某些事件。
Diameter: Diameter depends partly upon the transport protocol to provide flow control when the server becomes heavily loaded. It also has application-layer messaging to indicate that it is too busy or out of space (Diameter_TOO_BUSY and Diameter_OUT_OF_SPACE result codes).
Diameter：Diameter部分取决于传输协议，以在服务器负载过重时提供流控制。它还具有应用层消息，以指示它太忙或空间不足（Diameter\u too\u busy和Diameter\u out\u of_space结果代码）。
COPS: COPS has built-in support for clear state and policy instances. This would allow the creation of well-behaved MIDCOM state machines.
COPS：COPS内置了对清晰的州和政策实例的支持。这将允许创建性能良好的MIDCOM状态机。
SNMP: T, RSIP: T, Megaco: T, Diameter: P, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: P, COPS: T
SNMP: Requests are atomic in SNMP. MIB modules can define which data is persistent across reboots, so a known startup state can be established. The manager can poll the agent to determine the current state.
SNMP：请求在SNMP中是原子的。MIB模块可以定义哪些数据在重新启动期间是持久的，因此可以建立一个已知的启动状态。管理器可以轮询代理以确定当前状态。
RSIP: RSIP assumes that on middlebox start-up no sessions are defined, and thus no allocations have been made. In effect, all resources are released upon restart after failure.
RSIP:RSIP假设在middlebox启动时没有定义会话，因此没有进行分配。实际上，所有资源都在故障后重新启动时释放。
Megaco: Megaco has extensive audit capabilities to synchronize states between the MG and the MGC. Megaco also provides the MGC with the ability to do mass resets, as well as individual resets. The MGC can always release resources in the MG. The MG can also initiate the release of resources by the MGC.
Megaco:Megaco具有广泛的审计功能，可以同步MG和MGC之间的状态。Megaco还为MGC提供了进行大规模重置以及单独重置的能力。MGC始终可以释放MG中的资源。MG还可以启动MGC的资源释放。
Diameter: Diameter documentation does not discuss the degree of atomicity of message processing, so this would have to be specified in the MIDCOM extension.
Diameter:Diameter文档没有讨论消息处理的原子性程度，因此必须在MIDCOM扩展中指定。
COPS: The COPS protocol maintains synchronized states between Middleboxes and MA hence all the states are known on both sides.
COPS：COPS协议维护中间盒和MA之间的同步状态，因此双方都知道所有状态。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: The status of a middlebox can be reported using asynchronous communications, or via polling.
SNMP：可以使用异步通信或轮询来报告中间盒的状态。
RSIP: All RSIP client requests have explicit server responses. Additionally, a client may explicitly request server status using a QUERY request.
RSIP：所有RSIP客户端请求都有明确的服务器响应。此外，客户端可以使用查询请求显式请求服务器状态。
Megaco: Megaco has extensive audit capabilities for the MG to report status information to the MGC. It can also report some status updates using the ServiceChange command.
Megaco:Megaco具有广泛的审计功能，MG可以向MGC报告状态信息。它还可以使用ServiceChange命令报告一些状态更新。
Diameter: Diameter provides a number of response codes by means of which a server can indicate error conditions reflecting status of the server as a whole. The Disconnect-Peer-Request provides a means in the extreme case to terminate a connection with a peer gracefully, informing the other end about the reason for the disconnection.
Diameter：Diameter提供了许多响应代码，通过这些代码，服务器可以指示反映服务器整体状态的错误条件。断开对等请求在极端情况下提供了一种方法，可以优雅地终止与对等方的连接，通知另一端断开连接的原因。
COPS: The COPS Report message is designed to indicate any asynchronous conditions/events.
COPS：COPS报告消息旨在指示任何异步条件/事件。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 supports both confirmed and unconfirmed asynchronous notifications.
SNMP:SNMPv3支持已确认和未确认的异步通知。
RSIP: An RSIP server will send an unsolicited DE_REGISTER_RESPONSE to force an RSIP host to relinquish all of its bindings and terminate its relationship with the RSIP gateway. An RSIP server can send an asynchronous ERROR_RESPONSE to indicate less severe conditions.
RSIP：RSIP服务器将发送未经请求的DE_REGISTER_响应，以强制RSIP主机放弃其所有绑定并终止其与RSIP网关的关系。RSIP服务器可以发送异步错误\u响应，以指示不太严重的情况。
Megaco: Megaco supports the asynchronous notification of events using the Notify command.
Megaco:Megaco支持使用Notify命令异步通知事件。
Diameter: The Diameter protocol permits either peer in a connection to originate transactions. Thus the protocol supports Middlebox-originated messages.
Diameter：Diameter协议允许连接中的任一对等方发起事务。因此，该协议支持源自中间盒的消息。
COPS: The COPS Report message is designed to indicate any asynchronous conditions/events.
COPS：COPS报告消息旨在指示任何异步条件/事件。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 meets this requirement. SNMPv3 supports user authentication and explicitly supports symmetric secret key encryption between MIDCOM agent (SNMP manager) and Middlebox (SNMP agent), thus supporting mutual authentication. The default authentication and encryption methods are specified in RFC 3414 [11] (MD5, SHA-1, and DES). Different users at the same management application (MIDCOM agent) can authenticate themselves with different authentication and encryption methods, and additional methods can be added to SNMPv3 entities as needed.
SNMP:SNMPv3满足此要求。SNMPv3支持用户身份验证，并明确支持MIDCOM代理（SNMP管理器）和Middlebox（SNMP代理）之间的对称密钥加密，从而支持相互身份验证。RFC 3414[11]（MD5、SHA-1和DES）中规定了默认身份验证和加密方法。同一管理应用程序（MIDCOM代理）中的不同用户可以使用不同的身份验证和加密方法对自己进行身份验证，并且可以根据需要向SNMPv3实体添加其他方法。
RSIP: This requirement can be met by operating RSIP over IPSec as described in RFC 3104 [19]. The RSIP framework recommends all communication between an RSIP host and gateway be authenticated. Authentication, in the form of a message hash appended to the end of each RSIP protocol packet, can serve to authenticate the RSIP host and gateway to one another, provide message integrity, and
RSIP：如RFC 3104[19]所述，通过IPSec操作RSIP可以满足此要求。RSIP框架建议对RSIP主机和网关之间的所有通信进行身份验证。以消息散列的形式附加到每个RSIP协议分组的末尾的认证可用于相互认证RSIP主机和网关，提供消息完整性，以及
avoid replay attacks with an anti-replay counter. However, the message hash and replay counter parameters would need to be defined for the RSIP protocol.
使用反重放计数器避免重放攻击。但是，需要为RSIP协议定义消息散列和重播计数器参数。
Megaco: Megaco provides for the use of IPSec [22] for all security mechanisms including mutual authentication, integrity check and encryption. Use of IKE is recommended with support of RSA signatures and public key encryption.
Megaco:Megaco为所有安全机制（包括相互身份验证、完整性检查和加密）提供IPSec[22]的使用。建议在支持RSA签名和公钥加密的情况下使用IKE。
Diameter: The Diameter base protocol assumes that messages are secured by using either IPSec or TLS [21]. Diameter requires that when using the latter, peers must mutually authenticate themselves.
Diameter:Diameter基本协议假定消息通过使用IPSec或TLS进行保护[21]。Diameter要求在使用后者时，对等方必须相互验证自己。
COPS: COPS has built-in message level security for authentication, replay protection, and message integrity. COPS can also use TLS or IPSec.
COPS:COPS具有用于身份验证、重播保护和消息完整性的内置消息级安全性。警察也可以使用TLS或IPSec。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: Each SNMPv3 message is authenticated and authorized, so each message could be considered to have its own session, which automatically terminates after processing. Processing may be stopped for a number of reasons, such as security, and a response is sent.
SNMP：每个SNMPv3消息都经过身份验证和授权，因此可以认为每个消息都有自己的会话，该会话在处理后自动终止。处理可能会由于许多原因而停止，例如安全性，并且会发送响应。
Either peer may stop operating, and be unavailable for further operations. The authentication and/or authorization parameters of a principal may be changed between operations if desired, to prevent further authentication or authorization for security reasons.
任何一个对等方都可能停止运行，无法进行进一步的操作。如果需要，主体的认证和/或授权参数可以在操作之间更改，以防止出于安全原因进行进一步的认证或授权。
Additionally, managed objects can be defined for realizing sessions that persist beyond processing of a single message. The MIB module would need to specify the responsibility for cleanup of the objects following normal/abnormal termination.
此外，还可以定义托管对象，以实现在处理单个消息之后仍然存在的会话。MIB模块需要指定在正常/异常终止后清理对象的责任。
RSIP: An RSIP client may terminate a session with a DE_REGISTER_REQUEST. An RSIP server may terminate a session with an unsolicited DE_REGISTER_RESPONSE, and then respond to subsequent requests on the session with a REGISTER_FIRST error.
RSIP：RSIP客户端可以通过DE_REGISTER_请求终止会话。RSIP服务器可以使用未经请求的DE_REGISTER_响应终止会话，然后使用REGISTER_FIRST错误响应会话上的后续请求。
Megaco: The Megaco protocol allows both peers to terminate the association with proper reason code.
Megaco:Megaco协议允许两个对等方使用正确的原因码终止关联。
Diameter: Either peer in a connection may issue a Disconnect-Peer-Request to end the connection gracefully.
Diameter：连接中的任何一个对等方都可以发出断开连接的对等方请求以正常结束连接。
COPS: COPS allows both the PEP and PDP to terminate a session.
COPS：COPS允许政治公众人物和PDP终止会话。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: Each operation request has a corresponding response message that contains an error status to indicate success or failure. For complex requests that the middlebox cannot complete immediately, the corresponding MIB module may be designed to also provide asynchronous notifications of the success or failure of the complete transaction, and/or may provide pollable objects that indicate the success or failure of the complete transaction. For example, see ifAdminStatus and ifOperStatus in RFC 2863 [28].
SNMP：每个操作请求都有相应的响应消息，其中包含错误状态，以指示成功或失败。对于中间盒无法立即完成的复杂请求，相应的MIB模块也可设计为提供完成事务成功或失败的异步通知，和/或可提供指示完成事务成功或失败的可轮询对象。例如，请参见RFC 2863[28]中的ifAdminStatus和IFOperatStatus。
RSIP: All RSIP requests result in a paired RSIP response if the request was successful or an ERROR_RESPONSE if the request was not successful.
RSIP：如果请求成功，则所有RSIP请求都会导致成对的RSIP响应；如果请求不成功，则会导致错误响应。
Megaco: Megaco defines a special descriptor called an Error descriptor that contains the error code and an optional explanatory string.
Megaco:Megaco定义了一个称为错误描述符的特殊描述符，其中包含错误代码和可选解释字符串。
Diameter: Every Diameter request is matched by a response, and this response contains a result code as well as other information.
Diameter：每个Diameter请求都匹配一个响应，该响应包含一个结果代码以及其他信息。
COPS: The COPS Report message directly fulfills this requirement.
COPS：COPS报告消息直接满足此要求。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMP has a separation of the protocol to carry data, and the data that defines additional management functionality. Additional functionality can be added easily through MIBs. Capability exchange in SNMP is usually uni-directional. Managers can query the middlebox (SNMP agent) to determine which MIBs are supported. In addition, multiple message versions can be supported simultaneously, and are identified by a version number in the message header.
SNMP:SNMP将传输数据的协议与定义附加管理功能的数据分离。可以通过MIB轻松添加其他功能。SNMP中的功能交换通常是单向的。管理者可以查询中间件（SNMP代理）以确定支持哪些MIB。此外，可以同时支持多个消息版本，并通过消息头中的版本号进行标识。
RSIP: Each RSIP message contains a version parameter.
RSIP：每个RSIP消息都包含一个版本参数。
Megaco: Version interworking and negotiation are supported both for the protocol and any extension Packages.
Megaco：协议和任何扩展包都支持版本互通和协商。
Diameter: The Capabilities Exchange Request/Answer allows two peers to determine information about what each supports, including protocol version and specific applications.
Diameter：交换请求/应答功能允许两个对等方确定各自支持的信息，包括协议版本和特定应用程序。
COPS: The COPS protocol can carry a MIDCOM version number and capability negotiation between the COPS client and the COPS server. This capability negotiation mechanism allows the COPS client and server to communicate the supported features/capabilities. This would allow seamless version interworking.
COPS：COPS协议可以在COPS客户端和COPS服务器之间携带MIDCOM版本号和功能协商。此能力协商机制允许COPS客户端和服务器通信支持的功能/能力。这将允许无缝版本交互。
2.1.12. Deterministic Behaviour in the Presence of Overlapping Rules
2.1.12. 存在重叠规则时的确定性行为
SNMP: T, RSIP: T, Megaco: P, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: P, Diameter: T, COPS: T
SNMP: Rulesets would be defined in MIBs. The priority of rulesets, and the resolution of conflict, can be defined in the MIB module definition. The SNMPConf policy MIB defines mechanisms to achieve deterministic behavior in the presence of overlapping rule sets.
SNMP：规则集将在MIB中定义。规则集的优先级和冲突的解决可以在MIB模块定义中定义。SNMPConf策略MIB定义了在存在重叠规则集的情况下实现确定性行为的机制。
RSIP: All requests for allocation of IP addresses, or ports or both resulting in rule overlap are rejected by an RSIP server with a LOCAL_ADDR_INUSE error.
RSIP：导致规则重叠的所有IP地址或端口分配请求或两者都会被RSIP服务器拒绝，并出现本地地址使用错误。
Megaco: This is met with the help of a model that separates Megaco protocol elements from the overlapping Policy rules (see Appendix C). However, new behavior for the Megaco protocol elements needs to be specified as part of a new MIDCOM specific Package.
Megaco：这是在一个模型的帮助下实现的，该模型将Megaco协议元素从重叠的策略规则中分离出来（见附录C）。但是，需要将Megaco协议元素的新行为指定为新的MIDCOM特定包的一部分。
Diameter: The IPFilterRule type specification, which would probably be used as the type of a Policy Rule AVP, comes with an extensive semantic description providing a deterministic outcome, which the individual Agent cannot know unless it knows all of the Policy Rules installed on the Middlebox. Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny. The IPFilterRule format and further details on its applicability to this requirement are provided in Appendix D.
Diameter:IPFilterRule类型规范（可能用作策略规则AVP的类型）具有广泛的语义描述，提供了确定的结果，单个代理无法知道，除非它知道安装在中间盒上的所有策略规则。相应方向的规则按顺序求值，第一个匹配的规则终止求值。每个数据包评估一次。如果没有匹配的规则，则如果最后一个评估的规则是许可证，则丢弃数据包；如果最后一个规则是拒绝，则传递数据包。附录D中提供了IPFilterRule格式及其对本要求适用性的更多详细信息。
COPS: The COPS protocol provides transactional-based communication between the PEP and PDP, hence the behavior is totally deterministic provided the middlebox state machine is designed correctly. The COPS protocol features encourage and support good state machine design.
COPS：COPS协议在PEP和PDP之间提供基于事务的通信，因此，只要中间箱状态机设计正确，行为是完全确定的。COPS协议的特性鼓励并支持良好的状态机设计。
This section contains the individual protocols as evaluated against the protocol semantic requirements from section 2.2 of the requirements document [1]. A short description of each of the protocols is provided to substantiate the evaluation.
本节包含根据需求文件[1]第2.2节中的协议语义要求评估的各个协议。为证实评估，提供了每个协议的简短描述。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: Extensibility is a basic feature of the SNMP management Framework.
SNMP：可扩展性是SNMP管理框架的一个基本特性。
RSIP: All RSIP messages consist of three mandatory fields (protocol version, message type, and message length) and a sequence of parameterType / length / value 3-tuples. New messages may be defined by defining new values for the message type field. New parameter types may be defined, and existing messages may be extended, by defining new parameterType values. If new messages, parameters, or both are added in a non-backward compatible way, a new value of the protocol version field may be defined. This may be desirable even of the additions are backward compatible.
RSIP：所有RSIP消息都由三个必填字段（协议版本、消息类型和消息长度）和一系列参数类型/长度/值3元组组成。可以通过为消息类型字段定义新值来定义新消息。通过定义新的parameterType值，可以定义新的参数类型，并且可以扩展现有消息。如果以不向后兼容的方式添加新消息、参数或两者，则可以定义协议版本字段的新值。这可能是可取的，即使是向后兼容的添加。
Megaco: Megaco is easily extensible through new Packages, which allow definition of new attributes and behavior of a Termination.
Megaco:Megaco很容易通过新的包进行扩展，这些包允许定义新的属性和终止行为。
Diameter: Diameter provides a great deal of flexibility for extensions, including allowance for vendor-defined commands and AVPs and the ability to flag each AVP as must-understand or ignorable if not understood.
Diameter：Diameter为扩展提供了很大的灵活性，包括允许供应商定义的命令和AVP，以及将每个AVP标记为必须理解或不理解时可忽略的能力。
COPS: The COPS protocol is extensible, since it was designed to separate the Protocol from the Policy Control Information.
COPS：COPS协议是可扩展的，因为它被设计用于将协议与策略控制信息分离。
SNMP: T, RSIP: P+, Megaco: T, Diameter: P+, COPS: T
SNMP: T, RSIP: P+, Megaco: T, Diameter: P+, COPS: T
SNMP: SNMP explicitly supports managing different device types with different capabilities. First the managed object called sysObjectID from basic MIB-II [3] identifies the type of box. For boxes with variable capabilities, SNMP can check the availability of corresponding MIBs.
SNMP:SNMP明确支持管理具有不同功能的不同设备类型。首先，基本MIB-II[3]中名为sysObjectID的托管对象标识框的类型。对于具有可变功能的机箱，SNMP可以检查相应MIB的可用性。
RSIP: All types of middleboxes are supported so long as the ruleset action is permit. Other actions would require the definition of a new RSIP message parameter with values for permit and the other desired actions.
RSIP：只要规则集操作允许，就支持所有类型的中间盒。其他操作将需要定义一个新的RSIP消息参数，该参数包含许可和其他所需操作的值。
Megaco: Megaco can support multiple Middlebox types on the same interface either by designing the properties representing the Policy Rules to provide this support, or by using multiple terminations in the same session, each representing one type of action. In the latter case, the Megaco Context can be used as a convenient means of managing the related terminations as a group. However, the inherent idea of flow between terminations of a context is irrelevant and would have to be discarded.
Megaco:Megaco可以通过设计表示策略规则的属性来提供支持，或者通过在同一会话中使用多个终端（每个终端代表一种操作类型），在同一接口上支持多种中间盒类型。在后一种情况下，Megaco上下文可作为一种方便的方式，将相关终端作为一个组进行管理。然而，上下文终止之间的流的固有概念是不相关的，必须放弃。
Diameter: Any necessary additional AVPs or values must be specified as part of the MIDCOM application extension (see <2.2.8> below).
直径：任何必要的附加AVP或值必须指定为MIDCOM应用程序扩展的一部分（见下文<2.2.8>）。
COPS: COPS allows a PDP to provide filters and actions to multiple PEP functions through a single COPS session.
COPS：COPS允许PDP通过单个COPS会话向多个PEP功能提供过滤器和操作。
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: This requirement can be realized via the SNMP management framework by an appropriate definition of a MIB module. The SNMPConf WG has already defined an SNMP Policy MIB that permits the definitions of policy rulesets and grouping of rulesets.
SNMP：通过适当定义MIB模块，可通过SNMP管理框架实现此要求。SNMPConf WG已经定义了一个SNMP策略MIB，它允许定义策略规则集和对规则集进行分组。
RSIP: RSIP currently only allows one IP address, or address and port range, to be assigned to a bind-ID. RSIP could implement rulesets as required by adding an optional bind-ID parameter to the ASSIGN_REQUESTs to extend an existing ruleset rather than creating a new one. Similarly, the FREE_REQUESTs would have to be extended by adding optional, local and remote, address and port parameters.
RSIP:RSIP目前只允许将一个IP地址或地址和端口范围分配给bind-ID。RSIP可以根据需要实施规则集，方法是向ASSIGN_请求添加可选的bind ID参数以扩展现有规则集，而不是创建新的规则集。类似地，必须通过添加可选的本地和远程、地址和端口参数来扩展FREE_请求。
Megaco: The Megaco context can be used to group terminations to be managed together. For example, all of the terminations, each representing an instantiation of a Policy Rule, can be deleted in one command by doing a wildcarded Subtract from the context. However, the inherent idea of media flows between terminations of a context would be irrelevant in this application of the protocol.
Megaco:Megaco上下文可用于将要一起管理的终端分组。例如，通过从上下文执行通配符减法，可以在一个命令中删除所有终止，每个终止表示策略规则的实例化。然而，在协议的这种应用中，上下文终止之间的媒体流的固有概念是不相关的。
Diameter: Diameter allows message syntax definitions where multiple instances of the same AVP (for example, a Policy Rule AVP whose syntax and low-level semantics are defined by the IPFilterRule type definition) may be present. If a tighter grouping is
Diameter:Diameter允许消息语法定义，其中可能存在同一AVP的多个实例（例如，其语法和低级语义由IPFilterRule类型定义定义的策略规则AVP）。如果需要更紧密的分组
required, the set of Diameter base types includes the Grouped type. MIDCOM can choose how to make use of these capabilities to meet the ruleset group requirement when defining its application extension to the Diameter protocol.
如果需要，则直径基础类型集包括分组类型。MIDCOM在定义其对Diameter协议的应用程序扩展时，可以选择如何利用这些功能来满足规则集组的要求。
COPS: The COPS-PR Handle State may be used to associate the set of closely related policy objects. As the Middlebox learns additional requirements, the Middlebox adds these resource requirements under the same handle ID, which constitutes the required aggregation.
COPS:COPS-PR句柄状态可用于关联一组密切相关的策略对象。当中间盒了解到其他需求时，中间盒会在相同的句柄ID下添加这些资源需求，这构成了所需的聚合。
SNMP: P+, RSIP: T, Megaco: T, Diameter: T, COPS: P+
SNMP: P+, RSIP: T, Megaco: T, Diameter: T, COPS: P+
SNMP: This requirement can be realized via the SNMP management framework by an appropriate definition of a MIB module. The SNMPConf WG has developed a Policy MIB module that includes a pmPolicySchedule object with a modifiable lifetime.
SNMP：通过适当定义MIB模块，可通过SNMP管理框架实现此要求。SNMPConf工作组开发了一个策略MIB模块，其中包括一个具有可修改生存期的pmPolicySchedule对象。
RSIP: A client may request an explicit lease time when a request is made to assign one or more IP addresses, ports or both. The server may grant the requested lease time, or assign one if none was requested. Subsequently, the lease time may be extended if a client's EXTEND_REQUEST is granted by the server.
RSIP：当请求分配一个或多个IP地址、端口或两者时，客户端可能会请求显式租赁时间。服务器可以授予请求的租赁时间，如果没有请求，则可以分配一个租赁时间。随后，如果服务器允许客户端的EXTEND_请求，则可以延长租赁时间。
Megaco: The MG can report the imminent expiry of a policy rule to the MGC, which can then extend or delete the corresponding Termination.
Megaco：MG可以向MGC报告即将到期的保单规则，然后MGC可以延长或删除相应的终止。
Diameter: The Diameter concept of a session includes the session lifetime, grace period, and lifetime extension. It may make sense to associate the Diameter session with the lifetime of a MIDCOM Policy Rule, in which case support for lifetime extension comes ready-made.
Diameter：会话的Diameter概念包括会话生存期、宽限期和生存期扩展。将Diameter会话与MIDCOM策略规则的生存期相关联可能是有意义的，在这种情况下，对生存期扩展的支持已经准备就绪。
COPS: COPS allows a PDP to send unsolicited decisions to the PEP. However, the unsolicited events will be relevant to the COPS MIDCOM specific client or the MIDCOM specific PIB which needs to be defined. This would allow the PDP to extend the lifetime of an existing ruleset.
警察：警察允许PDP向政治公众人物发送未经请求的决定。但是，未经请求的事件将与需要定义的COPS MIDCOM特定客户或MIDCOM特定PIB相关。这将允许PDP延长现有规则集的生存期。
SNMP: T, RSIP: T, Megaco: P+, Diameter: P+, COPS: T
SNMP: T, RSIP: T, Megaco: P+, Diameter: P+, COPS: T
SNMP: Unknown attributes in a read operation are flagged as exceptions in the Response message, but the rest of the read succeeds. In a write operation (a SET request), all attributes are validated before the write is performed. If there are unknown attributes, the request fails and no writes are done. Unknown attributes are flagged as exceptions in the Response message, and the error status is reported.
SNMP：读取操作中的未知属性在响应消息中标记为异常，但其余读取操作成功。在写入操作（SET请求）中，所有属性都会在执行写入之前进行验证。如果存在未知属性，则请求将失败，并且不会执行任何写入操作。响应消息中将未知属性标记为异常，并报告错误状态。
RSIP: All options of all requests are fully specified. Not understood parameters must be reported by an ERROR_RESPONSE with an EXTRA_PARM error value, with the entire request otherwise ignored.
RSIP：所有请求的所有选项都已完全指定。未理解的参数必须由带有额外\u PARM错误值的错误\u响应报告，否则将忽略整个请求。
Megaco: Megaco entities provide Error codes in response messages. If a command marked "Optional" in a transaction fails, the remaining commands will continue. However, the specified requirement deals with rules of processing properties that need definition in new Package.
Megaco:Megaco实体在响应消息中提供错误代码。如果事务中标记为“可选”的命令失败，其余命令将继续。然而，指定的需求处理需要在新包中定义的处理属性的规则。
Diameter: Indication of the mandatory or optional status of AVPs is fully supported, provided it is enabled in the AVP definition. No guidance is imposed regarding the return of diagnostic information for optional AVPs.
直径：如果在AVP定义中启用，则完全支持AVP的强制或可选状态指示。没有关于返回可选AVP诊断信息的指南。
COPS: COPS provides for the exchange of capabilities and limitations between the PEP and PDP to ensure well-known outcomes are understood for scenarios with unknown attributes. There is also clear error handling for situations when the request is rejected.
COPS：COPS提供PEP和PDP之间的能力和限制交换，以确保对于具有未知属性的场景了解众所周知的结果。对于请求被拒绝的情况，也有明确的错误处理。
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: The SNMPv3 protocol returns error codes and exception codes in Response messages, to permit the requestor to modify their request. Errors and exceptions indicate the attribute that caused the error, and an error code identifies the nature of the error encountered.
SNMP:SNMPv3协议在响应消息中返回错误代码和异常代码，以允许请求者修改其请求。错误和异常指示导致错误的属性，错误代码标识遇到的错误的性质。
If desired, a MIB can be designed to provide additional data about error conditions either via asynchronous notifications or polled objects.
如果需要，可以设计MIB，通过异步通知或轮询对象提供有关错误条件的附加数据。
RSIP: RSIP defines a fairly large number of very specific error values. It is anticipated that additional error values will also have to be defined along with the new messages and parameters required for MIDCOM.
RSIP:RSIP定义了大量非常具体的错误值。预计还必须定义其他错误值以及MIDCOM所需的新消息和参数。
Megaco: The MG can provide Error codes in response messages allowing the MGC to modify its behavior. Megaco uses transaction identifiers for correlation between a response and a command. If the same transaction id is received more than once, the receiving entity silently discards the message, thus providing some protection against replay attacks.
Megaco:MG可以在响应消息中提供错误代码，允许MGC修改其行为。Megaco使用事务标识符来关联响应和命令。如果同一事务id被多次接收，则接收实体会自动丢弃消息，从而提供一些防止重播攻击的保护。
Diameter: Diameter provides an extensive set of failure reasons in the base protocol.
Diameter：Diameter在基本协议中提供了一组广泛的失败原因。
COPS: COPS uses an error object to identify a particular COPS protocol error. The error sub-code field may contain additional detailed COPS client (MIDCOM Middlebox) specific error codes.
COPS：COPS使用错误对象来标识特定的COPS协议错误。错误子代码字段可能包含其他详细的COPS客户端（MIDCOM Middlebox）特定错误代码。
2.2.7. Multiple Agents Operating on the Same Ruleset.
2.2.7. 在同一规则集上运行的多个代理。
SNMP: T, RSIP: P, Megaco: P, Diameter: T, COPS: P
SNMP: T, RSIP: P, Megaco: P, Diameter: T, COPS: P
SNMP: The SNMP framework supports multiple managers working on the same managed objects. The View-based Access Control Model (VACM, RFC 3415 [14]) even offers means to customize the access rights of different managers in a fine-grained way.
SNMP：SNMP框架支持在同一受管对象上工作的多个管理器。基于视图的访问控制模型（VACM，RFC 3415[14]）甚至提供了以细粒度方式定制不同管理者访问权限的方法。
RSIP: RSIP neither explicitly permits nor precludes an operation on a binding by a host that had not originally create the binding. However, to support this requirement, the RSIP semantics must be extended to explicitly permit any authorized host to request operations on a binding; this does not require a change to the protocol.
RSIP:RSIP既不明确允许也不排除最初未创建绑定的主机对绑定执行的操作。然而，为了支持这一要求，必须扩展RSIP语义，以明确允许任何授权主机请求绑定上的操作；这不需要更改协议。
Megaco: If the Megaco state machine on the Middle Box is decoupled from the Middle Box policy rule management, this requirement can be met with local policies on the Middle Box. However, this violates the spirit of the Megaco protocol, thus Megaco is considered partially compliant to this requirement.
Megaco：如果中间盒上的Megaco状态机与中间盒策略规则管理分离，则中间盒上的本地策略可以满足此要求。但是，这违反了Megaco协议的精神，因此Megaco被视为部分符合该要求。
Diameter: The Diameter protocol, as currently defined, would allow multiple agents to operate on the same ruleset.
Diameter：当前定义的Diameter协议允许多个代理在同一规则集上操作。
COPS: It is possible to use COPS to operate the same resource with multiple agents. An underlying resource management function, separate from the COPS state machine, on the Middlebox will handle the arbitration when resource conflicts happen.
COPS：可以使用COPS与多个代理操作同一资源。与COPS状态机分离的一个底层资源管理功能（位于中间盒上）将在发生资源冲突时处理仲裁。
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module. SMI, the language used for defining MIB modules, is flexible enough to allow the implementation of a MIB module to meet the semantics of this requirement.
SNMP：可以通过适当定义MIDCOM MIB模块来满足此要求。用于定义MIB模块的语言SMI足够灵活，允许MIB模块的实现满足此需求的语义。
RSIP: To support this requirement, a new optional enumeration parameter, transportProtocol, can be added to the RSIP ASSIGN_REQUESTs. When the parameter is included, the binding created applies only to the use of the bound addresses and ports, by the specific transportProtocol. When the parameter is not included, the binding applies to the use of all the bound addresses and ports, by any transport protocol, thus maintaining backward compatibility with the current definition of RSIP.
RSIP：为了支持此要求，可以将新的可选枚举参数transportProtocol添加到RSIP ASSIGN_请求中。当包含该参数时，创建的绑定仅适用于特定传输协议对绑定地址和端口的使用。如果不包括该参数，则绑定将应用于任何传输协议对所有绑定地址和端口的使用，从而保持与当前RSIP定义的向后兼容性。
Megaco: Megaco protocol can meet this requirement by defining a new property for the transport of filtering rules.
Megaco:Megaco协议可以通过定义过滤规则传输的新属性来满足此要求。
Diameter: While Diameter defines the promising IPFilterRule data type (see 2.1.12 above), there is no existing message, which would convey this to a Middlebox along with other required MIDCOM attributes. A new MIDCOM application extension of Diameter would have to be defined.
Diameter：虽然Diameter定义了有前途的IPFilterRule数据类型（见上面的2.1.12），但没有任何现有的消息可以将其与其他所需的MIDCOM属性一起传送到中间盒。必须定义直径的新MIDCOM应用程序扩展。
COPS: The COPS protocol can meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：通过使用COPS MIDCOM特定客户端或MIDCOM特定PIB，COPS协议可以满足此要求。
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module.
SNMP：可以通过适当定义MIDCOM MIB模块来满足此要求。
RSIP: To support this requirement, a new optional boolean parameter, portOddity, can be added to the RSIP ASSIGN_REQUESTs. If the parameter is TRUE, the remote port number of the binding created would have the same oddity as the local port. If the parameter is not specified, or is FALSE, the remote port's oddity is independent of the local port's oddity, thus maintaining backward compatibility with the current definition of RSIP.
RSIP：为了支持此要求，可以向RSIP ASSIGN_请求中添加一个新的可选布尔参数portOddity。如果参数为TRUE，则创建的绑定的远程端口号将与本地端口具有相同的奇数。如果该参数未指定或为FALSE，则远程端口的异常独立于本地端口的异常，从而保持与当前RSIP定义的向后兼容性。
Megaco: Megaco can be easily extended using a MIDCOM specific Package to support this feature.
Megaco:Megaco可以使用MIDCOM特定的软件包轻松扩展以支持此功能。
Diameter: This capability is not part of the current IPFilterRule type definition. Rather than modify the IPFilterRule type, MIDCOM could group it with other AVPs which add the missing information.
直径：此功能不是当前IPFilterRule类型定义的一部分。MIDCOM不需要修改IPFilterRule类型，而是可以将其与添加缺失信息的其他AVP分组。
COPS: The COPS protocol has all the flexibility to meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：通过使用COPS MIDCOM特定客户端或MIDCOM特定PIB，COPS协议具有满足此要求的所有灵活性。
SNMP: P+, RSIP: T, Megaco: P+, Diameter: P+, COPS: P+
SNMP: P+, RSIP: T, Megaco: P+, Diameter: P+, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module. SMI, the language used for defining MIB modules, is flexible enough to allow the implementation of a MIB module to meet the semantics of this requirement.
SNMP：可以通过适当定义MIDCOM MIB模块来满足此要求。用于定义MIB模块的语言SMI足够灵活，允许MIB模块的实现满足此需求的语义。
RSIP: The ports parameter of the RSIP ASSIGN_REQUESTs specifically allows multiple, consecutive port numbers to be specified.
RSIP:RSIP ASSIGN_请求的ports参数特别允许指定多个连续的端口号。
Megaco: Megaco can be easily extended using a MIDCOM specific Package to support this feature.
Megaco:Megaco可以使用MIDCOM特定的软件包轻松扩展以支持此功能。
Diameter: This capability is not part of the current IPFilterRule type definition. Rather than modify the IPFilterRule type, MIDCOM could group it with other AVPs which add the missing information.
直径：此功能不是当前IPFilterRule类型定义的一部分。MIDCOM不需要修改IPFilterRule类型，而是可以将其与添加缺失信息的其他AVP分组。
COPS: The COPS protocol has all the flexibility to meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：通过使用COPS MIDCOM特定客户端或MIDCOM特定PIB，COPS协议具有满足此要求的所有灵活性。
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: T, COPS: P+
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: T, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module.
SNMP：可以通过适当定义MIDCOM MIB模块来满足此要求。
RSIP: To support this requirement, a new optional boolean parameter, overlapOK, can be added to the RSIP ASSIGN_REQUESTs. If the parameter is TRUE, the binding may overlap with an existing binding. If the parameter is unspecified, or is FALSE, the binding will not overlap with an existing binding, thus maintaining backward compatibility with the current definition of RSIP.
RSIP：为了支持此要求，可以向RSIP ASSIGN_请求中添加一个新的可选布尔参数OverlappOK。如果参数为TRUE，则绑定可能与现有绑定重叠。如果参数未指定或为FALSE，则绑定将不会与现有绑定重叠，从而保持与当前RSIP定义的向后兼容性。
Megaco: This requirement would be met if the policy in the Middlebox allows contradictory, overlapping policy rules to be installed.
Megaco：如果中间盒中的策略允许安装相互矛盾、重叠的策略规则，则可以满足此要求。
Diameter: Allowed by the IPFilterRule semantics described in Appendix D.
直径：附录D中描述的IPFilterRule语义允许。
COPS: The COPS protocol has all the flexibility to meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：通过使用COPS MIDCOM特定客户端或MIDCOM特定PIB，COPS协议具有满足此要求的所有灵活性。
This section contains the individual protocols as evaluated against the General Security requirements from section 2.3 of the requirements document [1]. A short description of each of the protocols is provided to substantiate the evaluation.
本节包含根据需求文件[1]第2.3节的一般安全要求评估的各个协议。为证实评估，提供了每个协议的简短描述。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 includes the User-based Security Model (USM, RFC 3414 [11]), which defines three standardized methods for providing authentication, confidentiality, and integrity. Additionally, USM has specific built-in mechanisms for preventing replay attacks including unique protocol engine IDs, timers and counters per engine and time windows for the validity of messages.
SNMP:SNMPv3包括基于用户的安全模型（USM，RFC 3414[11]），该模型定义了三种用于提供身份验证、机密性和完整性的标准化方法。此外，USM具有防止重播攻击的特定内置机制，包括每个引擎的唯一协议引擎ID、计时器和计数器以及消息有效性的时间窗口。
RSIP: This requirement can be met by operating RSIP over IPSec. The RSIP framework recommends all communication between an RSIP host and gateway be authenticated. Authentication, in the form of a message hash appended to the end of each RSIP protocol packet, can serve to authenticate the RSIP host and gateway to one another, provide message integrity, and avoid replay attacks with an anti-replay counter. However, the message hash and replay counter parameters would need to be defined for the RSIP protocol.
RSIP：通过IPSec操作RSIP可以满足此要求。RSIP框架建议对RSIP主机和网关之间的所有通信进行身份验证。以消息散列的形式附加到每个RSIP协议包的末尾的身份验证可用于相互验证RSIP主机和网关，提供消息完整性，并使用反重放计数器避免重放攻击。但是，需要为RSIP协议定义消息散列和重播计数器参数。
Megaco: Megaco provides for these functions with the combined usage of IPSEC [22] or TLS [21].
Megaco:Megaco结合使用IPSEC[22]或TLS[21]提供这些功能。
Diameter: Diameter relies on either IPSEC or TLS for these functions.
Diameter:Diameter依赖于IPSEC或TLS来实现这些功能。
COPS: COPS has built-in message level security for authentication, replay protection, and message integrity. COPS can also use TLS or IPSec, thus reusing existing security mechanisms that have interoperated in the markets.
COPS:COPS具有用于身份验证、重播保护和消息完整性的内置消息级安全性。COP还可以使用TLS或IPSec，从而重用已在市场上互操作的现有安全机制。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 includes the User-based Security Model, which defines three standardized methods for providing authentication, confidentiality, and integrity, and is open to add further methods. The method to use can be optionally chosen.
SNMP:SNMPv3包括基于用户的安全模型，该模型定义了三种用于提供身份验证、机密性和完整性的标准化方法，并且可以添加更多方法。可以选择要使用的方法。
RSIP: Refer to 2.3.1.
RSIP：参考2.3.1。
Megaco: Refer to 2.3.1
Megaco：参考2.3.1
Diameter: Implementation support of IPSEC ESP (RFC 2406 [23]) in Diameter applications is not optional. Deployment of either IPSEC or TLS is optional.
Diameter：Diameter应用程序中对IPSEC ESP（RFC 2406[23]）的实现支持不是可选的。IPSEC或TLS的部署是可选的。
COPS: Refer to 2.3.1.
警察：参见2.3.1。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: The User-based Security Model of SNMPv3 defines three standardized methods for providing authentication, confidentiality, and integrity, and it is open to add further methods. These methods operate securely across untrusted domains.
SNMP:SNMPv3的基于用户的安全模型定义了三种标准化的方法来提供身份验证、机密性和完整性，并且可以添加更多的方法。这些方法跨不受信任的域安全地运行。
RSIP: Refer to 2.3.1.
RSIP：参考2.3.1。
Megaco: Refer to 2.3.1.
Megaco：参考2.3.1。
Diameter: The Diameter specification [24] recommends the use of TLS [21] across untrusted domains.
直径：直径规范[24]建议跨不受信任的域使用TLS[21]。
COPS: Refer to 2.3.1
警察：参见2.3.1
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: The User-based Security Model for SNMPv3 has specific built-in mechanisms for preventing replay attacks including unique protocol engine IDs, timers and counters per engine and time windows for the validity of messages.
SNMP:SNMPv3基于用户的安全模型具有防止重播攻击的特定内置机制，包括每个引擎的唯一协议引擎ID、计时器和计数器以及消息有效性的时间窗口。
RSIP: Refer to 2.3.1
RSIP：参考2.3.1
Megaco: Megaco commands and responses include matching transaction identifiers. The recipient receiving the same transaction id multiple times would discard the message, thus providing some protection against replay attacks. If even stronger protection against replay attack is needed, Megaco provides for the use of IPSec or TLS.
Megaco:Megaco命令和响应包括匹配的事务标识符。多次接收相同事务id的收件人将丢弃该消息，从而提供一些防止重播攻击的保护。如果需要针对重播攻击提供更强大的保护，Megaco将提供IPSec或TLS的使用。
Diameter: Diameter requires that implementations support the replay protection mechanisms of IPSEC.
Diameter:Diameter要求实现支持IPSEC的重播保护机制。
COPS: Refer to 2.3.1
警察：参见2.3.1
The overall statistics with regards to the number of Fully Compliant, Partially Compliant (P+ and P) and Failing Compliancy requirements for each of the protocols is summarized in table 1.
表1总结了关于每个协议的完全符合、部分符合（P+和P）和不符合要求的总体统计数据。
T P+ P F
-----------------------------------------------------------------
SNMP 22 5 0 0
RSIP 17 7 3 0
Megaco 19 5 3 0
Diameter 21 5 1 0
COPS 20 5 2 0
T P+ P F
-----------------------------------------------------------------
SNMP 22 5 0 0
RSIP 17 7 3 0
Megaco 19 5 3 0
Diameter 21 5 1 0
COPS 20 5 2 0
Table 1: Totals across all Requirements
表1：所有要求的总数
In considering the P+ category of compliancy, an important aspect is the mechanism for support of extensibility. The extension mechanism provided by SNMP and COPS-PR using MIBs and PIBs respectively, provides extensions with no impact to the protocol. Diameter extensions require protocol changes, thus has a higher impact, although the extensions can be handled by other Diameter entities without being understood. Megaco's extension mechanisms of packages also requires protocol changes that must be understand by both sending and receiving entities, also being considered higher impact. The RSIP extension mechanism has the largest impact on the existing protocol and is based upon defining the necessary new parameters.
在考虑遵从性的P+类别时，一个重要方面是支持可扩展性的机制。SNMP和COPS-PR分别使用MIB和PIB提供的扩展机制提供了对协议没有影响的扩展。Diameter扩展需要更改协议，因此具有更高的影响，尽管扩展可以由其他Diameter实体处理而不被理解。Megaco的包扩展机制还需要协议更改，发送实体和接收实体都必须理解这些更改，这也被认为具有更大的影响。RSIP扩展机制对现有协议的影响最大，它基于定义必要的新参数。
The SNMP management framework meets all the specified MIDCOM protocol requirements with the appropriate design of a MIDCOM MIB module. SNMP is a proven technology with stable and proven development tools, already has extensions defined to support NAT configuration and policy-based management. SNMPv3 is a full standard, is more mature and has undergone more validation than the other protocols in
SNMP管理框架通过适当设计的MIDCOM MIB模块满足所有指定的MIDCOM协议要求。SNMP是一种经验证的技术，具有稳定且经验证的开发工具，已经定义了扩展以支持NAT配置和基于策略的管理。SNMPv3是一个完整的标准，比其他协议更成熟，经过了更多的验证
the evaluation, and has been deployed to manage large-scale real-world networks (e.g., DOCSIS cable modem networks). The applicability of SNMP to the MIDCOM framework has a restriction in that it assumes the MIDCOM PDP is part of the Middlebox.
评估，并已部署用于管理大规模现实网络（如DOCSIS电缆调制解调器网络）。SNMP对MIDCOM框架的适用性有一个限制，因为它假定MIDCOM PDP是中间盒的一部分。
RSIP fully meets many of the MIDCOM requirements. However, it does require additions and extensions to meet several of the requirements. RSIP would also require several framework elements to be added to the MIDCOM framework as identified in section 1.2.3. In addition, the tunneling required for RSIP as described in section 1.2.4, results in RSIP not being acceptable by the WG as the MIDCOM protocol.
RSIP完全满足许多MIDCOM要求。但是，它确实需要添加和扩展以满足一些要求。RSIP还需要将几个框架元素添加到MIDCOM框架中，如第1.2.3节所述。此外，第1.2.4节所述RSIP所需的隧道导致工作组不接受RSIP作为MIDCOM协议。
Megaco fully meets most of the key requirements for the MIDCOM Protocol. Additional extensions in the form of a new Termination / Package definition would be required for MIDCOM to meet several of the requirements. In order to meet the remaining requirements, modeling the underlying Middlebox resources (e.g., filters, policy rules) as separate elements from the Megaco entities might allow the usage of the protocol as-is, satisfying some of the resource access control requirements.
Megaco完全满足MIDCOM协议的大部分关键要求。MIDCOM需要以新的终止/包定义的形式进行额外扩展，以满足若干要求。为了满足剩余的需求，将底层中间包资源（例如，过滤器、策略规则）建模为与Megaco实体分离的元素可能允许按原样使用协议，以满足某些资源访问控制需求。
The Diameter evaluation indicated a good overall fit. Some partially met requirements were identified that could be addressed by a new application extension. However, the Diameter architecture may be too heavy for the MIDCOM application and clearly much of the Diameter base is not needed. In addition, Diameter is the only protocol, at the time of this evaluation, for which the RFCs had not yet been published. Other than these reservations, the protocol is a good fit to MIDCOM requirements.
直径评估表明整体配合良好。确定了一些部分满足的需求，这些需求可以通过新的应用程序扩展来解决。然而，对于MIDCOM应用程序来说，Diameter架构可能太重，显然不需要Diameter的大部分基础。此外，在本次评估时，Diameter是唯一尚未公布RFC的协议。除了这些保留，该协议非常适合MIDCOM要求。
The COPS evaluation indicates that the protocol meets the majority of the MIDCOM protocol requirements by using the protocol's native extension techniques, with COPS-PR being explicitly required to meet requirements 2.1.3 and 2.2.3. In order to fully satisfy one partially met requirement, 2.1.1, the COPS model would need to allow a PDP to establish communication with a PEP. While not explicitly prohibited by the COPS model, this would require additions, in the form of local policy, to ensure the proper establishment of an authorized association.
COPS评估表明，通过使用协议的本机扩展技术，协议满足大多数MIDCOM协议要求，明确要求COPS-PR满足要求2.1.3和2.2.3。为了完全满足部分满足的要求2.1.1，COPS模型需要允许PDP与政治公众人物建立通信。虽然COPS模式没有明确禁止，但这需要以当地政策的形式进行补充，以确保适当建立授权协会。
Security considerations for the MIDCOM protocol are covered by the comparison against the specific Security requirements in the MIDCOM requirements document [1] and are specifically addressed by section 2.1.8 and section 2.3.
与MIDCOM要求文件[1]中特定安全要求的比较涵盖了MIDCOM协议的安全考虑因素，并在第2.1.8节和第2.3节中进行了具体阐述。
[1] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (MIDCOM) Protocol Requirements", RFC 3304, August 2002.
[1] R.斯瓦尔、P.马特、P.斯吉本、S.布里姆和M.肖尔，“中间箱通信（MIDCOM）协议要求”，RFC 33042002年8月。
[2] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox Communications Architecture and Framework", RFC 3303, August 2002.
[2] Srisuresh，P.，Kuthan，J.，Rosenberg，J.，Molitor，A.，和A.Rayhan，“中间箱通信架构和框架”，RFC3303，2002年8月。
[3] Rose, M. and K. McCloghrie, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
[3] Rose，M.和K.McCloghrie，“基于TCP/IP的互联网网络管理的管理信息库：MIB-II”，STD 17，RFC 1213，1991年3月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", STD 62, RFC 3411, December 2002.
[5] Harrington，D.，Presohn，R.，和B.Wijnen，“描述SNMP管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[6] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[6] McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[7] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[7] McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[8] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[8] McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[9] Presuhn, R. (Ed.), "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[9] Presohn，R.（编辑），“简单网络管理协议（SNMP）的传输映射”，STD 62，RFC 34172002年12月。
[10] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[10] Case，J.，Harrington D.，Presohn R.，和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，STD 62，RFC 3412，2002年12月。
[11] Blumenthal, U. and B. Wijnen, "User-based Security Model(USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[11] Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版的基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月。
[12] Presuhn, R. (Ed.), "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[12] Presohn，R.（编辑），“简单网络管理协议（SNMP）的协议操作第2版”，STD 62，RFC 3416，2002年12月。
[13] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", STD 62, RFC 3413, December 2002.
[13] Levi，D.，Meyer，P.和B.Stewart，“SNMPv3应用”，STD 62，RFC 3413，2002年12月。
[14] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[14] Wijnen，B.，Presuhn，R.，和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，STD 62，RFC 3415，2002年12月。
[15] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-Standard Network Management Framework", RFC 3410, December 2002.
[15] Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准网络管理框架第3版简介”，RFC 3410，2002年12月。
[16] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, March 2005.
[16] Rohit，R.，Srisuresh，P.，Raghunarayan，R.，Pai，N.，和C.Wang，“网络地址转换器（NAT）管理对象的定义”，RFC 4008，2005年3月。
[17] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[17] Borella，M.，Lo，J.，Grabelsky，D.，和G.黑山，“特定领域知识产权：框架”，RFC 3102，2001年10月。
[18] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[18] Borella，M.，Grabelsky，D.，Lo，J.，和K.Taniguchi，“领域特定IP：协议规范”，RFC 3103，2001年10月。
[19] Montenegro, G. and M. Borella, "RSIP Support for End-to-end Ipsec", RFC 3104, October 2001.
[19] 黑山G.和M.Borella，“RSIP对端到端Ipsec的支持”，RFC 3104，2001年10月。
[20] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B., and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, October 2001.
[20] Cuervo，F.，Greene，N.，Rayhan，A.，Huitema，C.，Rosen，B.，和J.Segers，“Megaco协议版本1.0”，RFC 3015，2001年10月。
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[21] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[22] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[22] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[23] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
[23] Kent，S.和R.Atkinson，“IP封装安全有效载荷”，RFC 2406，1998年11月。
[24] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[24] Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[25] Durham, D. (Ed.), Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[25] 达勒姆，D.（编辑），博伊尔，J.，科恩，R.，赫尔佐格，S.，拉詹，R.，和A.萨斯特里，“共同开放政策服务协议”，RFC 2748，2000年1月。
[26] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning", RFC 3084, March 2001.
[26] Chan，K.，Seligson，J.，Durham，D.，Gai，S.，McCloghrie，K.，Herzog，S.，Reichmeyer，F.，Yavatkar，R.，和A.Smith，“政策制定的COPS使用”，RFC 3084，2001年3月。
[27] Raz, D., Schoenwalder, J., and B. Sugla, "An SNMP Application Level Gateway for Payload Address Translation", RFC 2962, October 2000.
[27] Raz，D.，Schoenwalder，J.，和B.Sugla，“用于有效负载地址转换的SNMP应用程序级网关”，RFC 2962，2000年10月。
[28] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[28] McCloghrie，K.和F.Kastenholz，“接口组MIB”，RFC 28632000年6月。
The editor would like to acknowledge the constructive feedback provided by Joel M. Halpern on the individual protocol evaluation contributions. In addition, a thanks to Elwyn Davies, Christopher Martin, Bob Penfield, Scott Brim and Martin Stiemerling for contributing to the mailing list discussion on the document content.
编辑想感谢Joel M.Halpern就个人方案评估贡献提供的建设性反馈。此外，感谢Elwyn Davies、Christopher Martin、Bob Penfield、Scott Brim和Martin Stiemerling为邮件列表讨论文档内容做出的贡献。
Appendix A - SNMP Overview
附录A-SNMP概述
The SNMP Management Framework presently consists of five major components:
SNMP管理框架目前由五个主要组件组成：
o An overall architecture, described in RFC 3411 [5]. A more detailed introduction and applicability statements for the SNMP Management Framework can be found in RFC 3410 [15].
o RFC 3411[5]中描述的总体架构。有关SNMP管理框架的更详细介绍和适用性说明，请参见RFC 3410[15]。
o Mechanisms for describing and naming objects and events for the purpose of management. The current version of this Structure of Management Information (SMI) is called SMIv2 and described in RFC 2578 [6], RFC 2579 [7] and RFC 2580 [8].
o 为管理目的描述和命名对象和事件的机制。这种管理信息结构（SMI）的当前版本称为SMIv2，在RFC 2578[6]、RFC 2579[7]和RFC 2580[8]中进行了描述。
o Message protocols for transferring management information. The current version of the message protocol is called SNMPv3 and described in RFC 3412 [10], RFC 3414 [11] and RFC 3417 [9].
o 用于传输管理信息的消息协议。消息协议的当前版本称为SNMPv3，在RFC 3412[10]、RFC 3414[11]和RFC 3417[9]中进行了描述。
o Protocol operations for accessing management information. The current version of the protocol operations and associated PDU formats is described in RFC 3416 [12].
o 访问管理信息的协议操作。RFC 3416[12]中描述了协议操作和相关PDU格式的当前版本。
o A set of fundamental applications described in RFC 3413 [13] and the view-based access control mechanism described in RFC 3415 [14].
o RFC 3413[13]中描述的一组基本应用程序和RFC 3415[14]中描述的基于视图的访问控制机制。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
托管对象通过虚拟信息存储（称为管理信息库或MIB）进行访问。MIB中的对象是使用SMI中定义的机制定义的。
SNMPv3 proxy forwarding (RFC 3413 [13]) provides a standardized mechanism to configure an intermediate node to forward SNMP messages. A command generating entity sends requests to a proxy forwarding entity that forwards the request to a third entity.
SNMPv3代理转发（RFC 3413[13]）提供了一种标准化机制，用于配置中间节点以转发SNMP消息。命令生成实体向代理转发实体发送请求，代理转发实体将请求转发给第三实体。
One SNMP entity may serve both functions as the SNMP agent to monitor and configure the node on which it is resident, and as an intermediate node in a proxy relationship to permit monitoring and configuration of additional entities.
一个SNMP实体既可以用作SNMP代理以监视和配置其驻留的节点，也可以用作代理关系中的中间节点以允许监视和配置其他实体。
Each entity is identified by a unique engineID value, specifically to support proxy between addressing domains and/or trust domains. An SNMPv3 message contains two engineIDs- one to identify the database to be used for message security, and one to identify the source (or target) of the contained data. Message security is applied between the originator and the proxy, and then between the proxy and the
每个实体都由一个唯一的engineID值标识，专门用于支持寻址域和/或信任域之间的代理。SNMPv3消息包含两个EngineID—一个用于标识用于消息安全的数据库，另一个用于标识包含数据的源（或目标）。消息安全性在发起人和代理之间应用，然后在代理和代理之间应用
end-target. The PDU contains the engineID of the node whose data is contained in the message, which passes end-to-end, unchanged by the proxy.
最终目标。PDU包含节点的engineID，该节点的数据包含在消息中，该消息端到端传递，代理未更改。
SNMPv3 proxy was designed to provide a standard SNMP approach to inserting an intermediate node in the middle of communications for a variety of scenarios. SNMPv3 proxy can support crossing addressing domains, such as IPv4 and IPv6, crossing SNMP version domains, such as SNMPv3 and SNMPv1, crossing security mechanism domains, such as DES and AES, and for providing a single point of management contact for a subset of the network, such as managing a private network through a NAT device or a VPN endpoint.
SNMPv3代理被设计为提供一种标准SNMP方法，用于在各种情况下在通信的中间插入中间节点。SNMPv3代理可以支持跨寻址域（如IPv4和IPv6）、跨SNMP版本域（如SNMPv3和SNMPv1）、跨安全机制域（如DES和AES），以及为网络子集提供单点管理联系，例如，通过NAT设备或VPN端点管理专用网络。
Proxies are generally preferred to Application Level Gateways for SNMP. ALGs typically modify the headers and content of messages. SNMP is a protocol designed for troubleshooting network (mis-) configurations. Because an operator needs to understand the actual configuration, the translation of addresses within SNMP data causes confusion, hiding the actual configuration of a managed device from the operator. ALGs also introduce security vulnerabilities, and other complexities related to modifying SNMP data.
对于SNMP，代理通常优先于应用程序级网关。ALG通常修改消息的标题和内容。SNMP是一种为网络（mis）配置故障排除而设计的协议。由于操作员需要了解实际配置，SNMP数据中地址的转换会导致混淆，从而对操作员隐藏受管设备的实际配置。ALG还引入了安全漏洞，以及与修改SNMP数据相关的其他复杂性。
SNMP Proxies can modify message headers without modifying the contained data. This avoids the issues associated with translating the payload data, while permitting application level translation of addresses.
SNMP代理可以修改消息头，而无需修改包含的数据。这避免了与转换有效负载数据相关的问题，同时允许应用程序级别的地址转换。
The issues of ALGs versus proxies for SNMP Payload Address Translation are discussed at length in RFC 2962 [27].
RFC 2962[27]详细讨论了ALGs与SNMP有效负载地址转换代理的问题。
Appendix B - RSIP with Tunneling
附录B-带隧道的RSIP
NAT requires ALGs (Application Layer Gateways) in middleboxes without MIDCOM, and application modifications or agents for middleboxes with MIDCOM.
NAT要求在没有MIDCOM的中间盒中使用ALG（应用层网关），并要求在有MIDCOM的中间盒中使用应用程序修改或代理。
Support for NAT without tunneling could easily be added to the RSIP control protocol. NAT would be defined as a new, null tunnel type. Support for the NAT null tunnels could be implemented in hosts, or in applications or application agents.
无隧道的NAT支持可以很容易地添加到RSIP控制协议中。NAT将被定义为一种新的空隧道类型。对NAT空隧道的支持可以在主机、应用程序或应用程序代理中实现。
If support for NAT null tunnels were implemented in hosts, no modifications to applications would be required, and no application agents or ALGs would be required. This has obvious advantages. In addition to the NAT null tunnel, the host would have to implement an RSIP / MIDCOM client (or a STUN client) and the middlebox would have
如果在主机中实现了对NAT null隧道的支持，则不需要对应用程序进行任何修改，也不需要应用程序代理或ALG。这有明显的优势。除了NAT null隧道之外，主机还必须实现一个RSIP/MIDCOM客户端（或STUN客户端），并且中间盒必须
to implement an RSIP / MIDCOM server, or a STUN server would have to be available _beyond_ the middlebox. Note that the STUN client / server approach may not work with all types of middleboxes.
要实现RSIP/MIDCOM服务器或STUN服务器，必须在中间盒之外提供。请注意，STUN客户机/服务器方法可能不适用于所有类型的中间盒。
If support for NAT null tunnels were NOT implemented in hosts, then applications would have to be modified, or application agents or ALGs would have to be implemented. This has the advantage over tunnels (whether null or not) of not requiring modification to hosts, but would require the modification of host applications or the implementation of application agents, both of which would include an RSIP / MIDCOM client, and the implementation of an RSIP/MIDCOM server in the middlebox. Again, in some situations, STUN could be used instead of RSIP / MIDCOM.
如果主机中未实现对NAT null隧道的支持，则必须修改应用程序，或者必须实现应用程序代理或ALG。与隧道（无论是否为空）相比，它的优势在于不需要修改主机，但需要修改主机应用程序或实现应用程序代理，这两者都将包括RSIP/MIDCOM客户端和在中间盒中实现RSIP/MIDCOM服务器。同样，在某些情况下，可以使用STUN代替RSIP/MIDCOM。
Tunneled or not, an RSIP / MIDCOM server is needed in the middlebox. Tunneled, the host needs to be modified, but not the application. Untunneled, an agent must be added or the application must be modified, but there would be no host modifications. The advantages/disadvantages of tunneling would need to be evaluated in considering RSIP.
无论是否使用隧道，中间盒中都需要一台RSIP/MIDCOM服务器。隧道中，需要修改主机，但不需要修改应用程序。如果未运行，则必须添加代理或修改应用程序，但不会修改主机。在考虑RSIP时，需要评估隧道的优点/缺点。
Appendix C - Megaco Modeling Approach
附录C-Megaco建模方法
To model the Middlebox functions such as firewall, NAT etc., a new Middlebox Termination type needs to be defined within Megaco. If policy-rule overlap or modification by multiple Agents is NOT required, then a policy rule is equivalent to a Termination (see Figure 1). The various components of a Policy rule such as filter, action, life-time, creator etc. are described as various properties of a Termination. Use of the Virtual Media Gateway (VMG) concept allows for conflict-free interaction of multiple MA's with the same MB.
要对防火墙、NAT等中间盒功能进行建模，需要在Megaco中定义新的中间盒终止类型。如果不需要多个代理重叠或修改策略规则，则策略规则相当于终止（参见图1）。策略规则的各种组件（如筛选器、操作、生存期、创建者等）被描述为终止的各种属性。虚拟媒体网关（VMG）概念的使用允许多个MA与同一MB进行无冲突交互。
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | |
+-------------|---------|----------|-----------+
| +---------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
----------| |Tx|-------+ +---|Ty|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| ....| | | +-------------+ |
| +---------+ | |
| +---------------------------------
| Middlebox | IF4
+----------------------------------------------+
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | |
+-------------|---------|----------|-----------+
| +---------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
----------| |Tx|-------+ +---|Ty|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| ....| | | +-------------+ |
| +---------+ | |
| +---------------------------------
| Middlebox | IF4
+----------------------------------------------+
Tx: Termination x = Policy rule x
Ty: Termination y = Policy rule y
Tz: Termination z = Policy rule z
MA: MIDCOM Agent
IF: Interface
Tx: Termination x = Policy rule x
Ty: Termination y = Policy rule y
Tz: Termination z = Policy rule z
MA: MIDCOM Agent
IF: Interface
Figure 1.
图1。
If it is required to allow multiple agents manipulate the same Middlebox resource (e.g., a Policy rule or a filter), the latter needs to be kept separate from the Termination (the Policy rule is manipulated by the MA by manipulating the properties of the associated Termination). For example, if overlapping policy rule manipulation is required, then a Termination shall be associated with a single policy rule, but a policy rule may be associated with more than one Termination. Thus, a Termination can share a policy rule with another Termination, or have a policy rule partially overlapping with that of another Termination. This model allows two MAs, controlling two distinct Terminations (see Figure 2), manipulate the same or overlapping policy rules. In Figure 2, policy rules 1 and 2 are overlapping and they are shared by MA-1 and MA-2.
如果需要允许多个代理操作相同的中间盒资源（例如，策略规则或筛选器），则后者需要与终止分开（策略规则由MA通过操作关联终止的属性来操作）。例如，如果需要重叠策略规则操作，则终止应与单个策略规则关联，但策略规则可能与多个终止关联。因此，一个终止可以与另一个终止共享一个策略规则，或者使一个策略规则与另一个终止部分重叠。该模型允许两个MAs控制两个不同的终止（见图2），操作相同或重叠的策略规则。在图2中，策略规则1和2是重叠的，它们由MA-1和MA-2共享。
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | | MB
+-------------|---------|----------|-----------+
| +-----------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
------------------|Ty|----+ +---|Tx|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| .... | | | | +--/------\---+ |
| +-------|---+ | / \ |
| | +----/----------\------------------
| +------+----+------+ +------+ |IF4
| |Policy1 Policy2 | |Policy| |
| | | | | | 3 | |
| +----+------+------+ +------+ |
+----------------------------------------------+
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | | MB
+-------------|---------|----------|-----------+
| +-----------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
------------------|Ty|----+ +---|Tx|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| .... | | | | +--/------\---+ |
| +-------|---+ | / \ |
| | +----/----------\------------------
| +------+----+------+ +------+ |IF4
| |Policy1 Policy2 | |Policy| |
| | | | | | 3 | |
| +----+------+------+ +------+ |
+----------------------------------------------+
Tx: Termination x Ty: Termination y Tz: Termination z MA: MIDCOM Agent IF: Interface MB: Middlebox
Tx：终端x Ty：终端y Tz：终端z MA:MIDCOM代理如果：接口MB:Middlebox
Figure 2.
图2。
This requires that the Agent and the Middlebox adhere to the following principles:
这要求代理商和中间商遵守以下原则：
(1) Only one Termination has read/write access to a filter at any time.
(1) 在任何时候，只有一个终端具有对筛选器的读/写访问权限。
(2) When the policy rule is being modified by a new agent (i.e., not the one that created the policy) the Middlebox makes a policy decision and decides whether to accept the requested modification or not. In the case the modification is accepted the initial MIDCOM agent may be notified.
(2) 当新代理（即，不是创建策略的代理）修改策略规则时，中间盒会做出策略决策，并决定是否接受请求的修改。在接受修改的情况下，可能会通知初始的MIDCOM代理。
Appendix D - Diameter IPFilter Rule
附录D-直径过滤规则
The IPFilterRule format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. Packets may be filtered based on the following information that is associated with it:
IPFilterRule格式派生自八进制字符串AVP基本格式。它使用UTF-8编码，并具有与UTF8String相同的要求。可以基于与分组相关联的以下信息来过滤分组：
Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options ICMP types
方向（输入或输出）源和目标IP地址（可能被屏蔽）协议源和目标端口（列表或范围）TCP标志IP片段标志IP选项ICMP类型
Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny.
相应方向的规则按顺序求值，第一个匹配的规则终止求值。每个数据包评估一次。如果没有匹配的规则，则如果最后一个评估的规则是许可证，则丢弃数据包；如果最后一个规则是拒绝，则传递数据包。
IPFilterRule filters MUST follow the format:
IPFilterRule筛选器必须遵循以下格式：
action dir proto from src to dst [options]
从src到dst的操作目录协议[选项]
action permit - Allow packets that match the rule. deny - Drop packets that match the rule.
操作允许-允许符合规则的数据包。拒绝-丢弃与规则匹配的数据包。
dir "in" is from the terminal, "out" is to the terminal.
dir“in”来自终端，“out”指向终端。
proto An IP protocol specified by number. The "ip" keyword means any protocol will match.
proto由数字指定的IP协议。“ip”关键字表示任何协议都将匹配。
src and dst <address/mask> [ports]
src and dst <address/mask> [ports]
The <address/mask> may be specified as:
<address/mask>可指定为：
ipno An IPv4 or IPv6 number in dotted-quad or canonical IPv6 form. Only this exact IP number will match the rule.
ipno虚线四元组或规范IPv6形式的IPv4或IPv6号码。只有这个确切的IP号码才符合规则。
ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask.
ipno/位如上所述的IP号，掩码宽度为1.2.3.4/24。在这种情况下，从1.2.3.0到1.2.3.255的所有IP号码都将匹配。位宽度必须对IP版本有效，并且IP编号的位设置不得超出掩码。
For a match to occur, the same IP version must be present in the packet that was used in describing the IP address. To test for a particular IP version, the bits part can be set to zero. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. For IPv4, a typical first rule is often "deny in ip! assigned"
要进行匹配，用于描述IP地址的数据包中必须存在相同的IP版本。要测试特定IP版本，可以将bits部分设置为零。关键字“any”是0.0.0.0/0或IPv6等效值。关键字“assigned”是指分配给终端的地址或地址集。对于IPv4，典型的第一条规则通常是“拒绝ip！分配”
The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. This does not affect the selection of port numbers.
匹配的意义可以通过在地址前面加not修饰符（！）来颠倒，从而使所有其他地址都匹配。这不会影响端口号的选择。
With the TCP, UDP and SCTP protocols, optional ports may be specified as:
对于TCP、UDP和SCTP协议，可选端口可以指定为：
{port|port-port}[,ports[,...]]
{port | port port}[，port[，…]
The '-' notation specifies a range of ports (including boundaries).
“-”符号指定端口范围（包括边界）。
Fragmented packets that have a non-zero offset (i.e., not the first fragment) will never match a rule that has one or more port specifications. See the frag option for details on matching fragmented packets.
具有非零偏移量（即，不是第一个片段）的分段数据包将永远不会与具有一个或多个端口规范的规则匹配。有关匹配碎片数据包的详细信息，请参阅frag选项。
options:
选项：
frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications.
frag匹配，如果数据包是一个片段，而这不是数据报的第一个片段。frag不能与tcpflags或TCP/UDP端口规范一起使用。
ipoptions spec Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are:
如果IP标头包含规范中指定的以逗号分隔的选项列表，则ipoptions规范匹配。支持的IP选项包括：
ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a '!'.
ssrr（严格源路由）、lsrr（松散源路由）、rr（记录包路由）和ts（时间戳）。没有特定选项可以用“！”表示。
tcpoptions spec Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are:
如果TCP标头包含规范中指定的以逗号分隔的选项列表，则tcpoptions规范匹配。支持的TCP选项包括：
mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a '!'.
mss（最大段大小）、窗口（tcp窗口广告）、sack（选择性确认）、ts（rfc1323时间戳）和cc（rfc1644 t/tcp连接计数）。没有特定选项可以用“！”表示。
established TCP packets only. Match packets that have the RST or ACK bits set.
仅已建立TCP数据包。匹配设置了RST或ACK位的数据包。
setup TCP packets only. Match packets that have the SYN bit set but no ACK bit.
仅设置TCP数据包。匹配设置了SYN位但没有ACK位的数据包。
tcpflags spec TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are:
tcpflags仅用于规范TCP数据包。如果TCP标头包含规范中指定的以逗号分隔的标志列表，则匹配。支持的TCP标志为：
fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset. See the frag option for details on matching fragmented packets.
fin、syn、rst、psh、ack和urg。没有特定标志可用“！”表示。包含tcpflags规范的规则永远无法匹配具有非零偏移量的碎片数据包。有关匹配碎片数据包的详细信息，请参阅frag选项。
icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. Both the numeric values and the symbolic values listed below can be used. The supported ICMP types are:
icmptypes仅类型ICMP数据包。如果ICMP类型在列表类型中，则匹配。该列表可以指定为范围的任意组合或以逗号分隔的单个类型。可以使用下面列出的数值和符号值。支持的ICMP类型包括：
echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18).
回显回复（0）、目标不可到达（3）、源猝灭（4）、重定向（5）、回显请求（8）、路由器通告（9）、路由器请求（10）、超过生存时间（11）、IP报头错误（12）、时间戳请求（13）、时间戳回复（14）、信息请求（15）、信息回复（16）、地址掩码请求（17）和地址掩码回复（18）。
There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls.
有一种数据包，接入设备必须始终丢弃，即片段偏移量为1的IP片段。这是一个有效的数据包，但它只有一个用途，即试图绕过防火墙。
An access device that is unable to interpret or apply a deny rule MUST terminate the session. An access device that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. An access device MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure.
无法解释或应用拒绝规则的访问设备必须终止会话。无法解释或应用许可证规则的访问设备可以应用更严格的规则。接入设备可在提供的规则之前应用其自身的拒绝规则，例如，以保护接入设备所有者的基础设施。
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations.
规则语法是FreeBSD中ipfw（8）的一个修改子集，ipfw.c代码可以为实现提供有用的基础。
Contributors
贡献者
The following identifies the key contributors who provided the primary content for this document in the form of individual documents for each protocol:
以下列出了以每个协议的单独文档形式为本文档提供主要内容的主要贡献者：
RSIP:
RSIP：
Jim Renkel
吉姆·伦克尔
SNMP:
SNMP：
Juergen Quittek NEC Europe Ltd. EMail: quittek@ccrle.nec.de
Juergen Quitek NEC欧洲有限公司电子邮件：quittek@ccrle.nec.de
David Harrington Co-chair SNMPv3 WG EMail: dbh@enterasys.com
David Harrington SNMPv3工作组联合主席电子邮件：dbh@enterasys.com
Megaco:
梅加科：
Sanjoy Sen
胜先生
Cedric Aoun Nortel EMail: cedric.aoun@nortel.com
Cedric Aoun Nortel电子邮件：Cedric。aoun@nortel.com
Tom Taylor Nortel EMail: taylor@nortel.com
Tom Taylor Nortel电子邮件：taylor@nortel.com
Diameter:
直径：
Tom Taylor Nortel EMail: taylor@nortel.com
Tom Taylor Nortel电子邮件：taylor@nortel.com
COPS:
警察：
Cedric Aoun Nortel EMail: cedric.aoun@nortel.com
Cedric Aoun Nortel电子邮件：Cedric。aoun@nortel.com
Kwok-Ho Chan Nortel EMail: khchan@nortel.com
陈国豪北电电邮：khchan@nortel.com
Louis-Nicolas Hamer
路易斯·尼古拉斯·哈默
Reinaldo Penno EMail: rpenno@juniper.net
Reinaldo Penno电子邮件：rpenno@juniper.net
Sanjoy Sen
胜先生
Author's Address
作者地址
Mary Barnes Nortel 2201 Lakeside Blvd. Richardson, TX USA
玛丽·巴恩斯北电2201湖滨大道。美国德克萨斯州理查森
Phone: 1-972-684-5432 EMail: mary.barnes@nortel.com
电话：1-972-684-5432电子邮件：玛丽。barnes@nortel.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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.
本文件受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 gement
RFC编辑器功能的资金目前由Internet gement提供