Network Working Group M. Stiemerling
Request for Comments: 5189 J. Quittek
Obsoletes: 3989 NEC
Category: Standards Track T. Taylor
Nortel
March 2008
Network Working Group M. Stiemerling
Request for Comments: 5189 J. Quittek
Obsoletes: 3989 NEC
Category: Standards Track T. Taylor
Nortel
March 2008
Middlebox Communication (MIDCOM) Protocol Semantics
中间盒通信（MIDCOM）协议语义
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This document obsoletes RFC 3989.
本文档指定了MIDCOM代理用于与防火墙和网络地址转换器（NAT）等中间盒进行交互的中间盒通信（MIDCOM）协议的语义。语义讨论不包括具体语法或传输协议的任何规范。然而，一个具体的协议需要实现指定的语义，或者更可能是它的超集。MIDCOM协议语义源自MIDCOM需求、MIDCOM框架和工作组决策。本文件废除了RFC 3989。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Transaction Definition Template ............................7
2. Semantics Specification .........................................8
2.1. General Protocol Design ....................................8
2.1.1. Protocol Transactions ...............................8
2.1.2. Message Types .......................................9
2.1.3. Session, Policy Rule, and Policy Rule Group ........10
2.1.4. Atomicity ..........................................11
2.1.5. Access Control .....................................11
2.1.6. Middlebox Capabilities .............................12
2.1.7. Agent and Middlebox Identifiers ....................12
2.1.8. Conformance ........................................13
2.2. Session Control Transactions ..............................13
2.2.1. Session Establishment (SE) .........................14
2.2.2. Session Termination (ST) ...........................16
2.2.3. Asynchronous Session Termination (AST) .............16
2.2.4. Session Termination by Interruption of Connection ..17
2.2.5. Session State Machine ..............................17
2.3. Policy Rule Transactions ..................................18
2.3.1. Configuration Transactions .........................19
2.3.2. Establishing Policy Rules ..........................19
2.3.3. Maintaining Policy Rules and Policy Rule Groups ....20
2.3.4. Policy Events and Asynchronous Notifications .......21
2.3.5. Address Tuples .....................................21
2.3.6. Address Parameter Constraints ......................23
2.3.7. Interface-Specific Policy Rules ....................25
2.3.8. Policy Reserve Rule (PRR) ..........................25
2.3.9. Policy Enable Rule (PER) ...........................30
2.3.10. Policy Rule Lifetime Change (RLC) .................36
2.3.11. Policy Rule List (PRL) ............................38
2.3.12. Policy Rule Status (PRS) ..........................39
2.3.13. Asynchronous Policy Rule Event (ARE) ..............41
2.3.14. Policy Rule State Machine .........................42
2.4. Policy Rule Group Transactions ............................43
2.4.1. Overview ...........................................43
2.4.2. Group Lifetime Change (GLC) ........................44
2.4.3. Group List (GL) ....................................46
2.4.4. Group Status (GS) ..................................47
3. Conformance Statements .........................................48
3.1. General Implementation Conformance ........................49
3.2. Middlebox Conformance .....................................50
3.3. Agent Conformance .........................................50
4. Transaction Usage Examples .....................................50
4.1. Exploring Policy Rules and Policy Rule Groups .............50
4.2. Enabling a SIP-Signaled Call ..............................54
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Transaction Definition Template ............................7
2. Semantics Specification .........................................8
2.1. General Protocol Design ....................................8
2.1.1. Protocol Transactions ...............................8
2.1.2. Message Types .......................................9
2.1.3. Session, Policy Rule, and Policy Rule Group ........10
2.1.4. Atomicity ..........................................11
2.1.5. Access Control .....................................11
2.1.6. Middlebox Capabilities .............................12
2.1.7. Agent and Middlebox Identifiers ....................12
2.1.8. Conformance ........................................13
2.2. Session Control Transactions ..............................13
2.2.1. Session Establishment (SE) .........................14
2.2.2. Session Termination (ST) ...........................16
2.2.3. Asynchronous Session Termination (AST) .............16
2.2.4. Session Termination by Interruption of Connection ..17
2.2.5. Session State Machine ..............................17
2.3. Policy Rule Transactions ..................................18
2.3.1. Configuration Transactions .........................19
2.3.2. Establishing Policy Rules ..........................19
2.3.3. Maintaining Policy Rules and Policy Rule Groups ....20
2.3.4. Policy Events and Asynchronous Notifications .......21
2.3.5. Address Tuples .....................................21
2.3.6. Address Parameter Constraints ......................23
2.3.7. Interface-Specific Policy Rules ....................25
2.3.8. Policy Reserve Rule (PRR) ..........................25
2.3.9. Policy Enable Rule (PER) ...........................30
2.3.10. Policy Rule Lifetime Change (RLC) .................36
2.3.11. Policy Rule List (PRL) ............................38
2.3.12. Policy Rule Status (PRS) ..........................39
2.3.13. Asynchronous Policy Rule Event (ARE) ..............41
2.3.14. Policy Rule State Machine .........................42
2.4. Policy Rule Group Transactions ............................43
2.4.1. Overview ...........................................43
2.4.2. Group Lifetime Change (GLC) ........................44
2.4.3. Group List (GL) ....................................46
2.4.4. Group Status (GS) ..................................47
3. Conformance Statements .........................................48
3.1. General Implementation Conformance ........................49
3.2. Middlebox Conformance .....................................50
3.3. Agent Conformance .........................................50
4. Transaction Usage Examples .....................................50
4.1. Exploring Policy Rules and Policy Rule Groups .............50
4.2. Enabling a SIP-Signaled Call ..............................54
5. Compliance with MIDCOM Requirements ............................59
5.1. Protocol Machinery Requirements ...........................59
5.1.1. Authorized Association .............................59
5.1.2. Agent Connects to Multiple Middleboxes .............60
5.1.3. Multiple Agents Connect to Same Middlebox ..........60
5.1.4. Deterministic Behavior .............................60
5.1.5. Known and Stable State .............................60
5.1.6. Status Report ......................................61
5.1.7. Unsolicited Messages (Asynchronous Notifications) ..61
5.1.8. Mutual Authentication ..............................61
5.1.9. Session Termination by Any Party ...................61
5.1.10. Request Result ....................................62
5.1.11. Version Interworking ..............................62
5.1.12. Deterministic Handling of Overlapping Rules .......62
5.2. Protocol Semantics Requirements ...........................62
5.2.1. Extensible Syntax and Semantics ....................62
5.2.2. Policy Rules for Different Types of Middleboxes ....63
5.2.3. Ruleset Groups .....................................63
5.2.4. Policy Rule Lifetime Extension .....................63
5.2.5. Robust Failure Modes ...............................63
5.2.6. Failure Reasons ....................................63
5.2.7. Multiple Agents Manipulating Same Policy Rule ......63
5.2.8. Carrying Filtering Rules ...........................64
5.2.9. Parity of Port Numbers .............................64
5.2.10. Consecutive Range of Port Numbers .................64
5.2.11. Contradicting Overlapping Policy Rules ............64
5.3. Security Requirements .....................................64
5.3.1. Authentication, Confidentiality, Integrity .........64
5.3.2. Optional Confidentiality of Control Messages .......64
5.3.3. Operation across Untrusted Domains .................65
5.3.4. Mitigate Replay Attacks ............................65
6. Security Considerations ........................................65
7. IAB Considerations on UNSAF ....................................66
8. Acknowledgements ...............................................66
9. References .....................................................67
9.1. Normative References ......................................67
9.2. Informative References ....................................67
Appendix A. Changes from RFC 3989 .................................69
5. Compliance with MIDCOM Requirements ............................59
5.1. Protocol Machinery Requirements ...........................59
5.1.1. Authorized Association .............................59
5.1.2. Agent Connects to Multiple Middleboxes .............60
5.1.3. Multiple Agents Connect to Same Middlebox ..........60
5.1.4. Deterministic Behavior .............................60
5.1.5. Known and Stable State .............................60
5.1.6. Status Report ......................................61
5.1.7. Unsolicited Messages (Asynchronous Notifications) ..61
5.1.8. Mutual Authentication ..............................61
5.1.9. Session Termination by Any Party ...................61
5.1.10. Request Result ....................................62
5.1.11. Version Interworking ..............................62
5.1.12. Deterministic Handling of Overlapping Rules .......62
5.2. Protocol Semantics Requirements ...........................62
5.2.1. Extensible Syntax and Semantics ....................62
5.2.2. Policy Rules for Different Types of Middleboxes ....63
5.2.3. Ruleset Groups .....................................63
5.2.4. Policy Rule Lifetime Extension .....................63
5.2.5. Robust Failure Modes ...............................63
5.2.6. Failure Reasons ....................................63
5.2.7. Multiple Agents Manipulating Same Policy Rule ......63
5.2.8. Carrying Filtering Rules ...........................64
5.2.9. Parity of Port Numbers .............................64
5.2.10. Consecutive Range of Port Numbers .................64
5.2.11. Contradicting Overlapping Policy Rules ............64
5.3. Security Requirements .....................................64
5.3.1. Authentication, Confidentiality, Integrity .........64
5.3.2. Optional Confidentiality of Control Messages .......64
5.3.3. Operation across Untrusted Domains .................65
5.3.4. Mitigate Replay Attacks ............................65
6. Security Considerations ........................................65
7. IAB Considerations on UNSAF ....................................66
8. Acknowledgements ...............................................66
9. References .....................................................67
9.1. Normative References ......................................67
9.2. Informative References ....................................67
Appendix A. Changes from RFC 3989 .................................69
The MIDCOM working group has defined a framework [MDC-FRM] and a list of requirements [MDC-REQ] for middlebox communication. The next step toward a MIDCOM protocol is the specification of protocol semantics that is constrained, but not completely implied, by the documents mentioned above.
MIDCOM工作组定义了一个框架[MDC-FRM]和一个用于中间箱通信的需求列表[MDC-REQ]。MIDCOM协议的下一步是协议语义规范，该规范受到上述文档的约束，但并非完全隐含。
This memo suggests a semantics for the MIDCOM protocol. It is fully compliant with the requirements listed in [MDC-REQ] and with the working group's consensus on semantic issues. This document obsoletes RFC 3989 [MDC-SEM].
此备忘录为MIDCOM协议提供了一种语义。它完全符合[MDC-REQ]中列出的要求以及工作组在语义问题上的共识。本文件淘汰了RFC 3989[MDC-SEM]。
In conformance with the working group charter, the semantics description is targeted at packet filters and Network Address Translators (NATs), and it supports applications that require dynamic configuration of these middleboxes.
根据工作组章程，语义描述针对包过滤器和网络地址转换器（NAT），它支持需要动态配置这些中间盒的应用程序。
The semantics is defined in terms of transactions. Two basic types of transactions are used: request transactions and asynchronous transactions. Further, we distinguish two concrete types of request transactions: configuration transactions and monitoring transactions.
语义是根据事务定义的。使用两种基本类型的事务：请求事务和异步事务。此外，我们区分了两种具体类型的请求事务：配置事务和监视事务。
For each transaction, the semantics is specified by describing (1) the parameters of the transaction; (2) the processing of request messages at the middlebox; (3) the state transitions at the middlebox caused by the request transactions or indicated by the asynchronous transactions, respectively; and (4) the reply and notification messages sent from the middlebox to the agent in order to inform the agent about the state change.
对于每个事务，通过描述（1）事务的参数来指定语义；（2） 在中间箱处理请求消息；（3） 分别由请求事务引起或由异步事务指示的中间盒状态转换；以及（4）从中间盒发送到代理的回复和通知消息，以便将状态变化通知代理。
The semantics can be implemented by any protocol that supports these two transaction types and that is sufficiently flexible concerning transaction parameters. Different implementations for different protocols might need to extend the semantics described below by adding further transactions and/or adding further parameters to transactions and/or splitting single transactions into a set of transactions. Regardless of such extensions, the semantics below provides a minimum necessary subset of what must be implemented.
语义可以由支持这两种事务类型并且在事务参数方面具有足够灵活性的任何协议实现。不同协议的不同实现可能需要通过添加更多事务和/或向事务添加更多参数和/或将单个事务拆分为一组事务来扩展下面描述的语义。不管这些扩展如何，下面的语义提供了必须实现的内容的最小必要子集。
The remainder of this document is structured as follows. Section 2 describes the protocol semantics. It is structured in four subsections:
本文件其余部分的结构如下。第2节描述了协议语义。其结构分为四个小节：
- General Protocol Design (section 2.1) - Session Control (section 2.2) - Policy Rules (section 2.3) - Policy Rule Groups (section 2.4)
- 通用协议设计（第2.1节）-会话控制（第2.2节）-策略规则（第2.3节）-策略规则组（第2.4节）
Section 3 contains conformance statements for MIDCOM protocol definitions and MIDCOM protocol implementations with respect to the semantics defined in section 2. Section 4 gives two elaborated usage examples. Finally, section 5 explains how the semantics meets the MIDCOM requirements.
第3节包含关于第2节中定义的语义的MIDCOM协议定义和MIDCOM协议实现的一致性声明。第4节给出了两个详细的用法示例。最后，第5节解释了语义如何满足MIDCOM需求。
The terminology in this memo follows the definitions given in the framework [MDC-FRM] and requirements [MDC-REQ] document.
本备忘录中的术语遵循框架[MDC-FRM]和要求[MDC-REQ]文件中给出的定义。
In addition, the following terms are used:
此外，还使用了以下术语：
request transaction A request transaction consists of a request message transfer from the agent to the middlebox, processing of the message at the middlebox, a reply message transfer from the middlebox to the agent, and the optional transfer of notification messages from the middlebox to agents other than the one requesting the transaction. A request transaction might cause a state transition at the middlebox.
请求事务请求事务包括从代理到中间箱的请求消息传输、在中间箱处理消息、从中间箱到代理的回复消息传输，以及从中间箱到请求事务的代理以外的其他代理的可选通知消息传输。请求事务可能会导致中间箱发生状态转换。
configuration transaction A configuration transaction is a request transaction containing a request for state change in the middlebox. If accepted, it causes a state change at the middlebox.
配置事务配置事务是一个请求事务，在中间盒中包含状态更改请求。如果接受，则会导致中间盒的状态更改。
monitoring transaction A monitoring transaction is a request transaction containing a request for state information from the middlebox. It does not cause a state transition at the middlebox.
监控事务监控事务是一个请求事务，包含来自中间盒的状态信息请求。它不会导致中间盒的状态转换。
asynchronous transaction An asynchronous transaction is not triggered by an agent. It may occur without any agent participating in a session with the middlebox. Potentially, an asynchronous transaction includes the transfer of notification messages from the middlebox to agents that participate in an open session. A notification message is sent to each agent that needs to be notified about the asynchronous event. The message indicates the state transition at the middlebox.
异步事务异步事务不是由代理触发的。它可能在没有任何代理参与与中间盒的会话的情况下发生。异步事务可能包括将通知消息从中间箱传输到参与开放会话的代理。一条通知消息被发送到需要通知异步事件的每个代理。该消息表示中间盒的状态转换。
agent-unique An agent-unique value is unique in the context of the agent. This context includes all MIDCOM sessions the agent participates in. An agent-unique value is assigned by the agent.
代理唯一性代理唯一性值在代理的上下文中是唯一的。此上下文包括代理参与的所有MIDCOM会话。代理将分配一个代理唯一值。
middlebox-unique A middlebox-unique value is unique in the context of the middlebox. This context includes all MIDCOM sessions the middlebox participates in. A middlebox-unique value is assigned by the middlebox.
middlebox unique middlebox unique值在middlebox上下文中是唯一的。此上下文包括middlebox参与的所有MIDCOM会话。中间盒的唯一值由中间盒指定。
policy rule In general, a policy rule is "a basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions -- where the conditions are evaluated to determine whether the actions are performed" [RFC3198]. In the MIDCOM context, the condition is a specification of a set of packets to which rules are applied. The set of actions always contains just a single element per rule, either action "reserve" or action "enable".
策略规则一般来说，策略规则是“基于策略的系统的基本构建块。它是一组操作与一组条件的绑定，其中对条件进行评估以确定是否执行操作”[RFC3198]。在MIDCOM上下文中，条件是应用规则的一组数据包的规范。每个规则的操作集始终只包含一个元素，操作“reserve”或操作“enable”。
policy reserve rule A policy rule containing a reserve action. The policy condition of this rule is always true. The action is the reservation of just an IP address or a combination of an IP address and a range of port numbers on neither side, one side, or both sides of the middlebox, depending on the middlebox configuration.
策略保留规则包含保留操作的策略规则。此规则的策略条件始终为true。该操作是仅保留一个IP地址或IP地址与一系列端口号的组合（在中间盒的两侧、一侧或两侧），具体取决于中间盒的配置。
policy enable rule A policy rule containing an enable action. The policy condition consists of a descriptor of one or more unidirectional or bidirectional packet flows, and the policy action enables packets belonging to this flow to traverse the middlebox. The descriptor identifies the protocol, the flow direction, and the source and destination addresses, optionally with a range of port numbers.
策略启用规则包含启用操作的策略规则。策略条件由一个或多个单向或双向数据包流的描述符组成，策略操作使属于此数据包流的数据包能够通过中间件。描述符标识协议、流方向、源地址和目标地址，可选地使用一系列端口号。
NAT binding The term NAT binding as used in this document does not necessarily refer to a NAT bind as defined in [NAT-TERM]. A NAT binding in the MIDCOM semantics refers to an abstraction that enables communication between two endpoints through the NAT-type middlebox. An enable action may result in a NAT bind or a NAT session, depending on the request and its parameters.
NAT绑定本文档中使用的术语NAT绑定不一定指[NAT-term]中定义的NAT绑定。MIDCOM语义中的NAT绑定是指通过NAT类型的中间盒实现两个端点之间通信的抽象。根据请求及其参数，启用操作可能会导致NAT绑定或NAT会话。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In the following sections, the semantics of the MIDCOM protocol is specified per transaction. A transaction specification contains the following entries. Parameter entries, failure reason, and notification message type are only specified if applicable.
在以下各节中，将为每个事务指定MIDCOM协议的语义。事务规范包含以下条目。参数条目、故障原因和通知消息类型仅在适用时指定。
transaction-name A description name for this type of transaction.
事务名称此类型事务的描述名称。
transaction-type The transaction type is either 'configuration', 'monitoring', or 'asynchronous'. See section 1.1 for a description of transaction types.
事务类型事务类型为“配置”、“监视”或“异步”。有关交易类型的说明，请参见第1.1节。
transaction-compliance This entry contains either 'mandatory' or 'optional'. For details, see section 2.1.8.
交易符合性此条目包含“强制”或“可选”。有关详细信息，请参见第2.1.8节。
request-parameters This entry lists all parameters necessary for this request. A description for each parameter is given.
请求参数此条目列出此请求所需的所有参数。给出了每个参数的描述。
reply-parameters (success) This entry lists all parameters sent back from the middlebox to the agent as positive response to the prior request. A description for each parameter is given.
回复参数（成功）此条目列出从中间盒发送回代理的所有参数，作为对先前请求的肯定响应。给出了每个参数的描述。
failure reason All negative replies have two parameters: a request identifier identifying the request on which the reply is sent and a parameter indicating the failure reason. As these parameters are compulsory, they are not listed in the template. But the template
失败原因所有否定答复都有两个参数：一个用于标识发送答复的请求的请求标识符，另一个用于指示失败原因的参数。由于这些参数是必需的，因此不会在模板中列出。但是模板
contains a list of potential failure reasons that may be indicated by the second parameter. The list is not exhaustive. A concrete protocol specification may extend the list.
包含可能由第二个参数指示的潜在故障原因的列表。这份清单并非详尽无遗。具体的协议规范可以扩展该列表。
notification message type This entry describes the notification message type that may be used by this transaction.
通知消息类型此条目描述此事务可能使用的通知消息类型。
semantics This entry describes the actual semantics of the transaction. Particularly, it describes the processing of the request message by the middlebox, and middlebox state transitions caused by or causing the transaction, respectively.
语义此条目描述事务的实际语义。特别地，它分别描述了中间盒对请求消息的处理，以及由事务引起或引起事务的中间盒状态转换。
The semantics specification aims at a balance between proper support of applications that require dynamic configuration of middleboxes and simplicity of specification and implementation of the protocol.
语义规范旨在适当支持需要动态配置中间盒的应用程序与简化规范和协议实现之间取得平衡。
Protocol interactions are structured into transactions. The state of middleboxes is described by state machines. The state machines are defined by states and state transitions. A single transaction may cause or be caused by state transitions in more than one state machine, but per state machine there is no more than one transition per transaction.
协议交互被结构化为事务。中间盒的状态由状态机描述。状态机由状态和状态转换定义。单个事务可能导致或由多个状态机中的状态转换引起，但每个状态机中每个事务的转换不超过一个。
State transitions are initiated either by a request message from the agent to the middlebox or by some other event at the middlebox. In the first case, the middlebox informs the agent by sending a reply message on the actual state transition; in the second, the middlebox sends an unsolicited asynchronous notification message to each agent affected by the transaction (if it participates in an open session with the middlebox).
状态转换由代理向中间箱发送的请求消息或中间箱上的其他事件启动。在第一种情况下，中间盒通过发送关于实际状态转换的回复消息来通知代理；在第二种情况下，中间箱向受事务影响的每个代理发送一条未经请求的异步通知消息（如果它参与了与中间箱的开放会话）。
Request and reply messages contain an agent-unique request identifier that allows the agent to determine to which sent request a received reply corresponds.
请求和回复消息包含一个代理唯一的请求标识符，该标识符允许代理确定接收到的回复对应于哪个发送的请求。
An analysis of the requirements showed that three kinds of transactions are required:
对需求的分析表明，需要三种交易：
- Configuration transactions allowing the agent to request state transitions at the middlebox.
- 配置事务，允许代理在中间箱请求状态转换。
- Asynchronous transactions allowing the reporting of state changes that have not been requested by the agent.
- 异步事务允许报告代理未请求的状态更改。
- Monitoring transactions allowing the agent to request state information from the middlebox.
- 监控允许代理从中间箱请求状态信息的事务。
Configuration transactions and asynchronous transactions provide the basic MIDCOM protocol functionality. They are related to middlebox state transitions, and they concern establishment and termination of MIDCOM sessions and of policy rules.
配置事务和异步事务提供基本的MIDCOM协议功能。它们与中间盒状态转换有关，并且与MIDCOM会话和策略规则的建立和终止有关。
Monitoring transactions are not related to middlebox state transitions. They are used by agents to explore the number, status, and properties of policy rules established at the middlebox.
监控事务与中间盒状态转换无关。代理使用它们来探索在中间箱中建立的策略规则的数量、状态和属性。
As specified in detail in section 3, configuration transactions and asynchronous transactions are mandatory except of the Group Lifetime Change (GLC). They must be implemented by a compliant middlebox. The GLC transaction and some of the monitoring transactions are optional.
如第3节中详细说明的，配置事务和异步事务是强制性的，但组生命周期更改（GLC）除外。它们必须由符合要求的中间盒实现。GLC事务和一些监控事务是可选的。
The MIDCOM protocol supports three kinds of messages: request messages, reply messages, and notification messages. For each kind, different message types exist. In this semantics document, message types are only defined by the list of parameters. The order of the parameters and their encoding are left to a concrete protocol definition. A protocol definition may also add further parameters to a message type or combine several parameters into one, as long as the information contained in the parameters defined in the semantics is still present.
MIDCOM协议支持三种消息：请求消息、回复消息和通知消息。对于每种类型，都存在不同的消息类型。在此语义文档中，消息类型仅由参数列表定义。参数的顺序及其编码留给具体的协议定义。只要语义中定义的参数中包含的信息仍然存在，协议定义还可以向消息类型添加更多参数或将多个参数组合为一个参数。
For request messages and positive reply messages, there exists one message type per request transaction. Each reply transaction defines the parameter list of the request message and of the positive (successful) reply message by using the transaction definition template defined in section 1.2.
对于请求消息和肯定答复消息，每个请求事务存在一种消息类型。每个回复事务使用第1.2节中定义的事务定义模板定义请求消息和肯定（成功）回复消息的参数列表。
In case of a failed request transaction, a negative reply message is sent from the middlebox to the agent. This message is the same for all request transactions; it contains the request identifier identifying the request to which the reply is sent and a parameter indicating the failure reason.
如果请求事务失败，则会从中间盒向代理发送否定回复消息。此消息对于所有请求事务都是相同的；它包含标识应答发送到的请求的请求标识符和指示失败原因的参数。
There are three notification message types: the Session Termination Notification (STN), the Policy Rule Event Notification (REN), and the Group Event Notification (GEN). All of these contain a middlebox-unique notification identifier.
有三种通知消息类型：会话终止通知（STN）、策略规则事件通知（REN）和组事件通知（GEN）。所有这些都包含一个中间盒唯一通知标识符。
STN The Session Termination Notification message additionally contains a single parameter indicating the reason for session termination by the middlebox.
STN会话终止通知消息还包含一个参数，指示通过中间盒终止会话的原因。
REN The Policy Rule Event Notification message contains the notification identifier, a policy rule identifier, and the remaining policy lifetime.
REN策略规则事件通知消息包含通知标识符、策略规则标识符和剩余策略生存期。
GEN The Group Event Notification message contains the notification identifier, a policy rule group identifier, and the remaining policy rule group lifetime.
GEN组事件通知消息包含通知标识符、策略规则组标识符和剩余策略规则组生存期。
All transactions can be further grouped into transactions concerning sessions, transactions concerning policy rules, and transactions concerning policy rule groups. Policy rule groups can be used to indicate relationships between policy rules and to simplify transactions on a set of policy rules by using a single transaction per group instead of one per policy rule.
所有事务可以进一步分组为与会话有关的事务、与策略规则有关的事务和与策略规则组有关的事务。策略规则组可用于指示策略规则之间的关系，并简化一组策略规则上的事务，方法是每个组使用一个事务，而不是每个策略规则使用一个事务。
Sessions and policy rules at the middlebox are stateful. Their states are independent of each other, and their state machines (one per session and one per policy rule) can be separated. Policy rule groups are also stateful, but the middlebox does not need to maintain state for policy rule groups, because the semantics was chosen so that the policy rule group state is implicitly defined by the state of all policy rules belonging to the group (see section 2.4).
中间盒中的会话和策略规则是有状态的。它们的状态彼此独立，它们的状态机（每个会话一个，每个策略规则一个）可以分开。策略规则组也是有状态的，但中间盒不需要维护策略规则组的状态，因为选择了语义，因此策略规则组状态由属于该组的所有策略规则的状态隐式定义（请参见第2.4节）。
The separation of session state and policy rule state simplifies the specification of the semantics as well as a protocol implementation. Therefore, the semantics specification is structured accordingly and we use two separated state machines to illustrate the semantics. Please note that state machines of concrete protocol designs and implementations will probably be more complex than the state machines presented here. However, the protocol state machines are expected to be a superset of the semantics state machines in this document.
会话状态和策略规则状态的分离简化了语义规范和协议实现。因此，语义规范的结构是相应的，我们使用两个分离的状态机来说明语义。请注意，具体协议设计和实现的状态机可能比这里介绍的状态机更复杂。然而，协议状态机应该是本文中语义状态机的超集。
All request transactions are atomic with respect to each other. This means that processing of a request at the middlebox is never interrupted by another request arriving or already queued. This particularly applies when the middlebox concurrently receives requests originating in different sessions. However, asynchronous transactions may interrupt and/or terminate processing of a request at any time.
所有请求事务相互之间都是原子的。这意味着，在中间箱处理请求时，不会被另一个到达或已排队的请求中断。当中间盒同时接收来自不同会话的请求时，这尤其适用。但是，异步事务可以随时中断和/或终止对请求的处理。
All request transactions are atomic from the point of view of the agent. The processing of a request does not start before the complete request arrives at the middlebox. No intermediate state is stable at the middlebox, and no intermediate state is reported to any agent.
从代理的角度来看，所有请求事务都是原子的。在完整请求到达中间箱之前，不会开始处理请求。中间箱中没有稳定的中间状态，也没有向任何代理报告中间状态。
The number of transactions specified in this document is rather small. Again, for simplicity, we reduced it to a minimal set that still meets the requirements. A real implementation of the protocol might require splitting some of the transactions specified below into two or more transactions of the respective protocol. Reasons for this might include constraints of the particular protocol or the desire for more flexibility. In general, this should not be a problem. However, it should be considered that this might change atomicity of the affected transactions.
本文件中规定的交易数量相当少。同样，为了简单起见，我们将其简化为仍然满足要求的最小集合。协议的实际实现可能需要将下面指定的一些事务拆分为相应协议的两个或多个事务。原因可能包括特定协议的限制或对更大灵活性的渴望。一般来说，这不应该是一个问题。然而，应该考虑到这可能会改变受影响事务的原子性。
Ownership determines access to policy rules and policy rule groups. When a policy rule is created, a middlebox-unique identifier is generated to identify it in further transactions. Beyond the identifier, each policy rule has an owner. The owner is the authenticated agent that established the policy rule. The middlebox uses the owner attribute of a policy rule to control access to it; each time an authenticated agent requests to modify an existing policy rule, the middlebox determines the owner of the policy rule and checks whether the requesting agent is authorized to perform transactions on the owning agent's policy rules.
所有权决定对策略规则和策略规则组的访问。创建策略规则时，将生成一个中间盒唯一标识符，以在后续事务中对其进行标识。除了标识符之外，每个策略规则都有一个所有者。所有者是建立策略规则的经过身份验证的代理。中间盒使用策略规则的所有者属性来控制对它的访问；每次经过身份验证的代理请求修改现有的策略规则时，中间盒都会确定策略规则的所有者，并检查请求代理是否有权对所属代理的策略规则执行事务。
All policy rules belonging to the same policy rule group must have the same owner. Therefore, authenticated agents have access either to all members of a policy rule group or to none of them.
属于同一策略规则组的所有策略规则必须具有相同的所有者。因此，经过身份验证的代理可以访问策略规则组的所有成员，也可以不访问任何成员。
The middlebox may be configured to allow specific authenticated agents to access and modify policy rules with certain specific owners. Certainly, a reasonable default configuration would let each agent access its own policy rules. Also, it might be good to configure an agent identity to act as administrator, allowing
中间盒可以配置为允许特定的认证代理访问和修改具有特定所有者的策略规则。当然，合理的默认配置将允许每个代理访问自己的策略规则。此外，最好配置代理身份作为管理员，允许
modification of all policy rules owned by any agent. However, the configuration of authorization at the middlebox is out of scope of the MIDCOM semantics and protocol.
修改任何代理拥有的所有保单规则。然而，在中间盒上的授权配置超出了MIDCOM语义和协议的范围。
For several reasons, it is useful that at session establishment the agent learns about particular capabilities of the middlebox. Therefore, the session establishment procedure described in section 2.2.1 includes a transfer of capability information from the middlebox to the agent. The list of covered middlebox capabilities includes the following:
出于几个原因，在会话建立时，代理了解中间盒的特定功能非常有用。因此，第2.2.1节中描述的会话建立过程包括从中间箱向代理传输能力信息。涵盖的中间盒功能列表包括以下内容：
- Support of firewall function - List of supported NAT functions, perhaps including - address translation - port translation - protocol translation - twice-NAT - Internal IP address wildcard support - External IP address wildcard support - Port wildcard support - Supported IP version(s) for internal network: IPv4, IPv6, or both - Supported IP version(s) for external network: IPv4, IPv6, or both - List of supported optional MIDCOM protocol transactions - Support for interface-specific policy rules - Policy rule persistence: persistent or non-persistent (a rule is persistent when the middlebox can save the rule to a non-volatile memory, e.g., a hard disk or flash memory) - Maximum remaining lifetime of a policy rule or policy rule group - Idle-timeout of policy rules in the middlebox (reserved and enabled policy rules not used by any data traffic for the time of this idle-timeout are deleted automatically by the middlebox; for the deletion of policy rules by middleboxes, see section 2.3.13, "Asynchronous Policy Rule Event (ARE)"). - Maximum number of simultaneous MIDCOM sessions
- 支持防火墙功能-支持的NAT功能列表，可能包括-地址转换-端口转换-协议转换-两次NAT-内部IP地址通配符支持-外部IP地址通配符支持-端口通配符支持-内部网络支持的IP版本：IPv4、IPv6、，或两者都支持-外部网络支持的IP版本：IPv4、IPv6或两者都支持-支持的可选MIDCOM协议事务列表-支持接口特定的策略规则-策略规则持久性：持久性或非持久性（当中间盒可以将规则保存到非易失性内存（例如硬盘或闪存）时，规则是持久的）-策略规则或策略规则组的最大剩余生存期-中间盒中策略规则的空闲超时（在此空闲超时时间内未被任何数据通信使用的保留和启用的策略规则将由middlebox自动删除；有关通过middlebox删除策略规则的信息，请参阅第2.3.13节“异步策略规则事件（are）”——同时进行的MIDCOM会话的最大数量
The list of middlebox capabilities may be extended by a concrete protocol specification with further information useful for the agent.
中间盒功能列表可以通过具体的协议规范进行扩展，其中包含对代理有用的进一步信息。
To allow both agents and middleboxes to maintain multiple sessions, each request message contains a parameter identifying the requesting agent, and each reply message and each notification message contains a parameter identifying the middlebox. These parameters are not
为了允许代理和中间箱维护多个会话，每个请求消息都包含一个标识请求代理的参数，每个回复消息和每个通知消息都包含一个标识中间箱的参数。这些参数不是
explicitly listed in the description of the individual transactions, because they are common to all of them. They are not further referenced in the individual semantics descriptions. Although they are not necessarily passed explicitly as parameters of the MIDCOM protocol, they might be provided by the underlying (secure) transport protocol being used. Agent identifiers at the middlebox are middlebox-unique, and middlebox identifiers at the agent are agent-unique, respectively.
在单个交易的描述中明确列出，因为它们对所有交易都是通用的。它们在单独的语义描述中没有进一步引用。尽管它们不一定作为MIDCOM协议的参数显式传递，但它们可能由所使用的底层（安全）传输协议提供。中间箱处的代理标识符是唯一的，代理处的中间箱标识符分别是唯一的。
The MIDCOM requirements in [MDC-REQ] demand capabilities of the MIDCOM protocol that are met by the set of transactions specified below. However, it is not required that an actual implementation of a middlebox supports all these transactions. The set of announced supported transactions may be different for different authenticated agents. The middlebox informs the authenticated agent with the capability exchange at session establishment about the transactions that the agent is authorized to perform. Some transactions need to be offered to every authenticated agent.
[MDC-REQ]中的MIDCOM要求需要MIDCOM协议的功能，这些功能由下面指定的一组事务满足。但是，并不要求中间盒的实际实现支持所有这些事务。对于不同的经过身份验证的代理，所宣布的受支持事务集可能不同。在会话建立时，中间盒将代理被授权执行的事务通知具有能力交换的经过身份验证的代理。有些事务需要提供给每个经过身份验证的代理。
Each transaction definition below has a conformance entry that contains either 'mandatory' or 'optional'. A mandatory transaction needs to be implemented by every middlebox offering MIDCOM service and must be must be offered to each of the authenticated agents. An optional transaction does not necessarily need to be implemented by a middlebox; it may offer these optional transactions only to certain authenticated agents. The middlebox may offer one, several, all, or no optional transactions to the agents. Whether an agent is allowed to use an optional request transaction is determined by the middlebox's authorization procedure, which is not further specified by this document.
下面的每个事务定义都有一个包含“强制”或“可选”的一致性条目。每个提供MIDCOM服务的中间包都需要实现强制事务，并且必须提供给每个经过身份验证的代理。可选交易不一定需要通过中间箱实现；它可能只向某些经过身份验证的代理提供这些可选事务。中间包可以向代理提供一项、多项、全部或不提供可选交易。是否允许代理使用可选请求事务由中间箱的授权程序决定，本文档未进一步规定。
Before any transaction on policy rules or policy rule groups is possible, a valid MIDCOM session must be established. A MIDCOM session is an authenticated and authorized association between agent and middlebox. Sessions are initiated by agents and can be terminated by either the agent or the middlebox. Both agent and middlebox may participate in several sessions (with different entities) at the same time. To distinguish different sessions, each party uses local session identifiers.
在策略规则或策略规则组上进行任何事务之前，必须建立有效的MIDCOM会话。MIDCOM会话是代理和中间盒之间经过身份验证和授权的关联。会话由代理启动，可以由代理或中间盒终止。代理和middlebox都可以同时参与多个会话（使用不同的实体）。为了区分不同的会话，各方使用本地会话标识符。
All transactions are transmitted within this MIDCOM session.
所有事务都在此MIDCOM会话中传输。
Session control is supported by three transactions:
会话控制由三个事务支持：
- Session Establishment (SE) - Session Termination (ST) - Asynchronous Session Termination (AST)
- 会话建立（SE）-会话终止（ST）-异步会话终止（AST）
The first two are configuration transactions initiated by the agent, and the last one is an asynchronous transaction initiated by the middlebox.
前两个是由代理启动的配置事务，最后一个是由中间箱启动的异步事务。
transaction-name: session establishment
事务名称：会话建立
transaction-type: configuration
事务类型：配置
transaction-compliance: mandatory
交易合规性：强制性
request-parameters:
请求参数：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 请求标识符：用于在代理上匹配相应请求和答复的代理唯一标识符。
- version: The version of the MIDCOM protocol.
- 版本：MIDCOM协议的版本。
- middlebox challenge (mc): An authentication challenge token for authentication of the middlebox. As seen below, this is present only in the first iteration of the request.
- middlebox challenge（mc）：用于对middlebox进行身份验证的身份验证质询令牌。如下所示，这仅在请求的第一次迭代中出现。
- agent authentication (aa): An authentication token authenticating the agent to the middlebox. As seen below, this is updated in the second iteration of the request with material responding to the middlebox challenge.
- 代理身份验证（aa）：将代理身份验证到中间箱的身份验证令牌。如下图所示，这在请求的第二次迭代中得到更新，其中包含响应中间盒挑战的材料。
reply-parameters (success):
答复参数（成功）：
- request identifier: An identifier matching the identifier request.
- 请求标识符：与标识符请求匹配的标识符。
- middlebox authentication (ma): An authentication token authenticating the middlebox to the agent.
- 中间箱身份验证（ma）：向代理验证中间箱的身份验证令牌。
- agent challenge (ac): An authentication challenge token for the agent authentication.
- 代理质询（ac）：代理身份验证的身份验证质询令牌。
- middlebox capabilities: A list describing the middlebox's capabilities. See section 2.1.6 for the list of middlebox capabilities.
- 中间箱功能：描述中间箱功能的列表。有关中间盒功能列表，请参见第2.1.6节。
failure reason:
故障原因：
- authentication failed - no authorization - protocol version of agent and middlebox do not match - lack of resources
- 身份验证失败-未授权-代理和中间盒的协议版本不匹配-缺少资源
semantics:
语义：
This session establishment transaction is used to establish a MIDCOM session. For mutual authentication of both parties, two subsequent session establishment transactions are required as shown in Figure 1.
此会话建立事务用于建立MIDCOM会话。对于双方的相互认证，需要两个后续会话建立事务，如图1所示。
agent middlebox
| session establishment request |
| (with middlebox challenge mc) | CLOSED
|-------------------------------------------->|
| |
| successful reply (with middlebox |
| authentication ma and agent challenge ac) |
|<--------------------------------------------|
| | NOAUTH
| session establishment request |
| (with agent authentication aa) |
|-------------------------------------------->|
| |
| successful reply |
|<--------------------------------------------|
| | OPEN
| |
agent middlebox
| session establishment request |
| (with middlebox challenge mc) | CLOSED
|-------------------------------------------->|
| |
| successful reply (with middlebox |
| authentication ma and agent challenge ac) |
|<--------------------------------------------|
| | NOAUTH
| session establishment request |
| (with agent authentication aa) |
|-------------------------------------------->|
| |
| successful reply |
|<--------------------------------------------|
| | OPEN
| |
Figure 1: Mutual Authentication of Agent and Middlebox
图1：代理和中间盒的相互认证
Session establishment may be simplified by using only a single transaction. In this case, server challenge and agent challenge are omitted by the sender or ignored by the receiver, and authentication must be provided by other means, for example, by Transport Layer Security (TLS) [RFC4346] or IPsec [RFC4302][RFC4303].
会话建立可以通过只使用一个事务来简化。在这种情况下，发送方省略或接收方忽略服务器质询和代理质询，并且必须通过其他方式提供身份验证，例如，通过传输层安全（TLS）[RFC4346]或IPsec[RFC4302][RFC4303]。
The middlebox checks with its policy decision point whether the requesting agent is authorized to open a MIDCOM session. If it is not, the middlebox generates a negative reply with 'no authorization' as the failure reason. If authentication and authorization are successful, the session is established, and the agent may start with requesting transactions on policy rules and policy rule groups.
中间盒使用其策略决策点检查请求代理是否有权打开MIDCOM会话。如果不是，则中间盒将生成一个否定回复，并将“未授权”作为失败原因。如果身份验证和授权成功，将建立会话，并且代理可以开始请求策略规则和策略规则组上的事务。
Part of the successful reply is an indication of the middlebox's capabilities.
成功回复的一部分表明了中间盒的功能。
transaction-name: session termination
事务名称：会话终止
transaction-type: configuration
事务类型：配置
transaction-compliance: mandatory
交易合规性：强制性
request-parameters:
请求参数：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 请求标识符：用于在代理上匹配相应请求和答复的代理唯一标识符。
reply-parameters (success only):
回复参数（仅限成功）：
- request identifier: An identifier matching the identifier of the request.
- 请求标识符：与请求标识符匹配的标识符。
semantics:
语义：
This transaction is used to close the MIDCOM session on behalf of the agent. After session termination, the middlebox keeps all established policy rules until their lifetime expires or until an event occurs that causes the middlebox to terminate them.
此事务用于代表代理关闭MIDCOM会话。会话终止后，中间盒将保留所有已建立的策略规则，直到其生存期到期或发生导致中间盒终止它们的事件为止。
The middlebox always generates a successful reply. After sending the reply, the middlebox will not send any further messages to the agent within the current session. It also will not process any further request within this session that it received while processing the session termination request or that it receives later.
中间盒总是生成一个成功的回复。发送回复后，在当前会话中，中间盒将不会向代理发送任何进一步的消息。它也不会在此会话中处理在处理会话终止请求时收到的或稍后收到的任何进一步请求。
transaction-name: asynchronous session termination
事务名称：异步会话终止
transaction-type: asynchronous
事务类型：异步
transaction-compliance: mandatory
交易合规性：强制性
notification message type: Session Termination Notification (STN)
通知消息类型：会话终止通知（STN）
reply-parameters (success only):
回复参数（仅限成功）：
- termination reason: The reason why the session is terminated.
- 终止原因：会话终止的原因。
semantics:
语义：
The middlebox may decide to terminate a MIDCOM session at any time. Before terminating the actual session, the middlebox generates an STN message and sends it to the agent. After sending the notification, the middlebox will not process any further request by the agent, even if it is already queued at the middlebox.
中间盒可随时决定终止MIDCOM会话。在终止实际会话之前，中间盒将生成STN消息并将其发送给代理。发送通知后，中间箱将不会处理代理的任何进一步请求，即使它已经在中间箱排队。
After session termination, the middlebox keeps all established policy rules until their lifetime expires or until an event occurs for which the middlebox terminates them.
会话终止后，中间盒将保留所有已建立的策略规则，直到其生存期到期或发生中间盒终止它们的事件为止。
Unlike in other asynchronous transactions, no more than one notification is sent, because there is only one agent affected by the transaction.
与其他异步事务不同，只发送一个通知，因为只有一个代理受该事务影响。
If a MIDCOM session is based on an underlying network connection, the session can also be terminated by an interruption of this connection. If the middlebox detects this, it immediately terminates the session. The effect on established policy rules is the same as for the Asynchronous Session Termination.
如果MIDCOM会话基于基础网络连接，则会话也可以通过中断此连接而终止。如果中间盒检测到这一点，它会立即终止会话。对已建立的策略规则的影响与异步会话终止的影响相同。
A state machine illustrating the semantics of the session transactions is shown in Figure 2. The transaction abbreviations used can be found in the headings of the particular transaction section.
图2显示了说明会话事务语义的状态机。使用的交易缩写可在特定交易部分的标题中找到。
All sessions start in state CLOSED. If mutual authentication is already provided by other means, a successful SE transaction can cause a state transition to state OPEN. Otherwise, it causes a transition to state NOAUTH. From this state, a failed second SE transaction returns to state CLOSED. A successful SE transaction causes a transition to state OPEN. At any time, an AST transaction or a connection failure may occur, causing a transition to state CLOSED. A successful ST transaction from either NOAUTH or OPEN also causes a return to CLOSED. The parameters of the transactions are explained in Figure 2; the value mc=0 represents an empty middlebox challenge.
所有会话都以关闭状态开始。如果已经通过其他方式提供了相互身份验证，成功的SE事务可能会导致状态转换为打开状态。否则，将导致转换到状态NOAUTH。从该状态开始，失败的第二个SE事务返回到关闭状态。成功的SE事务会导致转换为打开状态。在任何时候，都可能发生AST事务或连接故障，导致转换为关闭状态。来自NOAUTH或OPEN的成功ST事务也会导致返回到CLOSED。交易的参数如图2所示；值mc=0表示一个空的中间盒质询。
mc = middlebox challenge
SE/failure ma = middlebox authentication
+-------+ ac = agent challenge
| v aa = agent authentication
+----------+
| CLOSED |----------------+
+----------+ | SE(mc!=0)/
| ^ ^ | success(ma,ac)
SE(mc=0, | | | AST |
aa=OK)/ | | | SE/failure v
success | | | ST/success +----------+
| | +------------| NOAUTH |
| | +----------+
| | AST | SE(mc=0,
v | ST/success | aa=OK)/
+----------+ | success
| OPEN |<---------------+
+----------+
mc = middlebox challenge
SE/failure ma = middlebox authentication
+-------+ ac = agent challenge
| v aa = agent authentication
+----------+
| CLOSED |----------------+
+----------+ | SE(mc!=0)/
| ^ ^ | success(ma,ac)
SE(mc=0, | | | AST |
aa=OK)/ | | | SE/failure v
success | | | ST/success +----------+
| | +------------| NOAUTH |
| | +----------+
| | AST | SE(mc=0,
v | ST/success | aa=OK)/
+----------+ | success
| OPEN |<---------------+
+----------+
Figure 2: Session State Machine
图2：会话状态机
This section describes the semantics for transactions on policy rules. The following transactions are specified:
本节描述策略规则上事务的语义。指定了以下事务：
- Policy Reserve Rule (PRR) - Policy Enable Rule (PER) - Policy Rule Lifetime Change (RLC) - Policy Rule List (PRL) - Policy Rule Status (PRS) - Asynchronous Policy Rule Event (ARE)
- 策略保留规则（PRR）-策略启用规则（PER）-策略规则生存期更改（RLC）-策略规则列表（PRL）-策略规则状态（PRS）-异步策略规则事件（ARE）
The first three transactions (PRR, PER, RLC) are configuration transactions initiated by the agent. The fourth and fifth (PRL, PRS) are monitoring transactions. The last one (ARE) is an asynchronous transaction. The PRL and PRS transactions do not have any effect on the policy rule state machine.
前三个事务（PRR、PER、RLC）是由代理启动的配置事务。第四个和第五个（PRL、PRS）是监控交易。最后一个是异步事务。PRL和PRS事务对策略规则状态机没有任何影响。
Before any transaction can start, a valid MIDCOM session must be established.
在启动任何事务之前，必须建立有效的MIDCOM会话。
Policy rule transactions PER and RLC constitute the core of the MIDCOM protocol. Both are mandatory, and they serve for
PER和RLC策略规则事务构成MIDCOM协议的核心。这两项都是强制性的，而且都是为公众服务的
- configuring NAT bindings (PER) - configuring firewall pinholes (PER) - extending the lifetime of established policy rules (RLC) - deleting policy rules (RLC)
- 配置NAT绑定（PER）-配置防火墙针孔（PER）-延长已建立策略规则（RLC）的生存期-删除策略规则（RLC）
Some cases require knowing in advance which IP address (and port number) would be chosen by NAT in a PER transaction. This information is required before sufficient information for performing a complete PER transaction is available (see example in section 4.2). For supporting such cases, the core transactions are extended by the Policy Reserve Rule (PRR) transaction serving for
有些情况下，需要提前知道NAT将在每个事务中选择哪个IP地址（和端口号）。在获得足够的信息来执行完整的每笔交易之前，需要这些信息（参见第4.2节中的示例）。为了支持这种情况，核心事务通过服务于的策略保留规则（PRR）事务进行扩展
- reserving addresses and port numbers at NATs (PRR)
- 在NAT（PRR）上保留地址和端口号
Both PRR and PER establish a policy rule. The action within the rule is 'reserve' if set by PRR and 'enable' if set by PER.
PRR和PER都建立了一个策略规则。如果由PRR设置，则规则内的操作为“保留”，如果由PER设置，则规则内的操作为“启用”。
The Policy Reserve Rule (PRR) transaction is used to establish an address reservation on neither side, one side, or both sides of the middlebox, depending on the middlebox configuration. The transaction returns the reserved IP addresses and the optional ranges of port numbers to the agent. No address binding or pinhole configuration is performed at the middlebox. Packet processing at the middlebox remains unchanged.
策略保留规则（PRR）事务用于根据中间盒配置在中间盒的任何一侧、一侧或两侧建立地址保留。事务将保留的IP地址和端口号的可选范围返回给代理。在中间盒上不执行地址绑定或针孔配置。中间箱的数据包处理保持不变。
On pure firewalls, the PRR transaction is successfully processed without any reservation, but the state transition of the MIDCOM protocol engine is exactly the same as on NATs.
在纯防火墙上，可以毫无保留地成功处理PRR事务，但MIDCOM协议引擎的状态转换与NAT上的状态转换完全相同。
On a traditional NAT (see [NAT-TRAD]), only an external address is reserved; on a twice-NAT, an internal and an external address are reserved. The reservation at a NAT is for required resources, such as IP addresses and port numbers, for future use. How the reservation is exactly done depends on the implementation of the NAT. In both cases, the reservation concerns either an IP address only or a combination of an IP address with a range of port numbers.
在传统NAT（参见[NAT-TRAD]）上，只保留一个外部地址；在两次NAT上，保留一个内部地址和一个外部地址。NAT上的保留是为了将来使用所需的资源，如IP地址和端口号。如何准确地进行预订取决于NAT的实现。在这两种情况下，保留要么仅涉及IP地址，要么涉及IP地址与一系列端口号的组合。
The Policy Enable Rule (PER) transaction is used to establish a policy rule that affects packet processing at the middlebox. Depending on its input parameters, it may make use of the reservation established by a PRR transaction or create a new rule from scratch.
策略启用规则（PER）事务用于建立影响中间箱数据包处理的策略规则。根据其输入参数，它可以利用PRR事务建立的保留，或者从头创建新规则。
On a NAT, the enable action is interpreted as a bind action establishing bindings between internal and external addresses. At a firewall, the enable action is interpreted as one or more allow actions configuring pinholes. The number of allow actions depends on the parameters of the request and the implementation of the firewall.
在NAT上，启用操作被解释为在内部和外部地址之间建立绑定的绑定操作。在防火墙上，启用操作被解释为配置针孔的一个或多个允许操作。允许操作的数量取决于请求的参数和防火墙的实现。
On a combined NAT/firewall, the enable action is interpreted as a combination of bind and allow actions.
在组合NAT/防火墙上，启用操作被解释为绑定和允许操作的组合。
The PRR transaction and the PER transaction are described in more detail in sections 2.3.8 and 2.3.9 below.
下文第2.3.8节和第2.3.9节详细描述了PRR交易和每笔交易。
Each policy rule has a middlebox-unique identifier.
每个策略规则都有一个中间盒唯一标识符。
Each policy rule has an owner. Access control to the policy rule is based on ownership (see section 2.1.5). Ownership of a policy rule does not change during lifetime of the policy rule.
每个策略规则都有一个所有者。对策略规则的访问控制基于所有权（参见第2.1.5节）。策略规则的所有权在策略规则的生存期内不会更改。
Each policy rule has an individual lifetime. If the policy rule lifetime expires, the policy rule will be terminated at the middlebox. Typically, the middlebox indicates termination of a policy rule by an ARE transaction. A Policy Rule Lifetime Change (RLC) transaction may extend the lifetime of the policy rule up to the limit specified by the middlebox at session setup. Also, an RLC transaction may be used for shortening a policy rule's lifetime or deleting a policy rule by requesting a lifetime of zero. (Please note that policy rule lifetimes may also be modified by the Group Lifetime Change (GLC) transaction.)
每个策略规则都有各自的生存期。如果策略规则生存期到期，则策略规则将在中间盒处终止。通常，中间框表示ARE事务终止策略规则。策略规则生存期更改（RLC）事务可以将策略规则的生存期延长到会话设置时由中间盒指定的限制。此外，RLC事务可用于缩短策略规则的生存期或通过请求零生存期来删除策略规则。（请注意，组生存期更改（GLC）事务也可以修改策略规则生存期。）
Each policy rule is a member of exactly one policy rule group. Group membership does not change during the lifetime of a policy rule. Selecting the group is part of the transaction establishing the policy rule. This transaction implicitly creates a new group if the agent does not specify one. The new group identifier is chosen by the middlebox. New members are added to an existing group if the agent's request designates one. A group only exists as long as it has member policy rules. As soon as all policies belonging to the group have reached the ends of their lifetimes, the group does not exist anymore.
每个策略规则都是一个策略规则组的成员。在策略规则的生存期内，组成员身份不会更改。选择组是建立策略规则的事务的一部分。如果代理未指定新组，则此事务隐式创建新组。新的组标识符由中间盒选择。如果代理的请求指定了一个现有组，则会将新成员添加到该组中。组只有在具有成员策略规则时才存在。一旦属于该组的所有策略到达其生命周期的终点，该组就不再存在。
Agents can explore the properties and status of all policy rules they are allowed to access by using the Policy Rule Status (PRS) transaction.
代理可以通过使用策略规则状态（PRS）事务来查看允许其访问的所有策略规则的属性和状态。
If a policy rule changes its state or if its remaining lifetime is changed in ways other than being decreased by time, then all agents that can access this policy rule and that participate in an open session with the middlebox are notified by the middlebox. If the state or lifetime change was requested explicitly by a request message, then the middlebox notifies the requesting agent by returning the corresponding reply. All other agents that can access the policy are notified by a Policy Rule Event Notification (REN) message.
如果某个策略规则更改了其状态，或者其剩余生存期不是按时间缩短的，而是以其他方式更改的，则所有可以访问此策略规则并参与与中间盒的打开会话的代理都会收到中间盒的通知。如果状态或生存期更改是由请求消息明确请求的，则中间盒通过返回相应的答复通知请求代理。策略规则事件通知（REN）消息将通知可以访问策略的所有其他代理。
Note that a middlebox can serve multiple agents at the same time in different parallel sessions. Between these agents, the sets of policy rules that can be accessed by them may overlap. For example, there might be an agent that authenticates as administrator and that can access all policies of all agents. Or there could be a backup agent running a session in parallel to a main agent and authenticating itself as the same entity as the main agent.
请注意，中间盒可以在不同的并行会话中同时为多个代理提供服务。在这些代理之间，它们可以访问的策略规则集可能重叠。例如，可能有一个代理以管理员身份进行身份验证，并且可以访问所有代理的所有策略。或者，可能有一个备份代理与主代理并行运行会话，并将自身验证为与主代理相同的实体。
In case of a PER, PRR, or RLC transaction, the requesting agent receives a PER, PRR, or RLC reply, respectively. To all other agents that can access the created, modified, or terminated policy rule (and that participate in an open session with the middlebox), the middlebox sends a REN message carrying the policy rule identifier (PID) and the remaining lifetime of the policy rule.
在PER、PRR或RLC事务的情况下，请求代理分别接收PER、PRR或RLC回复。对于可以访问已创建、修改或终止的策略规则（以及参与与middlebox的开放会话）的所有其他代理，middlebox将发送一条REN消息，其中包含策略规则标识符（PID）和策略规则的剩余生存期。
In case of a rule termination by lifetime truncation or other events not triggered by an agent, the middlebox sends a REN message to each agent that can access the particular policy rule and that participates in an open session with the middlebox. This ensures that an agent always knows the most recent state of all policy rules it can access.
如果规则因生存期截断或其他非由代理触发的事件而终止，则中间盒将向每个可以访问特定策略规则并参与与中间盒的开放会话的代理发送REN消息。这确保代理始终知道它可以访问的所有策略规则的最新状态。
Request and reply messages of the PRR, PER, and PRS transactions contain address specifications for IP and transport addresses. These parameters include
PRR、PER和PRS事务的请求和回复消息包含IP和传输地址的地址规范。这些参数包括
- IP version - IP address - IP address prefix length - transport protocol - port number - port parity - port range
- IP版本-IP地址-IP地址前缀长度-传输协议-端口号-端口奇偶校验-端口范围
Additionally, the request message of PER and the reply message of PRS contain a direction of flow parameter. This direction of flow parameter indicates for UDP and IP the direction of packets traversing the middlebox. For 'inbound', the UDP packets are traversing from outside to inside; for 'outbound', from inside to outside. In both cases, the packets can traverse the middlebox only unidirectionally. A bidirectional flow is enabled through 'bidirectional' as direction of flow parameter. For TCP, the packet flow is always bidirectional, but the direction of the flow parameter is defined as
此外，PER的请求消息和PRS的回复消息包含流向参数。此流向参数指示UDP和IP数据包穿过中间盒的方向。对于“入站”，UDP数据包从外到内遍历；对于“出站”，从内到外。在这两种情况下，数据包只能单向穿过中间盒。通过“双向”作为流动方向参数启用双向流动。对于TCP，数据包流始终是双向的，但流参数的方向定义为
- inbound: bidirectional TCP packet flow. First packet, with TCP SYN flag set and ACK flag not set, must arrive at the middlebox at the outside interface.
- 入站：双向TCP数据包流。设置了TCP SYN标志且未设置ACK标志的第一个数据包必须到达外部接口的中间盒。
- outbound: bidirectional TCP packet flow. First packet, with TCP SYN flag set and ACK flag not set, must arrive at the middlebox at the inside interface.
- 出站：双向TCP数据包流。设置了TCP SYN标志且未设置ACK标志的第一个数据包必须到达内部接口的中间盒。
- bidirectional: bidirectional TCP packet flow. First packet, with TCP SYN flag set and ACK flag not set, may arrive at inside or outside interface.
- 双向：双向TCP数据包流。设置了TCP SYN标志且未设置ACK标志的第一个数据包可能到达接口内部或外部。
We refer to the set of these parameters as an address tuple. An address tuple specifies either a communication endpoint at an internal or external device or allocated addresses at the middlebox. In this document, we distinguish four kinds of address tuples, as shown in Figure 3.
我们将这些参数集称为地址元组。地址元组指定内部或外部设备上的通信端点或在中间盒上分配的地址。在本文中，我们区分了四种地址元组，如图3所示。
+----------+ +----------+
| internal | A0 A1 +-----------+ A2 A3 | external |
| endpoint +----------+ middlebox +----------+ endpoint |
+----------+ +-----------+ +----------+
+----------+ +----------+
| internal | A0 A1 +-----------+ A2 A3 | external |
| endpoint +----------+ middlebox +----------+ endpoint |
+----------+ +-----------+ +----------+
Figure 3: Address Tuples A0 - A3
图3：地址元组A0-A3
- A0 - internal endpoint: Address tuple A0 specifies a communication endpoint of a device within the internal network, with respect to the middlebox.
- A0-内部端点：地址元组A0指定内部网络中设备相对于中间盒的通信端点。
- A1 - middlebox inside address: Address tuple A1 specifies a virtual communication endpoint at the middlebox within the internal network. A1 is the destination address for packets passing from the internal endpoint to the middlebox and is the source for packets passing from the middlebox to the internal endpoint.
- A1-中间盒内部地址：地址元组A1指定内部网络中中间盒处的虚拟通信端点。A1是从内部端点传递到中间盒的数据包的目标地址，是从中间盒传递到内部端点的数据包的源地址。
- A2 - middlebox outside address: Address tuple A2 specifies a virtual communication endpoint at the middlebox within the external network. A2 is the destination address for packets passing from the external endpoint to the middlebox and is the source for packets passing from the middlebox to the external endpoint.
- A2-中间盒外部地址：地址元组A2指定外部网络中中间盒处的虚拟通信端点。A2是从外部端点传递到中间盒的数据包的目标地址，也是从中间盒传递到外部端点的数据包的源地址。
- A3 - external endpoint: Address tuple A3 specifies a communication endpoint of a device within the external network, with respect to the middlebox.
- A3-外部端点：地址元组A3指定外部网络中设备相对于中间盒的通信端点。
For a firewall, the inside and outside endpoints are identical to the corresponding external or internal endpoints, respectively. In this case, the installed policy rule sets the same value in A2 as in A0 (A0=A2) and sets the same value in A1 as in A3 (A1=A3).
对于防火墙，内部和外部端点分别与相应的外部或内部端点相同。在这种情况下，已安装的策略规则在A2中设置的值与在A0中设置的值相同（A0=A2），在A1中设置的值与在A3中设置的值相同（A1=A3）。
For a traditional NAT, A2 is given a value different from that of A0, but the NAT binds them. As for the firewall, it is also as it is at a traditional NAT: A1 has the same value as A3.
对于传统NAT，A2的值与A0的值不同，但NAT将其绑定。至于防火墙，也和传统NAT一样：A1的值与A3的值相同。
For a twice-NAT, there are two bindings of address tuples: A1 and A2 are both assigned values by the NAT. The middlebox outside address A2 is bound to the internal endpoint A0, and the middlebox inside address A1 is bound to the external endpoint A3.
对于两次NAT，有两个地址元组绑定：A1和A2都是NAT分配的值。中间盒外部地址A2绑定到内部端点A0，中间盒内部地址A1绑定到外部端点A3。
For transaction parameters belonging to an address tuple, some constraints exist that are common for all messages using them. Therefore, these constraints are summarized in the following and are not repeated again when describing the parameters in the transaction descriptions are presented.
对于属于地址元组的事务参数，存在一些对使用它们的所有消息通用的约束。因此，这些约束在下文中进行了总结，在描述事务描述中的参数时不再重复。
The MIDCOM semantics defined in this document specifies the handling of IPv4 and IPv6 as network protocols, and of TCP and UDP (over IPv4 and IPv6) as transport protocols. The handling of any other transport protocol, e.g., Stream Control Transmission Protocol (SCTP), is not defined within the semantics but may be supported by concrete protocol specifications.
本文档中定义的MIDCOM语义将IPv4和IPv6指定为网络协议，将TCP和UDP（通过IPv4和IPv6）指定为传输协议。任何其他传输协议（例如流控制传输协议（SCTP））的处理未在语义中定义，但可由具体的协议规范支持。
The IP version parameter has either the value 'IPv4' or 'IPv6'. In a policy rule, the value of the IP version parameter must be the same for address tuples A0 and A1, and for A2 and A3.
IP版本参数的值为“IPv4”或“IPv6”。在策略规则中，对于地址元组A0和A1以及A2和A3，IP版本参数的值必须相同。
The value of the IP address parameter must conform with the specified IP version.
IP地址参数的值必须符合指定的IP版本。
The IP address of an address tuple may be wildcarded. Whether IP address wildcarding is allowed or in which range it is allowed depends on the local policy of the middlebox; see also section 6, "Security Considerations". Wildcarding is specified by the IP address prefix length parameter of an address tuple. In line with the common use of a prefix length, this parameter indicates the number of high significant bits of the IP address that are fixed, while the remaining low significant bits of the IP address are wildcarded.
地址元组的IP地址可以是通配符。是否允许IP地址通配符或允许在哪个范围内通配符取决于中间盒的本地策略；另见第6节“安全考虑”。通配符由地址元组的IP地址前缀长度参数指定。与前缀长度的常用用法一致，此参数表示固定的IP地址的高有效位的数量，而IP地址的剩余低有效位是通配符。
The value of the transport protocol parameter can be either 'TCP', 'UDP', or 'ANY'. If the transport protocol parameter has the value 'ANY', only IP headers are considered for packet handling in the middlebox -- i.e., the transport header is not considered. The values of the parameters port number, port range, and port parity are irrelevant if the protocol parameter is 'ANY'. In a policy rule, the value of the transport protocol parameter must be the same for all address tuples A0, A1, A2, and A3.
传输协议参数的值可以是“TCP”、“UDP”或“任意”。如果transport protocol参数的值为“ANY”，则只考虑IP报头来处理中间盒中的数据包，即不考虑传输报头。如果协议参数为“ANY”，则参数端口号、端口范围和端口奇偶校验的值不相关。在策略规则中，对于所有地址元组A0、A1、A2和A3，传输协议参数的值必须相同。
The value of the port number parameter is either zero or a positive integer. A positive integer specifies a concrete UDP or TCP port number. The value zero specifies port wildcarding for the protocol specified by the transport protocol parameter. If the port number parameter has the value zero, then the value of the port range parameter is irrelevant. Depending on the value of the transport protocol parameter, this parameter may truly refer to ports or may refer to an equivalent concept.
端口号参数的值为零或正整数。正整数指定具体的UDP或TCP端口号。值零指定传输协议参数指定的协议的端口通配符。如果端口号参数的值为零，则端口范围参数的值不相关。根据传输协议参数的值，此参数可能真正指端口，也可能指等效概念。
The port parity parameter is differently used in the context of Policy Reserve Rules (PRRs) and Policy Enable Rules (PERs). In the context of a PRR, the value of the parameter may be 'odd', 'even', or 'any'. It specifies the parity of the first (lowest) reserved port number.
端口奇偶校验参数在策略保留规则（PRR）和策略启用规则（PER）的上下文中使用不同。在PRR的上下文中，参数的值可以是“奇数”、“偶数”或“任意”。它指定第一个（最低）保留端口号的奇偶校验。
In the context of a PER, the port parity parameter indicates to the middlebox whether port numbers allocated at the middlebox should have the same parity as the corresponding internal or external port numbers, respectively. In this context, the parameter has the value 'same' or 'any'. If the value is 'same', then the parity of the port number of A0 must be the same as the parity of the port number of A2, and the parity of the port number of A1 must be the same as the parity of the port number of A3. If the port parity parameter has the value 'any', then there are no constraints on the parity of any port number.
在PER的上下文中，端口奇偶校验参数向中间箱指示在中间箱分配的端口号是否应分别与相应的内部或外部端口号具有相同的奇偶校验。在此上下文中，参数的值为“same”或“any”。如果该值为“相同”，则A0端口号的奇偶校验必须与A2端口号的奇偶校验相同，A1端口号的奇偶校验必须与A3端口号的奇偶校验相同。如果端口奇偶校验参数的值为“any”，则任何端口号的奇偶校验都没有限制。
The port range parameter specifies a number of consecutive port numbers. Its value is a positive integer. Like the port number parameter, this parameter defines a set of consecutive port numbers
port range参数指定连续端口号的数量。它的值是正整数。与端口号参数一样，此参数定义一组连续的端口号
starting with the port number specified by the port number parameter as the lowest port number and having as many elements as specified by the port range parameter. A value of 1 specifies a single port number. The port range parameter must have the same value for each address tuple A0, A1, A2, and A3.
以port number参数指定的端口号作为最低端口号开始，并具有port range参数指定的尽可能多的元素。值1指定单个端口号。对于每个地址元组A0、A1、A2和A3，端口范围参数必须具有相同的值。
A single policy rule P containing a port range value greater than one is equivalent to a set of policy rules containing a number n of policies P_1, P_2, ..., P_n where n equals the value of the port range parameter. Each policy rule P_1, P_2, ..., P_n has a port range parameter value of 1. Policy rule P_1 contains a set of address tuples A0_1, A1_1, A2_1, and A3_1, each of which contains the first port number of the respective address tuples in P; policy rule P_2 contains a set of address tuples A0_2, A1_2, A2_2, and A3_2, each of which contains the second port number of the respective address tuples in P; and so on.
包含端口范围值大于1的单个策略规则P相当于包含多个策略P_1、P_2、…、P_n的一组策略规则，其中n等于端口范围参数的值。每个策略规则P_1、P_2、…、P_n的端口范围参数值为1。策略规则P_1包含一组地址元组A0_1、A1_1、A2_1和A3_1，每个地址元组都包含P中各个地址元组的第一个端口号；策略规则P_2包含一组地址元组A0_2、A1_2、A2_2和A3_2，其中每个都包含P中各个地址元组的第二端口号；等等
Usually, agents request policy rules with the knowledge of A0 and A3 only, i.e., the address tuples (see section 2.3.5). But in very special cases, agents may need to select the interfaces to which the requested policy rule is bound. Generally, the middlebox is careful about choosing the right interfaces when reserving or enabling a policy rule, as it has the overall knowledge about its configuration. For agents that want to select the interfaces, optional parameters are included in the Policy Reserve Rule (PRR) and Policy Enable Rule (PER) transactions. These parameters are called
通常，代理请求策略规则时只需要了解A0和A3，即地址元组（见第2.3.5节）。但在非常特殊的情况下，代理可能需要选择所请求的策略规则绑定到的接口。一般来说，在保留或启用策略规则时，中间件会小心选择正确的接口，因为它对其配置有全面的了解。对于要选择接口的代理，可选参数包含在策略保留规则（PRR）和策略启用规则（PER）事务中。这些参数称为
- inside interface: The selected interface at the inside of the middlebox -- i.e., in the private or protected address realm.
- 内部接口：位于中间盒内部的所选接口，即在私有或受保护的地址域中。
- outside interface: The selected interface at the outside of the middlebox -- i.e., in the public address realm.
- 外部接口：位于中间盒外部的所选接口，即在公共广播领域中。
The Policy Rule Status (PRS) transactions include these optional parameters in their replies when they are supported.
策略规则状态（PRS）事务在受支持时在其答复中包括这些可选参数。
Agents can learn at session startup whether interface-specific policy rules are supported by the middlebox, by checking the middlebox capabilities (see section 2.1.6).
代理可以在会话启动时通过检查middlebox功能（参见第2.1.6节），了解middlebox是否支持特定于接口的策略规则。
transaction-name: policy reserve rule
事务处理名称：策略保留规则
transaction-type: configuration
事务类型：配置
transaction-compliance: mandatory
交易合规性：强制性
request-parameters:
请求参数：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 请求标识符：用于在代理上匹配相应请求和答复的代理唯一标识符。
- group identifier: A reference to the group of which the policy reserve rule should be a member. As indicated in section 2.3.3, if this value is not supplied, the middlebox assigns a new group for this policy reserve rule.
- 组标识符：对策略保留规则应为其成员的组的引用。如第2.3.3节所述，如果未提供此值，则中间盒将为此策略保留规则分配一个新组。
- service: The requested NAT service of the middlebox. Allowed values are 'traditional' or 'twice'.
- 服务：请求的中间箱NAT服务。允许的值为“传统”或“两次”。
- internal IP version: Requested IP version at the inside of the middlebox; see section 2.3.5.
- 内部IP版本：在中间盒内部请求的IP版本；见第2.3.5节。
- internal IP address: The IP address of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部IP地址：内部通信端点的IP地址（图3中的A0）；见第2.3.5节。
- internal port number: The port number of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部端口号：内部通信端点的端口号（图3中的A0）；见第2.3.5节。
- inside interface (optional): Interface at the inside of the middlebox; see section 2.3.7.
- 内部接口（可选）：位于中间盒内部的接口；见第2.3.7节。
- external IP version: Requested IP version at the outside of the middlebox; see section 2.3.5.
- 外部IP版本：在中间盒外部请求的IP版本；见第2.3.5节。
- outside interface (optional): Interface at the outside of the middlebox; see section 2.3.7.
- 外部接口（可选）：中间盒外部接口；见第2.3.7节。
- transport protocol: See section 2.3.5.
- 传输协议：见第2.3.5节。
- port range: The number of consecutive port numbers to be reserved; see section 2.3.5.
- 端口范围：要保留的连续端口号的数目；见第2.3.5节。
- port parity: The requested parity of the first (lowest) port number to be reserved; allowed values for this parameter are 'odd', 'even', and 'any'. See also section 2.3.5.
- 端口奇偶校验：要保留的第一个（最低）端口号的请求奇偶校验；此参数允许的值为“奇数”、“偶数”和“任意”。另见第2.3.5节。
- policy rule lifetime: A lifetime proposal to the middlebox for the requested policy rule.
- 策略规则生存期：为请求的策略规则向中间盒提交的生存期建议。
reply-parameters (success):
答复参数（成功）：
- request identifier: An identifier matching the identifier of the request.
- 请求标识符：与请求标识符匹配的标识符。
- policy rule identifier: A middlebox-unique policy rule identifier. It is assigned by the middlebox and used as policy rule handle in further policy rule transactions, particularly to refer to the policy reserve rule in a subsequent PER transaction.
- 策略规则标识符：中间盒唯一的策略规则标识符。它由中间盒分配，并在进一步的策略规则事务中用作策略规则句柄，特别是在后续的每个事务中引用策略保留规则。
- group identifier: A reference to the group of which the policy reserve rule is a member.
- 组标识符：对策略保留规则所属组的引用。
- reserved inside IP address: The reserved IPv4 or IPv6 address on the internal side of the middlebox. For an outbound flow, this will be the destination to which the internal endpoint sends its packets (A1 in Figure 3). For an inbound flow, it will be the apparent source address of the packets as forwarded to the internal endpoint (A0 in Figure 3). The middlebox reserves and reports an internal address only in the case where twice-NAT is in effect. Otherwise, an empty value for the addresses indicates that no internal reservation was made. See also section 2.3.5.
- 保留内部IP地址：位于中间盒内部的保留IPv4或IPv6地址。对于出站流，这将是内部端点向其发送数据包的目的地（图3中的A1）。对于入站流，它将是转发到内部端点的数据包的明显源地址（图3中的A0）。只有在两次NAT生效的情况下，中间盒才会保留并报告内部地址。否则，地址的空值表示未进行内部保留。另见第2.3.5节。
- reserved inside port number: See section 2.3.5.
- 预留内部端口号：见第2.3.5节。
- reserved outside IP address: The reserved IPv4 or IPv6 address on the external side of the middlebox. For an inbound flow, this will be the destination to which the external endpoint sends its packets (A2 in Figure 3). For an outbound flow, it will be the apparent source address of the packets as forwarded to the external endpoint (A3 in Figure 3). If the middlebox is configured as a pure firewall, an empty value for the addresses indicates that no external reservation was made. See also section 2.3.5.
- 保留的外部IP地址：位于中间盒外部的保留IPv4或IPv6地址。对于入站流，这将是外部端点向其发送数据包的目的地（图3中的A2）。对于出站流，它将是转发到外部端点的数据包的明显源地址（图3中的A3）。如果将中间件配置为纯防火墙，则地址的空值表示未进行外部保留。另见第2.3.5节。
- reserved outside port number: See section 2.3.5.
- 预留外部端口号：见第2.3.5节。
- policy rule lifetime: The policy rule lifetime granted by the middlebox, after which the reservation will be revoked if it has not been replaced already by a policy enable rule in a PER transaction.
- 策略规则生存期：由中间盒授予的策略规则生存期，在此之后，如果保留尚未被每个事务中的策略启用规则替换，则将撤销保留。
failure reason:
故障原因：
- agent not authorized for this transaction - agent not authorized to add members to this group - lack of IP addresses - lack of port numbers - lack of resources - specified inside/outside interface does not exist - specified inside/outside interface not available for specified service
- 代理未为此事务授权-代理未授权将成员添加到此组-缺少IP地址-缺少端口号-缺少资源-指定的内部/外部接口不存在-指定的内部/外部接口不可用于指定的服务
notification message type: Policy Rule Event Notification (REN)
通知消息类型：策略规则事件通知（REN）
semantics:
语义：
The agent can use this transaction type to reserve an IP address or a combination of IP address, transport type, port number, and port range at neither side, one side, or both sides of the middlebox as required to support the enabling of a flow. Typically, the PRR will be used in scenarios where it is required to perform such a reservation before sufficient parameters for a complete policy enable rule transaction are available. See section 4.2 for an example.
代理可以使用此事务类型在中间箱的任意一侧、一侧或两侧保留IP地址或IP地址、传输类型、端口号和端口范围的组合，以支持流的启用。通常，PRR将用于需要在完整的策略启用规则事务的足够参数可用之前执行此类保留的场景。有关示例，请参见第4.2节。
When receiving the request, the middlebox determines how many address (and port) reservations are required based on its configuration. If it provides only packet filter services, it does not perform any reservation and returns empty values for the reserved inside and outside IP addresses and port numbers. If it is configured for twice-NAT, it reserves both inside and outside IP addresses (and an optional range of port numbers) and returns them. Otherwise, it reserves and returns an outside IP address (and an optional range of port numbers) and returns empty values for the reserved inside address and port range.
当收到请求时，中间盒根据其配置确定需要多少地址（和端口）保留。如果它只提供包过滤服务，则不执行任何保留，并为保留的内部和外部IP地址和端口号返回空值。如果将其配置为两次NAT，它将保留内部和外部IP地址（以及可选的端口号范围）并返回它们。否则，它将保留并返回外部IP地址（以及端口号的可选范围），并为保留的内部地址和端口范围返回空值。
The A0 parameter (inside IP address version, inside IP address, and inside port number) can be used by the middlebox to determine the correct NAT mapping and thus A2 if necessary. Once a PRR transaction has reserved an outside address (A2) for an internal endpoint (A0) at the middlebox, the middlebox must ensure that this reserved A2 is available in any subsequent PER and PRR transactions.
中间盒可以使用A0参数（内部IP地址版本、内部IP地址和内部端口号）来确定正确的NAT映射，从而在必要时确定A2。一旦PRR交易在中间箱为内部端点（A0）保留了外部地址（A2），中间箱必须确保该保留A2在任何后续PER和PRR交易中可用。
For middleboxes supporting interface-specific policy rules, as defined in section 2.3.7, the optional inside and outside interface parameters must both be included in the request, or neither of them should be included. In the presence of these parameters, the middlebox uses the outside interface parameter to
对于支持接口特定策略规则的中间盒，如第2.3.7节所定义，请求中必须同时包含可选的内部和外部接口参数，或者两者都不应包含。存在这些参数时，中间盒使用外部接口参数
select the interface at which the outside address tuple (outside IP address and port number) is reserved, and the inside interface parameter to select the interface at which the inside address tuple (inside IP address and port number) is reserved. Without the presence of these parameters, the middlebox selects the particular interfaces based on its internal configuration.
选择保留外部地址元组（外部IP地址和端口号）的接口，选择内部接口参数以选择保留内部地址元组（内部IP地址和端口号）的接口。在不存在这些参数的情况下，中间盒会根据其内部配置选择特定的接口。
If there is a lack of resources, such as available IP addresses, port numbers, or storage for further policy rules, then the reservation fails, and an appropriate failure reply is generated.
如果缺少资源，如可用IP地址、端口号或用于进一步策略规则的存储，则保留失败，并生成相应的失败回复。
If a non-existing policy rule group was specified, or if an existing policy rule group was specified that is not owned by the requesting agent, then no new policy rule is established, and an appropriate failure reply is generated.
如果指定了不存在的策略规则组，或者指定了不属于请求代理的现有策略规则组，则不会建立新的策略规则，并生成相应的失败回复。
In case of success, this transaction creates a new policy reserve rule. If an already existing policy rule group is specified, then the new policy rule becomes a member of it. If no policy group is specified, a new group is created with the new policy rule as its only member. The middlebox generates a middlebox-unique identifier for the new policy rule. The owner of the new policy rule is the authenticated agent that sent the request. The middlebox chooses a lifetime value that is greater than zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox at session startup, i.e.,
如果成功，此事务将创建新的策略保留规则。如果指定了已存在的策略规则组，则新策略规则将成为该组的成员。如果未指定策略组，将创建一个新组，并将新策略规则作为其唯一成员。中间箱为新策略规则生成一个中间箱唯一标识符。新策略规则的所有者是发送请求的经过身份验证的代理。中间盒选择的生存期值大于零且小于或等于请求值的最小值和中间盒在会话启动时指定的最大生存期，即。，
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
where - lt_granted is the lifetime actually granted by the middlebox - lt_requested is the lifetime the agent requested - lt_maximum is the maximum lifetime specified at session setup
其中，-lt_-grated是中间盒实际授予的生存期-lt_-requested是代理请求的生存期-lt_-maximum是会话设置中指定的最大生存期
A middlebox with NAT capability always reserves a middlebox external address tuple (A2) in response to a PRR request. In the special case of a combined twice-NAT/NAT middlebox, the agent can request only NAT service or twice-NAT service by choosing the service parameter 'traditional' or 'twice'. An agent that does not have any preference chooses 'twice'. The 'traditional' value should only be used to select traditional NAT service at middleboxes offering both traditional NAT and twice-NAT. In the 'twice' case, the combined twice-NAT/NAT middlebox reserves A2 and A1; the 'traditional' case results in a reservation of A2 only. An agent must always use the PRR transaction for choosing NAT only
具有NAT功能的中间盒始终保留一个中间盒外部地址元组（A2）以响应PRR请求。在组合两次NAT/NAT中间盒的特殊情况下，代理可以通过选择服务参数“传统”或“两次”仅请求NAT服务或两次NAT服务。没有任何偏好的代理选择“两次”。“传统”值只能用于在同时提供传统NAT和两次NAT的中间盒中选择传统NAT服务。在“两次”情况下，组合的两次NAT/NAT中间盒保留A2和A1；“传统”案例仅导致A2保留。代理必须始终使用PRR事务仅用于选择NAT
or twice-NAT service in the special case of a combined twice-NAT/NAT middlebox. A firewall middlebox ignores this parameter.
或者在组合两次NAT/NAT中间盒的特殊情况下使用两次NAT服务。防火墙中间盒忽略此参数。
If the protocol identifier is 'ANY', then the middlebox reserves available inside and/or outside IP address(es) only. The reserved address(es) are returned to the agent. In this case, the request-parameters "port range" and "port parity" as well as the reply-parameters "inside port number" and "outside port number" are irrelevant.
如果协议标识符为“ANY”，则中间盒仅保留内部和/或外部IP地址。保留地址将返回给代理。在这种情况下，请求参数“端口范围”和“端口奇偶校验”以及应答参数“内部端口号”和“外部端口号”是不相关的。
If the protocol identifier is 'UDP' or 'TCP', then a combination of an IP address and a consecutive sequence of port numbers, starting with the specified parity, is reserved, on neither side, one side, or both sides of the middlebox, as appropriate. The IP address(es) and the first (lowest) reserved port number(s) of the consecutive sequence are returned to the agent. (This also applies to other protocols supporting ports or the equivalent.)
如果协议标识符为“UDP”或“TCP”，则IP地址和从指定奇偶校验开始的连续端口号序列的组合将被保留在中间盒的任意一侧、一侧或两侧（视情况而定）。将IP地址和连续序列的第一个（最低）保留端口号返回给代理。（这也适用于支持端口或等效端口的其他协议。）
After a new policy reserve rule is successfully established and the reply message has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents participating in open sessions, which can access the new policy rule. If the middlebox finds one or more of these agents, then it sends a REN message reporting the new policy rule to each of them.
成功建立新策略保留规则并将答复消息发送给请求代理后，中间盒将检查是否有其他经过身份验证的代理参与开放会话，这些代理可以访问新策略规则。如果中间盒找到一个或多个代理，则会向每个代理发送一条REN消息，报告新的策略规则。
MIDCOM agents use the policy enable rule (PER) transaction to enable policy reserve rules that have been established beforehand by a policy reserve rule (PRR) transaction. See also section 2.3.2.
MIDCOM代理使用策略启用规则（PER）事务来启用策略保留规则（PRR）事务预先建立的策略保留规则。另见第2.3.2节。
transaction-name: policy enable rule
事务名称：策略启用规则
transaction-type: configuration
事务类型：配置
transaction-compliance: mandatory
交易合规性：强制性
request-parameters:
请求参数：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 请求标识符：用于在代理上匹配相应请求和答复的代理唯一标识符。
- policy reserve rule identifier: A reference to an already existing policy reserve rule created by a PRR transaction. The reference may be empty, in which case the middlebox must assign any necessary addresses and port numbers within this PER transaction. If it is not empty, then the following request parameters are irrelevant: group identifier, transport protocol,
- 策略保留规则标识符：对PRR事务创建的现有策略保留规则的引用。引用可能为空，在这种情况下，中间盒必须为此每笔交易分配任何必要的地址和端口号。如果不为空，则以下请求参数不相关：组标识符、传输协议、，
port range, port parity, internal IP version, external IP version.
端口范围、端口奇偶校验、内部IP版本、外部IP版本。
- group identifier: A reference to the group of which the policy enable rule should be a member. As indicated in section 2.3.3, if this value is not supplied, the middlebox assigns a new group for this policy reserve rule.
- 组标识符：对策略启用规则应为其成员的组的引用。如第2.3.3节所述，如果未提供此值，则中间盒将为此策略保留规则分配一个新组。
- transport protocol: See section 2.3.5.
- 传输协议：见第2.3.5节。
- port range: The number of consecutive port numbers to be reserved; see section 2.3.5.
- 端口范围：要保留的连续端口号的数目；见第2.3.5节。
- port parity: The requested parity of the port number(s) to be mapped. Allowed values of this parameter are 'same' and 'any'. See also section 2.3.5.
- 端口奇偶校验：要映射的端口号的请求奇偶校验。此参数的允许值为“相同”和“任意”。另见第2.3.5节。
- direction of flow: This parameter specifies the direction of enabled communication, either 'inbound', 'outbound', or 'bidirectional'.
- 流向：此参数指定启用通信的方向，可以是“入站”、“出站”或“双向”。
- internal IP version: Requested IP version at the inside of the middlebox; see section 2.3.5.
- 内部IP版本：在中间盒内部请求的IP版本；见第2.3.5节。
- internal IP address: The IP address of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部IP地址：内部通信端点的IP地址（图3中的A0）；见第2.3.5节。
- internal port number: The port number of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部端口号：内部通信端点的端口号（图3中的A0）；见第2.3.5节。
- inside interface (optional): Interface at the inside of the middlebox; see section 2.3.7.
- 内部接口（可选）：位于中间盒内部的接口；见第2.3.7节。
- external IP version: Requested IP version at the outside of the middlebox; see section 2.3.5.
- 外部IP版本：在中间盒外部请求的IP版本；见第2.3.5节。
- external IP address: The IP address of the external communication endpoint (A3 in Figure 3); see section 2.3.5.
- 外部IP地址：外部通信端点的IP地址（图3中的A3）；见第2.3.5节。
- external port number: The port number of the external communication endpoint (A3 in Figure 3), see section 2.3.5.
- 外部端口号：外部通信端点的端口号（图3中的A3），参见第2.3.5节。
- outside interface (optional): Interface at the outside of the middlebox; see section 2.3.7.
- 外部接口（可选）：中间盒外部接口；见第2.3.7节。
- policy rule lifetime: A lifetime proposal to the middlebox for the requested policy rule.
- 策略规则生存期：为请求的策略规则向中间盒提交的生存期建议。
reply-parameters (success):
答复参数（成功）：
- request identifier: An identifier matching the identifier of the request.
- 请求标识符：与请求标识符匹配的标识符。
- policy rule identifier: A middlebox-unique policy rule identifier. It is assigned by the middlebox and used as policy rule handle in further policy rule transactions. If a policy reserve rule identifier was provided in the request, then the returned policy rule identifier has the same value.
- 策略规则标识符：中间盒唯一的策略规则标识符。它由中间盒分配，并在进一步的策略规则事务中用作策略规则句柄。如果请求中提供了策略保留规则标识符，则返回的策略规则标识符具有相同的值。
- group identifier: A reference to the group of which the policy enable rule is a member. If a policy reserve rule identifier was provided in the request, then this parameter identifies the group of which the policy reserve rule was a member.
- 组标识符：对策略启用规则所属组的引用。如果请求中提供了策略保留规则标识符，则此参数标识策略保留规则所属的组。
- inside IP address: The IP address provided at the inside of the middlebox (A1 in Figure 3). In case of a twice-NAT, this parameter will be an internal IP address reserved at the inside of the middlebox. In all other cases, this reply-parameter will be identical with the external IP address passed with the request. If the policy reserve rule identifier parameter was supplied in the request and the respective PRR transaction reserved an inside IP address, then the inside IP address provided in the PER response will be the identical value to that returned by the response to the PRR request. See also section 2.3.5.
- 内部IP地址：在中间盒内部提供的IP地址（图3中的A1）。在两次NAT的情况下，此参数将是在中间盒内部保留的内部IP地址。在所有其他情况下，此回复参数将与请求传递的外部IP地址相同。如果请求中提供了策略保留规则标识符参数，并且相应的PRR事务保留了内部IP地址，则每个响应中提供的内部IP地址将与PRR请求响应返回的值相同。另见第2.3.5节。
- inside port number: The internal port number provided at the inside of the middlebox (A1 in Figure 3); see also section 2.3.5.
- 内部端口号：提供在中间盒内部的内部端口号（图3中的A1）；另见第2.3.5节。
- outside IP address: The external IP address provided at the outside of the middlebox (A2 in Figure 3). In case of a pure firewall, this parameter will be identical with the internal IP address passed with the request. In all other cases, this reply-parameter will be an external IP address reserved at the outside of the middlebox. See also section 2.3.5.
- 外部IP地址：在中间盒外部提供的外部IP地址（图3中的A2）。对于纯防火墙，此参数将与请求传递的内部IP地址相同。在所有其他情况下，此回复参数将是在中间盒外部保留的外部IP地址。另见第2.3.5节。
- outside port number: The external port number provided at the outside of the NAT (A2 in Figure 3); see section 2.3.5..
- 外部端口号：NAT外部提供的外部端口号（图3中的A2）；见第2.3.5节。。
- policy rule lifetime: The policy rule lifetime granted by the middlebox.
- 策略规则生存期：由中间盒授予的策略规则生存期。
failure reason:
故障原因：
- agent not authorized for this transaction
- 代理未被授权进行此交易
- agent not authorized to add members to this group - no such policy reserve rule - agent not authorized to replace this policy reserve rule - conflict with already existing policy rule (e.g., the same internal address-port is being mapped to different outside address-port pairs) - lack of IP addresses - lack of port numbers - lack of resources - no internal IP wildcarding allowed - no external IP wildcarding allowed - specified inside/outside interface does not exist - specified inside/outside interface not available for specified service - reserved A0 to requested A0 mismatch
- 代理无权向该组添加成员-无此类策略保留规则-代理无权替换此策略保留规则-与现有策略规则冲突（例如，相同的内部地址端口映射到不同的外部地址端口对）-缺少IP地址-缺少端口号-缺少资源-不允许内部IP通配符-不允许外部IP通配符-指定的内部/外部接口不存在-指定的内部/外部接口不可用于指定服务-保留A0与请求的A0不匹配
notification message type: Policy Rule Event Notification (REN)
通知消息类型：策略规则事件通知（REN）
semantics:
语义：
This transaction can be used by an agent to enable communication between an internal endpoint and an external endpoint independently of the type of middlebox (NAT, NAPT, firewall, NAT-PT, combined devices), for unidirectional or bidirectional traffic.
代理可以使用此事务来实现内部端点和外部端点之间的通信，而不依赖于中间盒（NAT、NAPT、防火墙、NAT-PT、组合设备）的类型，以实现单向或双向通信。
The agent sends an enable request specifying the endpoints (optionally including wildcards) and the direction of communication (inbound, outbound, bidirectional). The communication endpoints are displayed in Figure 3. The basic operation of the PER transaction can be described by
代理发送一个enable请求，指定端点（可选地包括通配符）和通信方向（入站、出站、双向）。通信端点如图3所示。每个事务的基本操作可以通过以下方式描述：
1. the agent sending A0 and A3 to the middlebox,
1. 代理将A0和A3发送到中间箱，
2. the middlebox reserving A1 and A2 or using A1 and A2 from a previous PRR transaction,
2. 中间箱保留A1和A2或使用先前PRR交易中的A1和A2，
3. the middlebox enabling packet transfer between A0 and A3 by binding A0-A2 and A1-A3 and/or by opening the corresponding pinholes, both according to the specified direction, and
3. 通过绑定A0-A2和A1-A3和/或根据指定方向打开相应针孔，实现A0和A3之间数据包传输的中间盒，以及
4. the middlebox returning A1 and A2 to the agent.
4. 将A1和A2返回给代理的中间盒。
In case of a pure packet filtering firewall, the returned address tuples are the same as those in the request: A2=A0 and A1=A3. Each partner uses the other's real address. In case of a traditional NAT, the internal endpoint may use the real address of the external endpoint (A1=A3), but the external endpoint uses an
对于纯包过滤防火墙，返回的地址元组与请求中的地址元组相同：A2=A0和A1=A3。每个合作伙伴都使用对方的真实地址。在传统NAT的情况下，内部端点可以使用外部端点的实际地址（A1=A3），但外部端点使用
address tuple provided by the NAT (A2!=A0). In case of a twice-NAT device, both endpoints use address tuples provided by the NAT for addressing their communication partner (A3!=A1 and A2!=A0).
NAT提供的地址元组（A2！=A0）。对于两次NAT设备，两个端点都使用NAT提供的地址元组来寻址其通信伙伴（A3！=A1和A2！=A0）。
If a firewall is combined with a NAT or a twice-NAT, the replied address tuples will be the same as for pure traditional NAT or twice-NAT, respectively, but the middlebox will configure its packet filter in addition to the performed NAT bindings. In case of a firewall combined with a traditional NAT, the policy rule may imply more than one enable action for the firewall configuration, as incoming and outgoing packets may use different source-destination pairs.
如果防火墙与一个NAT或两次NAT组合，则回复的地址元组将分别与纯传统NAT或两次NAT的地址元组相同，但除了已执行的NAT绑定之外，中间盒还将配置其数据包过滤器。在防火墙与传统NAT组合的情况下，策略规则可能意味着防火墙配置的多个启用操作，因为传入和传出数据包可能使用不同的源-目的地对。
For middleboxes supporting interface-specific policy rules, as defined in section 2.3.7, the optional inside and outside interface parameters must both be included in the request, or neither of them should be included. In the presence of these parameters, the middlebox uses the outside interface parameter to select the interface at which the outside address tuple (outside IP address and port number) is bound, and the inside interface parameter to select the interface at which the inside address tuple (inside IP address and port number) is bound. Without the presence of these parameters, the middlebox selects the particular interfaces based on its internal configuration.
对于支持接口特定策略规则的中间盒，如第2.3.7节所定义，请求中必须同时包含可选的内部和外部接口参数，或者两者都不应包含。在存在这些参数的情况下，中间件使用外部接口参数选择绑定外部地址元组（外部IP地址和端口号）的接口，使用内部接口参数选择绑定内部地址元组（内部IP地址和端口号）的接口。在不存在这些参数的情况下，中间盒会根据其内部配置选择特定的接口。
Checking the Policy Reservation Rule Identifier
正在检查策略保留规则标识符
If the parameter specifying the policy reservation rule identifier is not empty, then the middlebox checks whether the referenced policy rule exists, whether the agent is authorized to replace this policy rule, and whether this policy rule is a policy reserve rule.
如果指定策略保留规则标识符的参数不为空，则中间件将检查引用的策略规则是否存在，代理是否有权替换此策略规则，以及此策略规则是否为策略保留规则。
In case of success, this transaction creates a new policy enable rule. If a policy reserve rule was referenced, then the policy reserve rule is terminated without an explicit notification sent to the agent (other than the successful PER reply).
如果成功，此事务将创建新的策略启用规则。如果引用了策略保留规则，则策略保留规则将在不向代理发送明确通知的情况下终止（除了每次回复成功的通知）。
The PRR transaction sets the internal endpoint A0 during the reservation process. In the process of creating a new policy enable rule, the middlebox may check whether the requested A0 is equal to the reserved A0. The middlebox may reject a PER request with a requested A0 not equal to the reserved A0 and must then send an appropriate failure message. Alternatively, the middlebox may change A0 due to the PER request.
PRR事务在预订过程中设置内部端点A0。在创建新策略启用规则的过程中，中间盒可以检查请求的A0是否等于保留的A0。如果请求的A0不等于保留的A0，则中间盒可能会拒绝每个请求，然后必须发送相应的失败消息。或者，由于PER请求，中间盒可能会更改A0。
The middlebox generates a middlebox-unique identifier for the new policy rule. If a policy reserve rule was referenced, then the identifier of the policy reserve rule is reused.
中间箱为新策略规则生成一个中间箱唯一标识符。如果引用了策略保留规则，则将重用策略保留规则的标识符。
The owner of the new policy rule is the authenticated agent that sent the request.
新策略规则的所有者是发送请求的经过身份验证的代理。
Checking the Policy Rule Group Identifier
正在检查策略规则组标识符
If no policy reserve rule was specified, then the policy rule group parameter is checked. If a non-existing policy rule group is specified, or if an existing policy rule group is specified that is not owned by the requesting agent, then no new policy rule is established, and an appropriate failure reply is generated.
如果未指定策略保留规则，则会选中策略规则组参数。如果指定了不存在的策略规则组，或者指定了不属于请求代理的现有策略规则组，则不会建立新的策略规则，并生成相应的失败回复。
If an already existing policy rule group is specified, then the new policy rule becomes a member. If no policy group is specified, then a new group is created with the new policy rule as its only member.
如果指定了已存在的策略规则组，则新策略规则将成为成员。如果未指定策略组，则将创建一个新组，并将新策略规则作为其唯一成员。
If the transport protocol parameter value is 'ANY', then the middlebox enables communication between the specified external IP address and the specified internal IP address. The addresses to be used by the communication partners to address each other are returned to the agent as inside IP address and outside IP address. If the reservation identifier is not empty and if the reservation used the same transport protocol type, then the reserved IP addresses are used.
如果传输协议参数值为“ANY”，则中间盒启用指定的外部IP地址和指定的内部IP地址之间的通信。通信伙伴用来相互寻址的地址作为内部IP地址和外部IP地址返回给代理。如果保留标识符不为空，并且保留使用相同的传输协议类型，则使用保留的IP地址。
For the transport protocol parameter values 'UDP' and 'TCP', the middlebox acts analogously as for 'ANY' but also maps ranges of port numbers, keeping the port parity, if requested.
对于传输协议参数值“UDP”和“TCP”，中间盒的作用类似于“ANY”，但也映射端口号的范围，在请求时保持端口奇偶校验。
The configuration of the middlebox may fail because of lack of resources, such as available IP addresses, port numbers, or storage for further policy rules. It may also fail because of a conflict with an established policy rule. In case of a conflict, the first-come first-served mechanism is applied. Existing policy rules remain unchanged and arriving new ones are rejected. However, in case of a non-conflicting overlap of policy rules (including identical policy rules), all policy rules are accepted.
由于缺少资源（如可用的IP地址、端口号或用于进一步策略规则的存储），中间盒的配置可能会失败。它也可能因与既定政策规则冲突而失败。如果发生冲突，则采用先到先得的机制。现有的政策规则保持不变，新的政策规则将被拒绝。但是，如果策略规则（包括相同的策略规则）存在不冲突的重叠，则接受所有策略规则。
The middlebox chooses a lifetime value that is greater than zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox at session startup, i.e.,
中间盒选择的生存期值大于零且小于或等于请求值的最小值和中间盒在会话启动时指定的最大生存期，即。，
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
where - lt_granted is the lifetime actually granted by the middlebox - lt_requested is the lifetime the agent requested - lt_maximum is the maximum lifetime specified at session setup
其中，-lt_-grated是中间盒实际授予的生存期-lt_-requested是代理请求的生存期-lt_-maximum是会话设置中指定的最大生存期
In each case of failure, an appropriate failure reply is generated. The policy reserve rule that is referenced in the PER transaction is not affected in case of a failure within the PER transaction -- i.e., the policy reserve rule remains.
在每种故障情况下，都会生成相应的故障回复。如果每个事务中出现故障，则每个事务中引用的策略保留规则不受影响，即策略保留规则保持不变。
After a new policy enable rule is successfully established and the reply message has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents participating in open sessions that can access the new policy rule. If the middlebox finds one or more of these agents, then it sends a REN message reporting the new policy rule to each of them.
成功建立新策略启用规则并将答复消息发送给请求代理后，中间盒将检查是否有其他经过身份验证的代理参与可以访问新策略规则的打开会话。如果中间盒找到一个或多个代理，则会向每个代理发送一条REN消息，报告新的策略规则。
transaction-name: policy rule lifetime change
事务名称：策略规则生存期更改
transaction-type: configuration
事务类型：配置
transaction-compliance: mandatory
交易合规性：强制性
request-parameters:
请求参数：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 请求标识符：用于在代理上匹配相应请求和答复的代理唯一标识符。
- policy rule identifier: Identifying the policy rule for which the lifetime is requested to be changed. This may identify either a policy reserve rule or a policy enable rule.
- 策略规则标识符：标识请求更改其生存期的策略规则。这可以标识策略保留规则或策略启用规则。
- policy rule lifetime: The new lifetime proposal for the policy rule.
- 策略规则生存期：策略规则的新生存期建议。
reply-parameters (success):
答复参数（成功）：
- request identifier: An identifier matching the identifier of the request.
- 请求标识符：与请求标识符匹配的标识符。
- policy rule lifetime: The remaining policy rule lifetime granted by the middlebox.
- 策略规则生存期：由中间盒授予的剩余策略规则生存期。
failure reason:
故障原因：
- agent not authorized for this transaction - agent not authorized to change lifetime of this policy rule - no such policy rule - lifetime cannot be extended
- 代理未对此事务授权-代理未被授权更改此策略规则的生存期-没有此类策略规则-无法延长生存期
notification message type: Policy Rule Event Notification (REN)
通知消息类型：策略规则事件通知（REN）
semantics:
语义：
The agent can use this transaction type to request the extension of an established policy rule's lifetime, the shortening of the lifetime, or policy rule termination. Policy rule termination is requested by suggesting a new policy rule lifetime of zero.
代理可以使用此事务类型请求延长已建立策略规则的生存期、缩短生存期或终止策略规则。通过建议新策略规则生存期为零来请求策略规则终止。
The middlebox first checks whether the specified policy rule exists and whether the agent is authorized to access this policy rule. If one of the checks fails, an appropriate failure reply is generated. If the requested lifetime is longer than the current one, the middlebox also checks whether the lifetime of the policy rule may be extended and generates an appropriate failure message if it may not.
中间盒首先检查指定的策略规则是否存在，以及代理是否有权访问此策略规则。如果其中一项检查失败，将生成相应的失败回复。如果请求的生存期长于当前生存期，则中间盒还会检查策略规则的生存期是否可以延长，如果不能延长，则会生成相应的失败消息。
A failure reply implies that the new lifetime was not accepted, and the policy rule remains unchanged. A success reply is generated by the middlebox if the lifetime of the policy rule was changed in any way.
失败回复意味着新生存期未被接受，并且策略规则保持不变。如果策略规则的生存期以任何方式发生了更改，则中间盒将生成一个成功回复。
The success reply contains the new lifetime of the policy rule. The middlebox chooses a lifetime value that is greater than zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox at session startup, i.e.,
成功回复包含策略规则的新生存期。中间盒选择的生存期值大于零且小于或等于请求值的最小值和中间盒在会话启动时指定的最大生存期，即。，
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
where - lt_granted is the lifetime actually granted by the middlebox - lt_requested is the lifetime the agent requested - lt_maximum is the maximum lifetime specified at session setup
其中，-lt_-grated是中间盒实际授予的生存期-lt_-requested是代理请求的生存期-lt_-maximum是会话设置中指定的最大生存期
After sending a success reply with a lifetime of zero, the middlebox will consider the policy rule non-existent. Any further transaction on this policy rule results in a negative reply, indicating that this policy rule does not exist anymore.
在发送一个生命周期为零的成功答复后，MealBox将考虑不存在策略规则。此策略规则上的任何进一步事务都将导致否定答复，表明此策略规则不再存在。
Note that policy rule lifetime may also be changed by the Group Lifetime Change (GLC) transaction, if applied to the group of which the policy rule is a member.
请注意，如果应用于策略规则所属的组，则组生存期更改（GLC）事务也可以更改策略规则生存期。
After the remaining policy rule lifetime was successfully changed and the reply message has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents participating in open sessions that can access the policy rule. If the middlebox finds one or more of these agents, then it sends a REN message reporting the new remaining policy rule lifetime to each of them.
成功更改剩余的策略规则生存期并将答复消息发送给请求代理后，中间盒将检查是否有其他经过身份验证的代理参与可以访问策略规则的打开会话。如果中间盒找到一个或多个代理，则会向每个代理发送一条REN消息，报告新的剩余策略规则生存期。
transaction-name: policy rule list
事务名称：策略规则列表
transaction-type: monitoring
事务类型：监视
transaction-compliance: mandatory
交易合规性：强制性
request-parameters:
请求参数：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 请求标识符：用于在代理上匹配相应请求和答复的代理唯一标识符。
reply-parameters (success):
答复参数（成功）：
- request identifier: An identifier matching the identifier of the request.
- 请求标识符：与请求标识符匹配的标识符。
- policy list: List of policy rule identifiers of all policy rules that the agent can access.
- 策略列表：代理可以访问的所有策略规则的策略规则标识符列表。
failure reason:
故障原因：
- transaction not supported - agent not authorized for this transaction
- 不支持事务-代理未为此事务授权
semantics:
语义：
The agent can use this transaction type to list all policies that it can access. Usually, the agent has this information already, but in special cases (for example, after an agent fail-over) or for special agents (for example, an administrating agent that can access all policies) this transaction can be helpful.
代理可以使用此事务类型列出它可以访问的所有策略。通常，代理已经具有此信息，但在特殊情况下（例如，代理故障转移后）或对于特殊代理（例如，可以访问所有策略的管理代理），此事务可能会有所帮助。
The middlebox first checks whether the agent is authorized to request this transaction. If the check fails, an appropriate failure reply is generated. Otherwise, a list of all policies the agent can access is returned indicating the identifier and the owner of each policy.
中间箱首先检查代理是否有权请求此交易。如果检查失败，将生成相应的失败回复。否则，将返回代理可以访问的所有策略的列表，指示每个策略的标识符和所有者。
This transaction does not have any effect on the policy rule state.
此事务对策略规则状态没有任何影响。
transaction-name: policy rule status
事务名称：策略规则状态
transaction-type: monitoring
事务类型：监视
transaction-compliance: mandatory
交易合规性：强制性
request-parameters:
请求参数：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 请求标识符：用于在代理上匹配相应请求和答复的代理唯一标识符。
- policy rule identifier: The middlebox-unique policy rule identifier.
- 策略规则标识符：中间盒唯一的策略规则标识符。
reply-parameters (success):
答复参数（成功）：
- request identifier: An identifier matching the identifier of the request.
- 请求标识符：与请求标识符匹配的标识符。
- policy rule owner: An identifier of the agent owning this policy rule.
- 策略规则所有者：拥有此策略规则的代理的标识符。
- group identifier: A reference to the group of which the policy rule is a member.
- 组标识符：对策略规则所属组的引用。
- policy rule action: This parameter has either the value 'reserve' or the value 'enable'.
- 策略规则操作：此参数的值为“reserve”或“enable”。
- transport protocol: Identifies the protocol for which a reservation is requested; see section 2.3.5.
- 传输协议：标识请求保留的协议；见第2.3.5节。
- port range: The number of consecutive port numbers; see section 2.3.5.
- 端口范围：连续端口号的数目；见第2.3.5节。
- direction: The direction of the communication enabled by the middlebox. Applicable only to policy enable rules.
- 方向：由中间盒启用的通信方向。仅适用于策略启用规则。
- internal IP address version: The version of the internal IP address (IP version of A0 in Figure 3).
- 内部IP地址版本：内部IP地址的版本（图3中A0的IP版本）。
- external IP address version: The version of the external IP address (IP version of A3 in Figure 3).
- 外部IP地址版本：外部IP地址的版本（图3中A3的IP版本）。
- internal IP address: The IP address of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部IP地址：内部通信端点的IP地址（图3中的A0）；见第2.3.5节。
- internal port number: The port number of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部端口号：内部通信端点的端口号（图3中的A0）；见第2.3.5节。
- external IP address: The IP address of the external communication endpoint (A3 in Figure 3); see section 2.3.5.
- 外部IP地址：外部通信端点的IP地址（图3中的A3）；见第2.3.5节。
- external port number: The port number of the external communication endpoint (A3 in Figure 3); see section 2.3.5.
- 外部端口号：外部通信端点的端口号（图3中的A3）；见第2.3.5节。
- inside interface (optional): The inside interface at the middlebox; see section 2.3.7.
- 内部接口（可选）：中间盒处的内部接口；见第2.3.7节。
- inside IP address: The internal IP address provided at the inside of the NAT (A1 in Figure 3); see section 2.3.5.
- 内部IP地址：NAT内部提供的内部IP地址（图3中的A1）；见第2.3.5节。
- inside port number: The internal port number provided at the inside of the NAT (A1 in Figure 3); see section 2.3.5.
- 内部端口号：NAT内部提供的内部端口号（图3中的A1）；见第2.3.5节。
- outside interface (optional): The outside interface at the middlebox; see section 2.3.7.
- 外部接口（可选）：中间盒处的外部接口；见第2.3.7节。
- outside IP address: The external IP address provided at the outside of the NAT (A2 in Figure 3); see section 2.3.5.
- 外部IP地址：NAT外部提供的外部IP地址（图3中的A2）；见第2.3.5节。
- outside port number: The external port number provided at the outside of the NAT (A2 in Figure 3); see section 2.3.5.
- 外部端口号：NAT外部提供的外部端口号（图3中的A2）；见第2.3.5节。
- port parity: The parity of the allocated ports.
- 端口奇偶校验：已分配端口的奇偶校验。
- service: The selected service in the case of mixed traditional and twice-NAT middlebox (see section 2.3.8).
- 服务：在混合传统和两次NAT中间盒的情况下选择的服务（见第2.3.8节）。
- policy rule lifetime: The remaining lifetime of the policy rule.
- 策略规则生存期：策略规则的剩余生存期。
failure reason:
故障原因：
- transaction not supported - agent not authorized for this transaction - no such policy rule - agent not authorized to access this policy rule
- 不支持事务-代理未为此事务授权-无此类策略规则-代理未授权访问此策略规则
semantics:
语义：
The agent can use this transaction type to list all properties of a policy rule. Usually, the agent has this information already, but in special cases (for example, after an agent fail-over) or for special agents (for example, an administrating agent that can access all policy rules) this transaction can be helpful.
代理可以使用此事务类型列出策略规则的所有属性。通常，代理已经具有此信息，但在特殊情况下（例如，代理故障转移后）或对于特殊代理（例如，可以访问所有策略规则的管理代理），此事务可能会有所帮助。
The middlebox first checks whether the specified policy rule exists and whether the agent is authorized to access this group. If one of the checks fails, an appropriate failure reply is generated. Otherwise, all properties of the policy rule are returned to the agent. Some of the returned parameters may be irrelevant, depending on the policy rule action ('reserve' or 'enable') and depending on other parameters -- for example, the protocol identifier.
中间盒首先检查指定的策略规则是否存在，以及代理是否有权访问此组。如果其中一项检查失败，将生成相应的失败回复。否则，策略规则的所有属性都将返回给代理。根据策略规则操作（“保留”或“启用”）和其他参数（例如，协议标识符），返回的一些参数可能不相关。
This transaction does not have any effect on the policy rule state.
此事务对策略规则状态没有任何影响。
transaction-name: asynchronous policy rule event
事务名称：异步策略规则事件
transaction-type: asynchronous
事务类型：异步
transaction-compliance: mandatory
交易合规性：强制性
notification message type: Policy Rule Event Notification (REN)
通知消息类型：策略规则事件通知（REN）
semantics:
语义：
The middlebox may decide at any point in time to terminate a policy rule. This transaction is triggered most frequently by lifetime expiration of the policy rule. Among other events that
中间箱可以在任何时间点决定终止策略规则。此事务最常由策略规则的生存期过期触发。在其他事件中
may cause this transaction are changes in the policy rule decision point.
策略规则决策点中的更改可能导致此事务。
The middlebox sends a REN message to all agents that participate in an open session with the middlebox and that are authorized to access the policy rule. The notification is sent to the agents before the middlebox changes the policy rule's lifetime. The change of lifetime may be triggered by any other authorized agent and results in shortening (lt_new < lt_existing), extending (lt_new > lt_existing), or terminating the policy rule (lt_new = 0).
中端箱向所有参与与中端箱的开放会话且有权访问策略规则的代理发送REN消息。在中间盒更改策略规则的生存期之前，会将通知发送给代理。生命周期的更改可能由任何其他授权代理触发，并导致缩短（lt_new<lt_existing）、扩展（lt_new>lt_existing）或终止策略规则（lt_new=0）。
The ARE transaction corresponds to the REN message handling described in section 2.3.4 for multiple agents.
ARE事务对应于第2.3.4节中描述的多个代理的REN消息处理。
The state machine for the policy rule transactions is shown in Figure 4 with all possible state transitions. The used transaction abbreviations may be found in the headings of the particular transaction section.
图4显示了策略规则事务的状态机以及所有可能的状态转换。使用的交易缩写可在特定交易章节的标题中找到。
PRR/success +---------------+
+-----------------+ PRID UNUSED |<-+
+----+ | +---------------+ |
| | | ^ | |
| v v | | |
| +-------------+ ARE | | PER/ | ARE
| | RESERVED +------------+ | success | RLC(lt=0)/
| +-+----+------+ RLC(lt=0)/ | | success
| | | success | |
+----+ | v |
RLC(lt>0)/ | PER/success +---------------+ |
success +---------------->| ENABLED +--+
+-+-------------+
| ^
lt = lifetime +-----------+
RLC(lt>0)/success
PRR/success +---------------+
+-----------------+ PRID UNUSED |<-+
+----+ | +---------------+ |
| | | ^ | |
| v v | | |
| +-------------+ ARE | | PER/ | ARE
| | RESERVED +------------+ | success | RLC(lt=0)/
| +-+----+------+ RLC(lt=0)/ | | success
| | | success | |
+----+ | v |
RLC(lt>0)/ | PER/success +---------------+ |
success +---------------->| ENABLED +--+
+-+-------------+
| ^
lt = lifetime +-----------+
RLC(lt>0)/success
Figure 4: Policy Rule State Machine
图4：策略规则状态机
This state machine exists per policy rule identifier (PRID). Initially, all policy rules are in state PRID UNUSED, which means that the policy rule does not exist or is not active. After returning to state PRID UNUSED, the policy rule identifier is no longer bound to an existing policy rule and may be reused by the middlebox.
此状态机根据策略规则标识符（PRID）存在。最初，所有策略规则都处于未使用状态PRID，这意味着该策略规则不存在或不处于活动状态。返回到PRID UNUSED状态后，策略规则标识符不再绑定到现有的策略规则，并且可以由中间盒重新使用。
A successful PRR transaction causes a transition from the initial state PRID UNUSED to the state RESERVED, where an address reservation is established. From there, state ENABLED can be entered by a PER transaction. This transaction can also be used for entering state ENABLED directly from state PRID UNUSED without a reservation. In state ENABLED, the requested communication between the internal and the external endpoint is enabled.
成功的PRR事务会导致从初始状态PRID UNUSED转换到状态REFERED，其中建立了地址保留。从那里，每个事务都可以输入启用状态。此事务还可用于直接从state PRID UNUSED无保留地输入state ENABLED。在启用状态下，将启用内部端点和外部端点之间请求的通信。
The states RESERVED and ENABLED can be maintained by successful RLC transactions with a requested lifetime greater than 0. Transitions from both of these states back to state PRID UNUSED can be caused by an ARE transaction or by a successful RLC transaction with a lifetime parameter of 0.
保留和启用的状态可以通过请求的生存期大于0的成功RLC事务来维护。从这两种状态转换回未使用状态PRID可能是由ARE事务或生存期参数为0的成功RLC事务引起的。
A failed request transaction does not change state at the middlebox.
失败的请求事务不会更改中间盒的状态。
Note that transitions initiated by RLC transactions may also be initiated by GLC transactions.
请注意，由RLC事务启动的转换也可以由GLC事务启动。
This section describes the semantics for transactions on groups of policy rules. These transactions are specified as follows:
本节描述策略规则组上事务的语义。这些交易规定如下：
- Group Lifetime Change (GLC) - Group List (GL) - Group Status (GS)
- 组生命周期更改（GLC）-组列表（GL）-组状态（GS）
All are request transactions initiated by the agent. GLC is a configuration transaction. GL and GS are monitoring transactions that do not have any effect on the group state machine.
所有都是由代理发起的请求事务。GLC是一个配置事务。GL和GS正在监视对组状态机没有任何影响的事务。
A policy rule group has only one attribute: the list of its members. All member policies of a single group must be owned by the same authenticated agent. Therefore, an implicit property of a group is its owner, which is the owner of the member policy rules.
策略规则组只有一个属性：其成员列表。单个组的所有成员策略必须由同一个经过身份验证的代理拥有。因此，组的隐式属性是其所有者，即成员策略规则的所有者。
A group is implicitly created when its first member policy rule is established. A group is implicitly terminated when the last remaining member policy rule is terminated. Consequently, the lifetime of a group is the maximum of the lifetimes of all member policy rules.
组在其第一个成员策略规则建立时隐式创建。当最后一个剩余成员策略规则终止时，组将隐式终止。因此，组的生存期是所有成员策略规则的最大生存期。
A group has a middlebox-unique identifier.
组具有中间盒唯一标识符。
Policy rule group transactions are declared as 'optional' by their respective compliance entry in section 3. However, they provide some functionalities, such as convenience for the agent in sending only one request instead of several, that is not available if only mandatory transactions are available.
策略规则组事务在第3节中通过其各自的合规性条目声明为“可选”。但是，它们提供了一些功能，例如方便代理只发送一个而不是多个请求，如果只有强制事务可用，则这些功能不可用。
The Group Lifetime Change (GLC) transaction is equivalent to simultaneously performed Policy Rule Lifetime Change (RLC) transactions on all members of the group. The result of a successful GLC transaction is that all member policy rules have the same lifetime. As with the RLC transaction, the GLC transaction can be used to delete all member policy rules by requesting a lifetime of zero.
组生存期更改（GLC）事务相当于对组的所有成员同时执行的策略规则生存期更改（RLC）事务。成功的GLC事务的结果是所有成员策略规则具有相同的生存期。与RLC事务一样，GLC事务可以通过请求零生存期来删除所有成员策略规则。
The monitoring transactions Group List (GL) and Group Status (GS) can be used by the agent to explore the state of the middlebox and to explore its access rights. The GL transaction lists all groups that the agent may access, including groups owned by other agents. The GS transaction reports the status on an individual group and lists all policy rules of this group by their policy rule identifiers. The agent can explore the state of the individual policy rules by using the policy rule identifiers in a policy rule status (PRS) transaction (see section 2.3.12).
代理可以使用监控事务组列表（GL）和组状态（GS）来查看中间箱的状态并查看其访问权限。总账事务列出了代理可以访问的所有组，包括其他代理拥有的组。GS事务报告单个组的状态，并按其策略规则标识符列出该组的所有策略规则。代理可以通过在策略规则状态（PRS）事务中使用策略规则标识符来探索各个策略规则的状态（请参见第2.3.12节）。
The GL and GS transactions are particularly helpful in case of an agent fail-over. The agent taking over the role of a failed one can use these transactions to retrieve whichever policies have been established by the failed agent.
总账和GS交易在代理故障转移的情况下特别有用。接管失败代理角色的代理可以使用这些事务检索失败代理已建立的策略。
Notifications on group events are generated analogously to policy rule events. To notify agents about group events, the Policy Rule Group Event Notification (GEN) message type is used. GEN messages contain an agent-unique notification identifier, the policy rule group identifier, and the remaining lifetime of the group.
组事件的通知生成方式与策略规则事件类似。要向代理通知组事件，请使用策略规则组事件通知（GEN）消息类型。GEN消息包含代理唯一通知标识符、策略规则组标识符和组的剩余生存期。
transaction-name: group lifetime change
事务名称：组生存期更改
transaction-type: configuration
事务类型：配置
transaction-compliance: optional
事务遵从性：可选
request-parameters:
请求参数：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 请求标识符：用于在代理上匹配相应请求和答复的代理唯一标识符。
- group identifier: A reference to the group for which the lifetime is requested to be changed.
- 组标识符：对请求更改其生存期的组的引用。
- group lifetime: The new lifetime proposal for the group.
- 组生存期：组的新生存期建议。
reply-parameters (success):
答复参数（成功）：
- request identifier: An identifier matching the identifier of the request.
- 请求标识符：与请求标识符匹配的标识符。
- group lifetime: The group lifetime granted by the middlebox.
- 组生存期：由中间盒授予的组生存期。
failure reason:
故障原因：
- transaction not supported - agent not authorized for this transaction - agent not authorized to change lifetime of this group - no such group - lifetime cannot be extended
- 不支持事务-代理未对此事务授权-代理未被授权更改此组的生存期-无此类组-生存期无法延长
notification message type: Policy Rule Group Event Notification (GEN)
通知消息类型：策略规则组事件通知（GEN）
semantics:
语义：
The agent can use this transaction type to request an extension of the lifetime of all members of a policy rule group, to request shortening the lifetime of all members, or to request termination of all member policies (which implies termination of the group). Termination is requested by suggesting a new group lifetime of zero.
代理可以使用此事务类型请求延长策略规则组的所有成员的生存期，请求缩短所有成员的生存期，或请求终止所有成员策略（这意味着组的终止）。通过建议新的组寿命为零来请求终止。
The middlebox first checks whether the specified group exists and whether the agent is authorized to access this group. If one of the checks fails, an appropriate failure reply is generated. If the requested lifetime is longer than the current one, the middlebox also checks whether the lifetime of the group may be extended and generates an appropriate failure message if it may not.
中间盒首先检查指定的组是否存在，以及代理是否有权访问此组。如果其中一项检查失败，将生成相应的失败回复。如果请求的生存期长于当前生存期，则中间盒还会检查组的生存期是否可以延长，如果不能延长，则会生成相应的失败消息。
A failure reply implies that the lifetime of the group remains unchanged. A success reply is generated by the middlebox if the lifetime of the group was changed in any way.
失败回复意味着组的生存期保持不变。如果组的生存期以任何方式发生了更改，则中间盒将生成一个成功回复。
The success reply contains the new common lifetime of all member policy rules of the group. The middlebox chooses the new lifetime less than or equal to the minimum of the requested lifetime and the maximum lifetime that the middlebox specified at session setup along with its other capabilities, i.e.,
成功回复包含组的所有成员策略规则的新公共生存期。中间盒选择的新生存期小于或等于请求生存期的最小值和中间盒在会话设置时指定的最大生存期及其其他功能，即。，
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
where - lt_granted is the lifetime actually granted by the middlebox - lt_requested is the lifetime the agent requested - lt_maximum is the maximum lifetime specified at session setup
其中，-lt_-grated是中间盒实际授予的生存期-lt_-requested是代理请求的生存期-lt_-maximum是会话设置中指定的最大生存期
After sending a success reply with a lifetime of zero, the middlebox will terminate the member policy rules without any further notification to the agent, and will consider the group and all of its members non-existent. Any further transaction on this policy rule group or on any of its members results in a negative reply, indicating that this group or policy rule, respectively, does not exist anymore.
在发送一个生命周期为零的成功答复后，MealBox将终止成员策略规则而不向代理进一步通知，并且将考虑该组及其所有成员不存在。此策略规则组或其任何成员上的任何进一步事务都将导致否定答复，这分别表示此组或策略规则不再存在。
After the remaining policy rule group lifetime is successfully changed and the reply message has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents participating in open sessions that can access the policy rule group. If the middlebox finds one or more of these agents, it sends a GEN message reporting the new remaining policy rule group lifetime to each of them.
成功更改剩余的策略规则组生存期并将答复消息发送给请求代理后，中间盒将检查是否有其他经过身份验证的代理参与可以访问策略规则组的打开会话。如果中间盒找到一个或多个代理，它将向每个代理发送一条GEN消息，报告新的剩余策略规则组生存期。
transaction-name: group list
事务名称：组列表
transaction-type: monitoring
事务类型：监视
transaction-compliance: optional
事务遵从性：可选
request-parameters:
请求参数：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 请求标识符：用于在代理上匹配相应请求和答复的代理唯一标识符。
reply-parameters (success):
答复参数（成功）：
- request identifier: An identifier matching the identifier of the request.
- 请求标识符：与请求标识符匹配的标识符。
- group list: List of all groups that the agent can access. For each listed group, the identifier and the owner are indicated.
- 组列表：代理可以访问的所有组的列表。对于列出的每个组，都会显示标识符和所有者。
failure reason:
故障原因：
- transaction not supported - agent not authorized for this transaction
- 不支持事务-代理未为此事务授权
semantics:
语义：
The agent can use this transaction type to list all groups that it can access. Usually, the agent has this information already, but in special cases (for example, after an agent fail-over) or for special agents (for example, an administrating agent that can access all groups) this transaction can be helpful.
代理可以使用此事务类型列出它可以访问的所有组。通常，代理已经具有此信息，但在特殊情况下（例如，代理故障转移后）或对于特殊代理（例如，可以访问所有组的管理代理），此事务可能会有所帮助。
The middlebox first checks whether the agent is authorized to request this transaction. If the check fails, an appropriate failure reply is generated. Otherwise a list of all groups the agent can access is returned indicating the identifier and the owner of each group.
中间箱首先检查代理是否有权请求此交易。如果检查失败，将生成相应的失败回复。否则，将返回代理可以访问的所有组的列表，指示每个组的标识符和所有者。
This transaction does not have any effect on the group state.
此事务对组状态没有任何影响。
transaction-name: group status
事务名称：组状态
transaction-type: monitoring
事务类型：监视
transaction-compliance: optional
事务遵从性：可选
request-parameters:
请求参数：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 请求标识符：用于在代理上匹配相应请求和答复的代理唯一标识符。
- group identifier: A reference to the group for which status information is requested.
- 组标识符：对请求状态信息的组的引用。
reply-parameters (success):
答复参数（成功）：
- request identifier: An identifier matching the identifier of the request.
- 请求标识符：与请求标识符匹配的标识符。
- group owner: An identifier of the agent owning this policy rule group.
- 组所有者：拥有此策略规则组的代理的标识符。
- group lifetime: The remaining lifetime of the group. This is the maximum of the remaining lifetimes of all members' policy rules.
- 组生存期：组的剩余生存期。这是所有成员的策略规则剩余生存期的最大值。
- member list: List of all policy rules that are members of the group. The policy rules are specified by their middlebox-unique policy rule identifier.
- 成员列表：作为组成员的所有策略规则的列表。策略规则由其中间盒唯一策略规则标识符指定。
failure reason:
故障原因：
- transaction not supported - agent not authorized for this transaction - no such group - agent not authorized to list members of this group
- 不支持事务-代理未为此事务授权-无此类组-代理未授权列出此组的成员
semantics:
语义：
The agent can use this transaction type to list all member policy rules of a group. Usually, the agent has this information already, but in special cases (for example, after an agent fail-over) or for special agents (for example, an administrating agent that can access all groups) this transaction can be helpful.
代理可以使用此事务类型列出组的所有成员策略规则。通常，代理已经具有此信息，但在特殊情况下（例如，代理故障转移后）或对于特殊代理（例如，可以访问所有组的管理代理），此事务可能会有所帮助。
The middlebox first checks whether the specified group exists and whether the agent is authorized to access this group. If one of the checks fails, an appropriate failure reply is generated. Otherwise, a list of all group members is returned indicating the identifier of each group.
中间盒首先检查指定的组是否存在，以及代理是否有权访问此组。如果其中一项检查失败，将生成相应的失败回复。否则，将返回所有组成员的列表，指示每个组的标识符。
This transaction does not have any effect on the group state.
此事务对组状态没有任何影响。
A protocol definition complies with the semantics defined in section 2 if the protocol specification includes all specified transactions with all their mandatory parameters. However, it is not required that an actual implementation of a middlebox supports all these transactions. Which transactions are required for compliance is different for agent and middlebox.
如果协议规范包括所有指定事务及其所有必需参数，则协议定义符合第2节中定义的语义。但是，并不要求中间盒的实际实现支持所有这些事务。对于代理商和中间商，合规性所需的交易是不同的。
This section contains conformance statements for MIDCOM protocol implementations related to the semantics. Conformance is specified differently for agents and middleboxes. These conformance statements will probably be extended by a concrete protocol specification. However, such an extension is expected to extend the statements below in such a way that all of them still hold.
本节包含与语义相关的MIDCOM协议实现的一致性声明。代理商和中间商的合规性规定不同。这些一致性声明可能会通过具体的协议规范进行扩展。然而，这样的扩展预计会以一种所有声明仍然有效的方式扩展以下声明。
The following list shows the transaction-compliance property of all transactions as specified in the previous section:
下表显示了上一节中指定的所有交易的交易符合性属性：
- Session Control Transactions - Session Establishment (SE) mandatory - Session Termination (ST) mandatory - Asynchronous Session Termination (AST) mandatory
- 会话控制事务-会话建立（SE）强制-会话终止（ST）强制-异步会话终止（AST）强制
- Policy Rule Transactions - Policy Reserve Rule (PRR) mandatory - Policy Enable Rule (PER) mandatory - Policy Rule Lifetime Change (RLC) mandatory - Policy Rule List (PRL) mandatory - Policy Rule Status (PRS) mandatory - Asynchronous Policy Rule Event (ARE) mandatory
- 策略规则事务-策略保留规则（PRR）强制-策略启用规则（PER）强制-策略规则生存期更改（RLC）强制-策略规则列表（PRL）强制-策略规则状态（PRS）强制-异步策略规则事件（ARE）强制
- Policy Rule Group Transactions - Group Lifetime Change (GLC) optional - Group List (GL) optional - Group Status (GS) optional
- 策略规则组事务-组生存期更改（GLC）可选-组列表（GL）可选-组状态（GS）可选
A compliant implementation of a MIDCOM protocol MUST support all mandatory transactions.
MIDCOM协议的兼容实现必须支持所有强制事务。
A compliant implementation of a MIDCOM protocol MAY support none, one, or more of the following transactions: GLC, GL, GS.
MIDCOM协议的兼容实现可能不支持、一个或多个以下事务：GLC、GL、GS。
A compliant implementation MAY extend the protocol semantics by further transactions.
兼容的实现可以通过进一步的事务扩展协议语义。
A compliant implementation of a MIDCOM protocol MUST support all mandatory parameters of each transaction concerning the information contained. The set of parameters can be redefined per transaction as long as the contained information is maintained.
MIDCOM协议的兼容实现必须支持与包含的信息有关的每个事务的所有必需参数。只要保留所包含的信息，就可以为每个事务重新定义参数集。
A compliant implementation of a MIDCOM protocol MAY support the use of interface-specific policy rules. Either both or neither of the optional inside and outside interface parameters in PRR, PER, and PRS MUST be included if interface-specific policy rules are supported.
MIDCOM协议的兼容实现可能支持使用特定于接口的策略规则。如果支持特定于接口的策略规则，则必须同时包含PRR、PER和PRS中的可选内部和外部接口参数或两者都不包含。
A compliant implementation MAY extend the list of parameters of transactions.
兼容的实现可以扩展事务的参数列表。
A compliant implementation MAY replace a single transaction by a set of more fine-grained transactions. In such a case, it MUST be ensured that requirement 2.1.4 (deterministic behavior) and requirement 2.1.5 (known and stable state) of [MDC-REQ] are still met. When a single transaction is replaced by a set of multiple fine-grained transactions, this set MUST be equivalent to a single transaction. Furthermore, this set of transactions MUST further meet the atomicity requirement stated in section 2.1.4.
兼容实现可以用一组更细粒度的事务替换单个事务。在这种情况下，必须确保[MDC-REQ]的要求2.1.4（确定性行为）和要求2.1.5（已知和稳定状态）仍然得到满足。当单个事务被一组多个细粒度事务替换时，此集合必须等效于单个事务。此外，这组事务必须进一步满足第2.1.4节中规定的原子性要求。
A middlebox implementation of a MIDCOM protocol supports a request transaction if it is able to receive and process all possible correct message instances of the particular request transaction and if it generates a correct reply for any correct request it receives.
如果MIDCOM协议的中间盒实现能够接收和处理特定请求事务的所有可能的正确消息实例，并且能够为其接收的任何正确请求生成正确的答复，则它支持请求事务。
A middlebox implementation of a MIDCOM protocol supports an asynchronous transaction if it is able to generate the corresponding notification message properly.
如果MIDCOM协议的中间盒实现能够正确生成相应的通知消息，则它支持异步事务。
A compliant middlebox implementation of a MIDCOM protocol must inform the agent about the list of supported transactions within the SE transaction.
MIDCOM协议的符合要求的中间盒实现必须将SE事务中支持的事务列表通知代理。
An agent implementation of a MIDCOM protocol supports a request transaction if it can generate the corresponding request message properly and if it can receive and process all possible correct replies to the particular request.
如果MIDCOM协议的代理实现能够正确生成相应的请求消息，并且能够接收和处理对特定请求的所有可能的正确回复，则它支持请求事务。
An agent implementation of a MIDCOM protocol supports an asynchronous transaction if it can receive and process all possible correct message instances of the particular transaction.
如果MIDCOM协议的代理实现可以接收和处理特定事务的所有可能的正确消息实例，则它支持异步事务。
A compliant agent implementation of a MIDCOM protocol must not use any optional transaction that is not supported by the middlebox. The middlebox informs the agent about the list of supported transactions within the SE transaction.
MIDCOM协议的兼容代理实现不得使用任何middlebox不支持的可选事务。中间盒将SE事务中支持的事务列表通知代理。
This section gives two usage examples of the transactions specified in section 2. The first shows how an agent can explore all policy rules and policy rule groups that it may access at a middlebox. The second example shows the configuration of a middlebox in combination with the setup of a voice over IP session with the Session Initiation Protocol (SIP) [RFC3261].
本节给出了第2节中指定的事务的两个使用示例。第一个演示了代理如何浏览它可以在中间箱访问的所有策略规则和策略规则组。第二个示例显示了结合会话发起协议（SIP）[RFC3261]的IP语音会话设置的中间盒配置。
This example assumes an already established session. It shows how an agent can find out
本例假定已建立会话。它显示了代理如何发现
- which groups it may access and who owns these groups, - the status and member list of all accessible groups, and - the status and properties of all accessible policy rules.
- 它可以访问哪些组以及谁拥有这些组，-所有可访问组的状态和成员列表，以及-所有可访问策略规则的状态和属性。
If there is just a single session, these actions are not needed, because the middlebox informs the agent about each state transition of any policy rule or policy rule group. However, after the disruption of a session or after an intentional session termination, the agent might want to re-establish the session and explore which of the groups and policy rules it established are still in place.
如果只有一个会话，则不需要执行这些操作，因为中间盒会将任何策略规则或策略规则组的每个状态转换通知代理。但是，在会话中断或有意终止会话后，代理可能希望重新建立会话，并探索它建立的哪些组和策略规则仍然存在。
Also, an agent system may fail and another one may take over. Then the new agent system needs to find out what has already been configured by the failing system and what still needs to be done.
此外，一个代理系统可能会失败，另一个可能会接管。然后，新的代理系统需要找出故障系统已经配置了什么以及还需要做什么。
A third situation where exploring policy rules and groups is useful is the case of an agent with 'administrator' authorization. This agent may access and modify any policy rule or group created by any other agent.
探索策略规则和组非常有用的第三种情况是具有“管理员”授权的代理。此代理可以访问和修改任何其他代理创建的任何策略规则或组。
All agents will probably start their exploration with the Group List (GL) transaction, as shown in Figure 5. On this request, the middlebox returns a list of pairs, each containing an agent identifier and a group identifier (GID). The agent is informed which of its own groups and which other agents' groups it may access.
所有代理可能都会从Group List（GL）事务开始探索，如图5所示。在该请求中，中间件返回一个对列表，每个对包含一个代理标识符和一个组标识符（GID）。将通知代理可以访问其自己的组和其他代理的组。
agent middlebox
| GL |
|**********************************************>|
|<**********************************************|
| (agent1,GID1) (agent1,GID2) (agent2,GID3) |
| |
| GS GID2 |
|**********************************************>|
|<**********************************************|
| agent1 lifetime PID1 PID2 PID3 PID4 |
| |
agent middlebox
| GL |
|**********************************************>|
|<**********************************************|
| (agent1,GID1) (agent1,GID2) (agent2,GID3) |
| |
| GS GID2 |
|**********************************************>|
|<**********************************************|
| agent1 lifetime PID1 PID2 PID3 PID4 |
| |
Figure 5: Using the GL and the GS Transactions
图5：使用总账和GS交易记录
In Figure 5, three groups are accessible to the agent, and the agent retrieves information about the second group by using the Group Status (GS) transaction. It receives the owner of the group, the remaining lifetime, and the list of member policy rules, in this case containing four policy rule identifiers (PIDs).
在图5中，代理可以访问三个组，并且代理通过使用group Status（GS）事务检索关于第二个组的信息。它接收组的所有者、剩余生存期和成员策略规则列表，在本例中包含四个策略规则标识符（PID）。
In the following, the agent explores these four policy rules. The example assumes that the middlebox is a traditional NAPT. Figure 6 shows the exploration of the first policy rule. In reply to a Policy Rule Status (PRS) transaction, the middlebox always returns the following list of parameters:
在下面，代理将探讨这四条策略规则。该示例假设中间盒是传统的NAPT。图6显示了对第一个策略规则的探索。作为对策略规则状态（PRS）事务的响应，中间盒始终返回以下参数列表：
- policy rule owner - group identifier - policy rule action (reserve or enable) - protocol type - port range - direction - internal IP address - internal port number - external address - external port number - middlebox inside IP address - middlebox inside port number - middlebox outside IP address - middlebox outside port number - IP address versions (not printed) - middlebox service (not printed) - inside and outside interface (optional, not printed)
- 策略规则所有者-组标识符-策略规则操作（保留或启用）-协议类型-端口范围-方向-内部IP地址-内部端口号-外部地址-外部端口号-中间盒内部IP地址-中间盒内部端口号-中间盒外部IP地址-中间盒外部端口号-IP地址版本（未打印）-中间盒服务（未打印）-内部和外部接口（可选，未打印）
agent middlebox
| PRS PID1 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 RESERVE UDP 1 "" |
| ANY ANY ANY ANY |
| ANY ANY IPADR_OUT PORT_OUT1 |
| |
agent middlebox
| PRS PID1 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 RESERVE UDP 1 "" |
| ANY ANY ANY ANY |
| ANY ANY IPADR_OUT PORT_OUT1 |
| |
Figure 6: Status Report for an Outside Reservation
图6：外部预订的状态报告
The 'ANY' parameter printed in Figure 6 is used as a placeholder in policy rule status replies for policy reserve rules. The policy rule with PID1 is a policy reserve rule for UDP traffic at the outside of the middlebox. Since this is a reserve rule, direction is empty. As there is no internal or external address involved yet, these four fields are wildcarded in the reply. The same holds for the inside middlebox address and port number. The only address information given by the reply is the reserved outside IP address of the middlebox (IPADR_OUT) and the corresponding port number (PORT_OUT1). Note that IPADR_OUT and PORT_OUT1 may not be wildcarded, as the reserve action does not support this.
图6中打印的“ANY”参数用作策略保留规则的策略规则状态回复中的占位符。带有PID1的策略规则是用于中间盒外部UDP通信的策略保留规则。因为这是一条保留规则，所以方向为空。由于还没有涉及内部或外部地址，因此这四个字段在回复中是通配符。内部中间盒地址和端口号也是如此。回复中给出的唯一地址信息是中间盒的保留外部IP地址（IPADR_OUT）和相应的端口号（port_OUT1）。请注意，IPADR_OUT和PORT_OUT1可能不是通配符，因为保留操作不支持这一点。
Applying PRS to PID2 (Figure 7) shows that the second policy rule is a policy enable rule for inbound UDP packets. The internal destination is fixed concerning IP address, protocol, and port number, but for the external source, the port number is wildcarded. The outside IP address and port number of the middlebox are what the external sender needs to use as destination in the original packet it sends. At the middlebox, the destination address is replaced with
将PRS应用于PID2（图7）显示第二个策略规则是入站UDP数据包的策略启用规则。关于IP地址、协议和端口号，内部目标是固定的，但是对于外部源，端口号是通配符。中间盒的外部IP地址和端口号是外部发送方需要在其发送的原始数据包中用作目的地的。在中间盒中，目标地址替换为
the internal address of the final receiver. During address translation, the source IP address and the source port numbers of the packets remain unchanged. This is indicated by the inside address, which is identical to the external address.
最终接收者的内部地址。在地址转换期间，数据包的源IP地址和源端口号保持不变。这由内部地址表示，与外部地址相同。
agent middlebox
| PRS PID2 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE UDP 1 IN |
| IPADR_INT PORT_INT1 IPADR_EXT ANY |
| IPADR_EXT ANY IPADR_OUT PORT_OUT2 |
| |
agent middlebox
| PRS PID2 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE UDP 1 IN |
| IPADR_INT PORT_INT1 IPADR_EXT ANY |
| IPADR_EXT ANY IPADR_OUT PORT_OUT2 |
| |
Figure 7: Status Report for Enabled Inbound Packets
图7：启用的入站数据包的状态报告
For traditional NATs, the identity of the inside IP address and port number with the external IP address and port number always holds (A1=A3 in Figure 3). For a pure firewall, the outside IP address and port number are always identical with the internal IP address and port number (A0=A2 in Figure 3).
对于传统NAT，内部IP地址和端口号与外部IP地址和端口号的标识始终保持不变（图3中的A1=A3）。对于纯防火墙，外部IP地址和端口号始终与内部IP地址和端口号相同（图3中的A0=A2）。
agent middlebox
| PRS PID3 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE UDP 1 OUT |
| IPADR_INT PORT_INT2 IPADR_EXT PORT_EXT1 |
| IPADR_EXT PORT_EXT1 IPADR_OUT PORT_OUT3 |
| |
agent middlebox
| PRS PID3 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE UDP 1 OUT |
| IPADR_INT PORT_INT2 IPADR_EXT PORT_EXT1 |
| IPADR_EXT PORT_EXT1 IPADR_OUT PORT_OUT3 |
| |
Figure 8: Status Report for Enabled Outbound Packets
图8：启用的出站数据包的状态报告
Figure 8 shows enabled outbound UDP communication between the same host. Here all port numbers are known. Since again A1=A3, the internal sender uses the external IP address and port number as destination in the original packets. At the firewall, the internal source IP address and port number are replaced by the shown outside IP address and port number of the middlebox.
图8显示了同一主机之间启用的出站UDP通信。这里所有的端口号都是已知的。由于A1=A3，内部发送方使用外部IP地址和端口号作为原始数据包中的目的地。在防火墙上，内部源IP地址和端口号将替换为显示的中间盒外部IP地址和端口号。
agent middlebox
| PRS PID4 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE TCP 1 BI |
| IPADR_INT PORT_INT3 IPADR_EXT PORT_EXT2 |
| IPADR_EXT PORT_EXT2 IPADR_OUT PORT_OUT4 |
| |
agent middlebox
| PRS PID4 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE TCP 1 BI |
| IPADR_INT PORT_INT3 IPADR_EXT PORT_EXT2 |
| IPADR_EXT PORT_EXT2 IPADR_OUT PORT_OUT4 |
| |
Figure 9: Status Report for Bidirectional TCP Traffic
图9：双向TCP流量的状态报告
Finally, Figure 9 shows the status report for enabled bidirectional TCP traffic. Note that, still, A1=A3. For outbound packets, only the source IP address and port number are replaced at the middlebox, and for inbound packets, only the destination IP address and port number are replaced.
最后，图9显示了启用的双向TCP流量的状态报告。注意，仍然是A1=A3。对于出站数据包，只有源IP地址和端口号在中间盒中被替换，而对于入站数据包，只有目标IP地址和端口号被替换。
This elaborated transaction usage example shows the interaction between a back-to-back user agent (B2BUA) and a middlebox. The middlebox itself is a traditional Network Address and Port Translator (NAPT), and two SIP user agents communicate with each other via the B2BUA and a NAPT, as shown in Figure 10. The MIDCOM agent is co-located with the B2BUA, and the MIDCOM server is at the middlebox. Thus, the MIDCOM protocol runs between the B2BUA and the middlebox.
这个详细的事务使用示例显示了背靠背用户代理（B2BUA）和中间箱之间的交互。中间盒本身是一个传统的网络地址和端口转换器（NAPT），两个SIP用户代理通过B2BUA和NAPT相互通信，如图10所示。MIDCOM代理与B2BUA位于同一位置，MIDCOM服务器位于中间箱。因此，MIDCOM协议在B2BUA和中间盒之间运行。
+-------------+
| B2BUA |
| for domain ++++
| example.com | +
+-------------+ +
^ ^ +
Private | | + Public Network
Network | | +
+----------+ | | +----+------+ +----------------+
| SIP User |<-+ +->| Middlebox |<------->| SIP User Agent |
| Agent A |<#######>| NAPT |<#######>| B@example.org |
+----------+ +-----------+ +----------------+
+-------------+
| B2BUA |
| for domain ++++
| example.com | +
+-------------+ +
^ ^ +
Private | | + Public Network
Network | | +
+----------+ | | +----+------+ +----------------+
| SIP User |<-+ +->| Middlebox |<------->| SIP User Agent |
| Agent A |<#######>| NAPT |<#######>| B@example.org |
+----------+ +-----------+ +----------------+
<--> SIP signaling
<##> RTP traffic
++++ MIDCOM protocol
<--> SIP signaling
<##> RTP traffic
++++ MIDCOM protocol
Figure 10: Example of a SIP Scenario
图10:SIP场景的示例
For the sequence charts below, we make these assumptions:
对于以下序列图，我们做出以下假设：
- The NAPT is statically configured to forward SIP signaling from the outside to the B2BUA -- i.e., traffic to the NAPT's external IP address and port 5060 is forwarded to the internal B2BUA.
- NAPT被静态地配置为将SIP信令从外部转发到B2BUA——即，将业务转发到NAPT的外部IP地址，并将端口5060转发到内部B2BUA。
- The SIP user agent A, located inside the private network, is registered at the B2BUA with its private IP address.
- 位于专用网络内的SIP用户代理A使用其专用IP地址在B2BUA处注册。
- User A knows the general SIP URL of user B. The URL is B@example.org. However, the concrete URL of the SIP user agent B, which user B currently uses, is not known.
- 用户A知道用户B的一般SIP URL。URL为B@example.org. 然而，用户B当前使用的SIP用户代理B的具体URL未知。
- The RTP paths are configured, but not the RTP Control Protocol (RTCP) paths.
- 已配置RTP路径，但未配置RTP控制协议（RTCP）路径。
- The middlebox and the B2BUA share an established MIDCOM session.
- 中间盒和B2BUA共享一个已建立的MIDCOM会话。
- Some parameters are omitted, such as the request identifier (RID).
- 省略了一些参数，例如请求标识符（RID）。
Furthermore, the following abbreviations are used:
此外，还使用了以下缩写：
- IP_AI: Internal IP address of user agent A - P_AI: Internal port number of user agent A to receive RTP data - P_AE: External mapped port number of user agent A - IP_AE: External IP address of the middlebox - IP_B: IP address of user agent B - P_B: Port number of user agent B to receive RTP data - GID: Group identifier - PID: Policy rule identifier
- IP_AI:用户代理A的内部IP地址-P_AI:接收RTP数据的用户代理A的内部端口号-P_AE:用户代理A的外部映射端口号-IP_AE:中间箱的外部IP地址-IP_B:用户代理B的IP地址-P_B:接收RTP数据的用户代理B的端口号-GID:组标识符-PID:策略规则标识符
The abbreviations of the MIDCOM transactions can be found in the particular section headings.
MIDCOM交易的缩写可在特定章节标题中找到。
In our example, user A tries to call user B. The user agent A sends an INVITE SIP message to the B2BUA (see Figure 10). The SDP part of the particular SIP message relevant for the middlebox configuration is shown in the sequence chart as follows:
在我们的示例中，用户A尝试呼叫用户B。用户代理A向B2BUA发送INVITE SIP消息（参见图10）。与中间箱配置相关的特定SIP消息的SDP部分在序列图中显示如下：
SDP: m=..P_AI.. c=IP_AI
SDP:m=…P_AI。。c=IP_AI
where the m tag is the media tag that contains the receiving UDP port number, and the c tag contains the IP address of the terminal receiving the media stream.
其中，m标记是包含接收UDP端口号的媒体标记，c标记包含接收媒体流的终端的IP地址。
The INVITE message forwarded to user agent B must contain a public IP address and a port number to which user agent B can send its RTP media stream. The B2BUA requests a policy enable rule at the middlebox with a PER request with the wildcarded IP address and port number of user agent B. As neither the IP address nor port numbers of user agent B are known at this point, the address of user agent B must be wildcarded. The wildcarded IP address and port number enable the 'early media' capability but result in some insecurity, as any outside host can reach user agent A on the enabled port number through the middlebox.
转发到用户代理B的INVITE消息必须包含一个公共IP地址和一个端口号，用户代理B可以将其RTP媒体流发送到该端口号。B2BUA在中间箱中请求一个策略启用规则，每个请求具有用户代理B的通配符IP地址和端口号。由于此时用户代理B的IP地址和端口号都未知，因此必须通配符用户代理B的地址。通配符IP地址和端口号启用了“早期媒体”功能，但会导致一些不安全因素，因为任何外部主机都可以通过中间盒在启用的端口号上与用户代理A联系。
User Agent B2BUA Middlebox User Agent
A NAPT B
| | | |
| INVITE | | |
| B@example.org | | |
| SDP:m=..P_AI.. | | |
| c=IP_AI | | |
|--------------->| | |
| | | |
| | PER PID1 UDP 1 EVEN IN | |
| | IP_AI P_AI ANY ANY 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID1 ANY ANY | |
| | IP_AE P_AE1 300s | |
User Agent B2BUA Middlebox User Agent
A NAPT B
| | | |
| INVITE | | |
| B@example.org | | |
| SDP:m=..P_AI.. | | |
| c=IP_AI | | |
|--------------->| | |
| | | |
| | PER PID1 UDP 1 EVEN IN | |
| | IP_AI P_AI ANY ANY 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID1 ANY ANY | |
| | IP_AE P_AE1 300s | |
Figure 11: PER with Wildcard Address and Port Number
图11：带有通配符地址和端口号的PER
A successful PER reply, as shown in Figure 11, results in a NAT binding at the middlebox. This binding enables UDP traffic from any host outside user agent A's private network to reach user agent A. So user agent B could start sending traffic immediately after receiving the INVITE message, as could any other host -- even hosts that are not intended to participate, such as any malicious host.
如图11所示，成功的每个回复将导致在中间盒处进行NAT绑定。此绑定允许来自用户代理A专用网络之外的任何主机的UDP通信到达用户代理A。因此，用户代理B可以在收到INVITE消息后立即开始发送通信，任何其他主机也可以，即使是不打算参与的主机，如任何恶意主机。
If the middlebox does not support or does not permit IP address wildcarding for security reasons, the PER request will be rejected with an appropriate failure reason, like 'IP wildcarding not supported'. Nevertheless, the B2BUA needs an outside IP address and port number at the middlebox (the NAPT) in order to forward the SIP INVITE message.
如果出于安全原因，中间盒不支持或不允许IP地址通配符，则将以适当的失败原因拒绝每个请求，如“不支持IP通配符”。然而，B2BUA需要在中间盒（NAPT）处提供外部IP地址和端口号，以便转发SIP INVITE消息。
If the IP address of user agent B is still not known (it will be sent by user agent B in the SIP reply message) and IP address wildcarding is not permitted, the B2BUA uses the PRR transaction.
如果用户代理B的IP地址仍然未知（将由用户代理B在SIP回复消息中发送），并且不允许IP地址通配符，B2BUA将使用PRR事务。
By using the PRR request, the B2BUA requests an outside IP address and port number (see Figure 12) without already establishing a NAT binding or pin hole. The PRR request contains the service parameter 'tw' -- i.e., the MIDCOM agent chooses the default value. In this configuration, with NAPT and without a twice-NAT, only an outside address is reserved. In the SDP payload of the INVITE message, the B2BUA replaces the IP address and port number of user agent A with the reserved IP address and port from the PRR reply (see Figure 12). The SIP INVITE message is forwarded to user agent B with a modified SDP body containing the outside address and port number, to which user agent B will send its RTP media stream.
通过使用PRR请求，B2BUA请求外部IP地址和端口号（见图12），而不必建立NAT绑定或引脚孔。PRR请求包含服务参数“tw”——即MIDCOM代理选择默认值。在这种配置中，使用NAPT和不使用两次NAT时，只保留一个外部地址。在INVITE消息的SDP有效负载中，B2BUA用PRR应答中的保留IP地址和端口替换用户代理A的IP地址和端口号（见图12）。SIP INVITE消息被转发到用户代理B，用户代理B将向用户代理B发送其RTP媒体流，该用户代理B具有修改后的SDP正文，其中包含外部地址和端口号。
User Agent B2BUA Middlebox User Agent
A NAPT B
| | | |
...PER in Figure 11 has failed, continuing with PRR ...
| | | |
| |PRR tw v4 v4 A UDP 1 EVEN 300s| |
| |*****************************>| |
| |<*****************************| |
| | PRR OK PID1 GID1 EMPTY | |
| | IP_AE/P_AE 300s | |
| | | |
| | INVITE B@example.org SDP:m=..P_AE.. c=IP_AE |
| |-------------------------------------------->|
| |<--------------------------------------------|
| | 200 OK SDP:m=..P_B.. c=IP_B |
User Agent B2BUA Middlebox User Agent
A NAPT B
| | | |
...PER in Figure 11 has failed, continuing with PRR ...
| | | |
| |PRR tw v4 v4 A UDP 1 EVEN 300s| |
| |*****************************>| |
| |<*****************************| |
| | PRR OK PID1 GID1 EMPTY | |
| | IP_AE/P_AE 300s | |
| | | |
| | INVITE B@example.org SDP:m=..P_AE.. c=IP_AE |
| |-------------------------------------------->|
| |<--------------------------------------------|
| | 200 OK SDP:m=..P_B.. c=IP_B |
Figure 12: Address Reservation with PRR Transaction
图12:PRR事务的地址预订
This SIP '200 OK' reply contains the IP address and port number at which user agent B will receive a media stream. The IP address is assumed to be equal to the IP address from which user agent B will send its media stream.
此SIP“200 OK”回复包含用户代理B将在其中接收媒体流的IP地址和端口号。假设IP地址等于用户代理B将从中发送其媒体流的IP地址。
Now, the B2BUA has sufficient information for establishing the complete NAT binding with a policy enable rule (PER) transaction; i.e., the UDP/RTP data of the call can flow from user agent B to user agent A. The PER transaction references the reservation by passing the PID of the PRR (PID1).
现在，B2BUA有足够的信息来建立具有策略启用规则（PER）事务的完整NAT绑定；i、 例如，调用的UDP/RTP数据可以从用户代理B流向用户代理A。每个事务通过传递PRR的PID（PID1）来引用保留。
For the opposite direction, UDP/RTP data from user agent A to B has to be enabled also. This is done by a second PER transaction with all the necessary parameters (see Figure 13). The request message contains the group identifier (GID1) the middlebox has assigned in the first PER transaction. Therefore, both policy rules have become
对于相反方向，还必须启用从用户代理A到B的UDP/RTP数据。这是通过每个事务一秒钟完成的，并带有所有必要的参数（参见图13）。请求消息包含中间盒在每个事务的第一个事务中分配的组标识符（GID1）。因此，这两项政策规则都变得非常重要
members of the same group. After having enabled both UDP/RTP streams, the B2BUA can forward the '200 OK' SIP message to user agent A to indicate that the telephone call can start.
同一组的成员。启用两个UDP/RTP流后，B2BUA可以将“200 OK”SIP消息转发给用户代理A，以指示电话呼叫可以开始。
User Agent B2BUA Middlebox User Agent
A NAPT B
| | | |
| | PER PID1 UDP 1 SAME IN | |
| | IP_AI P_AI IP_B ANY 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID1 IP_B ANY | |
| | IP_AE P_AE1 300s | |
| | | |
...media stream from user agent B to A enabled...
| | | |
| | PER GID1 UDP 1 SAME OUT | |
| | IP_AI ANY IP_B P_B 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID2 IP_B P_B | |
| | IP_AE P_AE2 300s | |
| | | |
...media streams from both directions enabled...
| | | |
| 200 OK | | |
|<---------------| | |
| SDP:m=..P_B.. | | |
| c=IP_B | | |
User Agent B2BUA Middlebox User Agent
A NAPT B
| | | |
| | PER PID1 UDP 1 SAME IN | |
| | IP_AI P_AI IP_B ANY 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID1 IP_B ANY | |
| | IP_AE P_AE1 300s | |
| | | |
...media stream from user agent B to A enabled...
| | | |
| | PER GID1 UDP 1 SAME OUT | |
| | IP_AI ANY IP_B P_B 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID2 IP_B P_B | |
| | IP_AE P_AE2 300s | |
| | | |
...media streams from both directions enabled...
| | | |
| 200 OK | | |
|<---------------| | |
| SDP:m=..P_B.. | | |
| c=IP_B | | |
Figure 13: Policy Rule Establishment for UDP Flows
图13：UDP流的策略规则建立
User agent B decides to terminate the call and sends its 'BYE' SIP message to user agent A. The B2BUA forwards all SIP messages and terminates the group afterwards, using a group lifetime change (GLC) transaction with a requested remaining lifetime of 0 seconds (see Figure 14). Termination of the group includes terminating all member policy rules.
用户代理B决定终止呼叫，并将其“再见”SIP消息发送给用户代理A。B2BUA转发所有SIP消息，然后使用请求的剩余生存期为0秒的组生存期更改（GLC）事务终止组（见图14）。终止组包括终止所有成员策略规则。
User Agent B2BUA Middlebox User Agent
A NAPT B
| | | |
| BYE | BYE |
|<---------------|<--------------------------------------------|
| | | |
| 200 OK | 200 OK |
|--------------->|-------------------------------------------->|
| | | |
| | GLC GID1 0s | |
| |*****************************>| |
| |<*****************************| |
| | GLC OK 0s | |
| | | |
...both NAT bindings for the media streams are removed...
User Agent B2BUA Middlebox User Agent
A NAPT B
| | | |
| BYE | BYE |
|<---------------|<--------------------------------------------|
| | | |
| 200 OK | 200 OK |
|--------------->|-------------------------------------------->|
| | | |
| | GLC GID1 0s | |
| |*****************************>| |
| |<*****************************| |
| | GLC OK 0s | |
| | | |
...both NAT bindings for the media streams are removed...
Figure 14: Termination of Policy Rule Groups
图14：策略规则组的终止
This section explains the compliance of the specified semantics with the MIDCOM requirements. It is structured according to [MDC-REQ]:
本节解释指定语义与MIDCOM要求的一致性。其结构符合[MDC-REQ]：
- Compliance with Protocol Machinery Requirements (section 5.1) - Compliance with Protocol Semantics Requirements (section 5.2) - Compliance with Security Requirements (section 5.3)
- 符合协议机械要求（第5.1节）-符合协议语义要求（第5.2节）-符合安全要求（第5.3节）
The requirements are referred to with the number of the section in which they are defined: "requirement x.y.z" refers to the requirement specified in section x.y.z of [MDC-REQ].
这些要求以其定义章节的编号表示：“要求x.y.z”是指[MDC-REQ]第x.y.z节中规定的要求。
The specified semantics enables a MIDCOM agent to establish an authorized association between itself and the middlebox. The agent identifies itself by the authentication mechanism of the Session Establishment transaction described in section 2.2.1. Based on this authentication, the middlebox can determine whether or not the agent will be permitted to request a service. Thus, requirement 2.1.1 is met.
指定的语义使MIDCOM代理能够在其自身和中间盒之间建立授权关联。代理通过第2.2.1节中描述的会话建立事务的身份验证机制来识别自己。基于此身份验证，中间盒可以确定是否允许代理请求服务。因此，满足要求2.1.1。
As specified in section 2.2, the MIDCOM protocol allows the agent to communicate with more than one middlebox simultaneously. The selection of a mechanism for separating different sessions is left to the concrete protocol definition. It must provide a clear mapping of protocol messages to open sessions. Then requirement 2.1.2 is met.
如第2.2节所述，MIDCOM协议允许代理同时与多个中间盒通信。分离不同会话的机制的选择取决于具体的协议定义。它必须提供协议消息到打开会话的清晰映射。则满足要求2.1.2。
As specified in section 2.2, the MIDCOM protocol allows the middlebox to communicate with more than one agent simultaneously. The selection of a mechanism for separating different sessions is left to the concrete protocol definition. It must provide a clear mapping of protocol messages to open sessions. Then requirement 2.1.3 is met.
如第2.2节所述，MIDCOM协议允许中间件同时与多个代理通信。分离不同会话的机制的选择取决于具体的协议定义。它必须提供协议消息到打开会话的清晰映射。则满足要求2.1.3。
Section 2.1.2 states that the processing of a request of an agent may not be interrupted by any request of the same or another agent. This provides atomicity among request transactions and avoids race conditions resulting in unpredictable behavior by the middlebox.
第2.1.2节规定，代理请求的处理不得被同一代理或另一代理的任何请求中断。这在请求事务之间提供了原子性，并避免了因竞争条件而导致中间盒的不可预测行为。
The behavior of the middlebox can only be predictable in the view of its administrators. In the view of an agent, the middlebox behavior is unpredictable, as the administrator can, for example, modify the authorization of the agent at any time without the agent being able to observe this change. Consequently, the behavior of the middlebox is not necessarily deterministic from the point of view of any agent.
中间盒的行为只能在其管理员的视图中预测。在代理的视图中，中间包行为是不可预测的，例如，管理员可以随时修改代理的授权，而代理无法观察此更改。因此，从任何代理的角度来看，中间箱的行为不一定是确定性的。
As predictability of the middlebox behavior is given for its administrator, requirement 2.1.4 is met.
由于为其管理员提供了中间盒行为的可预测性，因此满足了要求2.1.4。
Section 2.1 states that request transactions are atomic with respect to each other and from the point of view of an agent. All transactions are clearly defined as state transitions that either leave the current stable, well-defined state and enter a new stable, well-defined one or that remain in the current stable, well-defined state. Section 2.1 clearly demands that intermediate states are not stable and are not reported to any agent.
第2.1节指出，从代理的角度来看，请求事务相互之间是原子的。所有事务都明确定义为状态转换，要么离开当前稳定、定义良好的状态，进入新的稳定、定义良好的状态，要么保持当前稳定、定义良好的状态。第2.1节明确要求中间状态不稳定，不向任何代理报告。
Furthermore, for each state transition a message is sent to the corresponding agent, either a reply or a notification. The agent can uniquely map each reply to one of the requests that it sent to the middlebox, because agent-unique request identifiers are used for this purpose. Notifications are self-explanatory by their definition.
此外，对于每个状态转换，都会向相应的代理发送一条消息，即回复或通知。代理可以将每个回复唯一地映射到它发送到中间箱的一个请求，因为代理唯一的请求标识符用于此目的。通知的定义是不言自明的。
Furthermore, the Group List transaction (section 2.4.3), the Group Status transaction (section 2.4.4), the Policy Rule List transaction (section 2.3.11), and the Policy Rule Status transaction (section 2.3.12) allow the agent at any time during a session to retrieve information about
此外，组列表事务（第2.4.3节）、组状态事务（第2.4.4节）、策略规则列表事务（第2.3.11节）和策略规则状态事务（第2.3.12节）允许代理在会话期间的任何时候检索有关
- all policy rule groups it may access, - the status and member policy rules of all accessible groups, - all policy rules it may access, and - the status of all accessible policy rules.
- 它可以访问的所有策略规则组，-所有可访问组的状态和成员策略规则，-它可以访问的所有策略规则，以及-所有可访问策略规则的状态。
Therefore, the agent is precisely informed about the state of the middlebox (as far as the services requested by the agent are affected), and requirement 2.1.5 is met.
因此，可以准确地告知代理行中间箱的状态（只要代理行要求的服务受到影响），并满足要求2.1.5。
As argued in the previous section, the middlebox unambiguously informs the agent about every state transition related to any of the services requested by the agent. Also, at any time the agent can retrieve full status information about all accessible policy rules and policy rule groups. Thus, requirement 2.1.6 is met.
如前一节所述，中间箱会毫不含糊地通知代理与代理请求的任何服务相关的每个状态转换。此外，代理随时可以检索有关所有可访问策略规则和策略规则组的完整状态信息。因此，满足要求2.1.6。
The semantics includes asynchronous notifications messages from the middlebox to the agent, including the Session Termination Notification (STN) message, the Policy Rule Event Notification (REN) message, and the Group Event Notification (GEN) message (see section 2.1.2). These notifications report every change of state of policy rules or policy rule groups that was not explicitly requested by the agent. Thus, requirement 2.1.7 is met by the semantics specified above.
语义包括从中间件到代理的异步通知消息，包括会话终止通知（STN）消息、策略规则事件通知（REN）消息和组事件通知（GEN）消息（参见第2.1.2节）。这些通知报告代理未明确请求的策略规则或策略规则组状态的每次更改。因此，上述语义满足要求2.1.7。
As specified in section 2.2.1, the semantics requires mutual authentication of agent and middlebox, by using either two subsequent Session Establishment transactions or mutual authentication provided on a lower protocol layer. Thus, requirement 2.1.8 is met.
As specified in section 2.2.1, the semantics requires mutual authentication of agent and middlebox, by using either two subsequent Session Establishment transactions or mutual authentication provided on a lower protocol layer. Thus, requirement 2.1.8 is met.translate error, please retry
The semantics specification states in section 2.2.2 that the agent may request session termination by generating the Session Termination request and that the middlebox may not reject this request. In turn, section 2.2.3 states that the middlebox may send the Asynchronous
语义规范在第2.2.2节中规定，代理可以通过生成会话终止请求来请求会话终止，并且中间盒不能拒绝该请求。反过来，第2.2.3节规定，中间盒可以发送异步消息
Session Termination notification at any time and then terminate the session. Thus, requirement 2.1.9 is met.
随时发出会话终止通知，然后终止会话。因此，满足要求2.1.9。
Section 2.1 states that each request of an agent is followed by a reply of the middlebox indicating either success or failure. Thus, requirement 2.2.10 is met.
第2.1节规定，代理的每个请求之后都会有一个指示成功或失败的中间箱回复。因此，满足要求2.2.10。
Section 2.2.1 states that the agent needs to specify the protocol version number that it will use during the session. The middlebox may accept this and act according to this protocol version or may reject the session if it does not support this version. If the session setup is rejected, the agent may try again with another version. Thus, requirement 2.2.11 is met.
第2.2.1节指出，代理需要指定会话期间将使用的协议版本号。中间盒可以接受此协议并根据此协议版本进行操作，或者如果不支持此版本，则可以拒绝会话。如果会话设置被拒绝，代理可以使用其他版本重试。因此，满足要求2.2.11。
The only policy rule actions specified are 'reserve' and 'enable'. For firewalls, overlapping enable actions or reserve actions do not create any conflict, so a firewall will always accept overlapping rules as specified in section 2.3.2 (assuming the required authorization is given).
指定的唯一策略规则操作是“保留”和“启用”。对于防火墙，重叠的启用操作或保留操作不会产生任何冲突，因此防火墙将始终接受第2.3.2节中指定的重叠规则（假设已给出所需的授权）。
For NATs, reserve and enable may conflict. If a conflicting request arrives, it is rejected, as stated in section 2.3.2. If an overlapping request arrives that does not conflict with those it overlaps, it is accepted (assuming the required authorization is given).
对于NAT，保留和启用可能会冲突。如第2.3.2节所述，如果出现冲突请求，则该请求将被拒绝。如果到达的重叠请求与它重叠的请求不冲突，那么它将被接受（假设给出了所需的授权）。
Therefore, the behavior of the middlebox in the presence of overlapping rules can be predicted deterministically, and requirement 2.1.12 is met.
因此，在存在重叠规则的情况下，可以确定地预测中间箱的行为，并满足要求2.1.12。
Requirement 2.2.1 explicitly requests extensibility of protocol syntax. This needs to be addressed by the concrete protocol definition. The semantics specification is extensible anyway, because new transactions may be added.
要求2.2.1明确要求协议语法的可扩展性。这需要通过具体的协议定义来解决。语义规范无论如何都是可扩展的，因为可以添加新的事务。
Section 2.3 explains that the semantics uses identical transactions for all middlebox types and that the same policy rule can be applied to all of them. Thus, requirement 2.2.2 is met.
第2.3节解释了语义对所有中间包类型使用相同的事务，并且相同的策略规则可以应用于所有中间包类型。因此，满足要求2.2.2。
The semantics explicitly supports grouping of policy rules and transactions on policy rule groups, as described in section 2.4. The group transactions can be used for lifetime extension and termination of all policy rules that are members of the particular group. Thus, requirement 2.2.3 is met.
语义明确支持策略规则组上的策略规则和事务分组，如第2.4节所述。组事务可用于特定组成员的所有策略规则的生存期延长和终止。因此，满足要求2.2.3。
The semantics includes a transaction for explicit lifetime extension of policy rules, as described in section 2.3.3. Thus, requirement 2.2.4 is met.
语义包括用于策略规则显式生命周期扩展的事务，如第2.3.3节所述。因此，满足要求2.2.4。
The state transitions at the middlebox are clearly specified and communicated to the agent. There is no intermediate state reached by a partial processing of a request. All requests are always processed completely, either successfully or unsuccessfully. All request transactions include a list of failure reasons. These failure reasons cover indication of invalid parameters where applicable. In case of failure, one of the specified reasons is returned from the middlebox to the agent. Thus, requirement 2.2.5 is met.
明确指定了中间箱的状态转换，并将其传达给代理。请求的部分处理不会达到中间状态。所有请求都会被完全处理，无论成功与否。所有请求事务都包括一个失败原因列表。这些故障原因包括在适用情况下指示无效参数。如果失败，指定的原因之一将从中间箱返回给代理。因此，满足要求2.2.5。
The semantics includes a failure reason parameter in each failure reply. Thus, requirement 2.2.6 is met.
语义在每个失败回复中包含一个失败原因参数。因此，满足要求2.2.6。
As specified in sections 2.3 and 2.4, each installed policy rule and policy rule group has an owner, which is the authenticated agent that created the policy rule or group, respectively. The authenticated identity is input to authorize access to policy rules and groups.
如第2.3节和第2.4节所述，每个已安装的策略规则和策略规则组都有一个所有者，分别是创建策略规则或组的经过身份验证的代理。输入经过身份验证的标识以授权对策略规则和组的访问。
If the middlebox is sufficiently configurable, its administrator can configure it so that one authenticated agent is authorized to access and modify policy rules and groups owned by another agent. Because specified semantics does not preclude this, it meets requirement 2.2.7.
如果中间包具有足够的可配置性，则其管理员可以对其进行配置，以便授权一个经过身份验证的代理访问和修改另一个代理拥有的策略规则和组。因为指定的语义并不排除这一点，所以它符合要求2.2.7。
The Policy Enable Rule transaction specified in section 2.3.8 can carry 5-tuple filtering rules. This meets requirement 2.2.8.
第2.3.8节中指定的策略启用规则事务可以携带5元组过滤规则。这符合要求2.2.8。
As specified in section 2.3.6, the agent is able to request keeping the port parity when reserving port numbers with the PRR transaction (see section 2.3.8) and when establishing address bindings with the PER transaction (see section 2.3.9). Thus, requirement 2.2.9 is met.
如第2.3.6节所述，当为PRR事务保留端口号（见第2.3.8节）和为每个事务建立地址绑定（见第2.3.9节）时，代理可以请求保持端口奇偶校验。因此，满足要求2.2.9。
As specified in section 2.3.6, the agent is able to request a consecutive range of port numbers when reserving port numbers with the PRR transaction (see section 2.3.8) and when establishing address bindings or pinholes with the PER transaction (see section 2.3.9). Thus, requirement 2.2.10 is met.
如第2.3.6节所述，在PRR事务中保留端口号（见第2.3.8节）和在每个事务中建立地址绑定或针孔（见第2.3.9节）时，代理可以请求连续范围的端口号。因此，满足要求2.2.10。
Requirement 2.2.11 is based on the assumption that contradictory policy rule actions, such as 'enable'/'allow' and 'disable'/'disallow', are supported. In conformance with decisions made by the working group after finalizing the requirements document, this requirement is not met by the semantics because no 'disable'/'disallow' action is supported.
要求2.2.11基于以下假设，即支持相互矛盾的政策规则操作，如“启用”/“允许”和“禁用”/“不允许”。根据工作组在完成需求文档后做出的决定，语义不满足此需求，因为不支持“禁用”/“不允许”操作。
The semantics definition supports mutual authentication of agent and middlebox in the Session Establishment transaction (section 2.2.1). The use of an underlying protocol such as TLS or IPsec is mandatory. Thus, requirement 2.3.1 is met.
语义定义支持会话建立事务中代理和中间盒的相互身份验证（第2.2.1节）。必须使用底层协议，如TLS或IPsec。因此，满足要求2.3.1。
The use of IPsec or TLS allows agent and middlebox to use an encryption method (including no encryption). Thus, requirement 2.3.2 is met.
使用IPsec或TLS允许代理和中间盒使用加密方法（包括不加密）。因此，满足要求2.3.2。
Operation across untrusted domains is supported by mutual authentication and by the use of TLS or IPsec protection. Thus, requirement 2.3.3 is met.
相互身份验证以及TLS或IPsec保护的使用支持跨不受信任域的操作。因此，满足要求2.3.3。
The specified semantics mitigates replay attacks and meets requirement 2.3.4 by requiring mutual authentication of agent and middlebox, and by mandating the use of TLS or IPsec protection.
指定的语义通过要求代理和中间盒的相互身份验证，并通过强制使用TLS或IPsec保护，减轻重播攻击，并满足要求2.3.4。
Further mitigation can be provided as part of a concrete MIDCOM protocol definition -- for example, by requiring consecutively increasing numbers for request identifiers.
作为具体的MIDCOM协议定义的一部分，可以提供进一步的缓解措施——例如，要求连续增加请求标识符的数量。
The interaction between a middlebox and an agent (see [MDC-FRM]) is a very sensitive point with respect to security. The configuration of policy rules from a middlebox-external entity appears to contradict the nature of a middlebox. Therefore, effective means have to be used to ensure
中间盒和代理之间的交互（参见[MDC-FRM]）是安全性方面非常敏感的一点。来自中间箱外部实体的策略规则配置似乎与中间箱的性质相矛盾。因此，必须使用有效的手段来确保
- mutual authentication between agent and middlebox, - authorization, - message integrity, and - message confidentiality.
- 代理和中间包之间的相互身份验证、-授权、-消息完整性和-消息机密性。
The semantics defines a mechanism to ensure mutual authentication between agent and middlebox (see section 2.2.1). In combination with the authentication, the middlebox is able to decide whether an agent is authorized to request an action at the middlebox. The semantics relies on underlying protocols, such as TLS or IPsec, to maintain message integrity and confidentiality of the transferred data between both entities.
语义定义了一种机制，以确保代理和中间盒之间的相互身份验证（参见第2.2.1节）。结合身份验证，中间箱能够决定是否授权代理在中间箱请求操作。语义依赖于底层协议，如TLS或IPsec，以维护两个实体之间传输的数据的消息完整性和机密性。
For the TLS and IPsec use, both sides must use securely configured credentials for authentication and authorization.
对于TLS和IPsec的使用，双方都必须使用安全配置的凭据进行身份验证和授权。
The configuration of policy rules with wildcarded IP addresses and port numbers results in certain risks, such as opening overly wildcarded policy rules. An excessively wildcarded policy rule would be A0 and A3 with IP address set to 'any' IP address, for instance. This type of pinhole would render the middlebox, in the sense of security, useless, as any packet could traverse the middlebox without further checking. The local policy of the middlebox should reject such policy rule enable requests.
使用通配符IP地址和端口号配置策略规则会导致某些风险，例如打开过度通配符的策略规则。例如，过度通配符策略规则将是A0和A3，IP地址设置为“任意”IP地址。这种类型的针孔会使中间盒在安全性方面变得无用，因为任何数据包都可以在不进行进一步检查的情况下穿过中间盒。中间盒的本地策略应拒绝此类策略规则启用请求。
A reasonable default configuration for wildcarding would be that only one port number may be wildcarded and all IP addresses must be set without wildcarding. However, there are some cases where security needs to be balanced with functionality.
通配符的合理默认配置是，只能对一个端口号进行通配符，并且必须在不进行通配符的情况下设置所有IP地址。但是，在某些情况下，安全性需要与功能性相平衡。
The example described in section 4.2 shows how SIP-signaled calls can be served in a secure way without wildcarding IP addresses. But some SIP-signaled applications make use of early media (see section 5.5 of [RFC3398]). To receive early media, the middleboxes need to be configured before the second participant in a session is known. As it is not known, the IP address of the second participant needs to be wildcarded.
第4.2节中描述的示例说明了如何在不通配符IP地址的情况下以安全的方式为SIP信号呼叫提供服务。但一些SIP信号应用程序使用早期媒体（见[RFC3398]第5.5节）。要接收早期媒体，需要先配置中间盒，然后才能知道会话中的第二个参与者。由于未知，第二个参与者的IP地址需要通配符。
In such cases and in several similar ones, there is a security policy decision to be made by the middlebox operator. The operator can configure the middlebox so that it supports more functionality, for example, by allowing wildcarded IP addresses, or so that network operation is more secure, for example, by disallowing wildcarded IP addresses.
在这种情况下，以及在一些类似的情况下，中间箱运营商需要做出安全策略决策。运营商可以配置中间箱，使其支持更多功能，例如，允许使用通配符IP地址，或使网络操作更安全，例如，不允许使用通配符IP地址。
UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a process at originating endpoints that attempt to determine or fix the address (and port) by which they are known to another endpoint. UNSAF proposals, such as Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489], are considered as a general class of workarounds for NAT traversal and as solutions for scenarios with no middlebox communication (MIDCOM).
[RFC3424]将单边自地址修复（UNSAF）描述为原始端点处的一个过程，试图确定或修复另一个端点已知的地址（和端口）。UNSAF建议，例如通过NAT（STUN）[RFC3489]简单遍历UDP协议，被视为NAT遍历的一般解决方案，也被视为无中间箱通信（MIDCOM）情况下的解决方案。
This document describes the protocol semantics for such a middlebox communication (MIDCOM) solution. MIDCOM is not intended as a short-term workaround, but more as a long-term solution for middlebox communication. In MIDCOM, endpoints are not involved in allocating, maintaining, and deleting addresses and ports at the middlebox. The full control of addresses and ports at the middlebox is located at the MIDCOM server.
本文档描述了这种中间箱通信（MIDCOM）解决方案的协议语义。MIDCOM并不是一个短期的解决方案，而是一个用于中端通讯的长期解决方案。在MIDCOM中，端点不参与在中间盒中分配、维护和删除地址和端口。在MIDCOM服务器上可以完全控制中间盒的地址和端口。
Therefore, this document addresses the UNSAF considerations in [RFC3424] by proposing a long-term alternative solution.
因此，本文件通过提出长期替代解决方案，解决了[RFC3424]中的UNSAF考虑事项。
We would like to thank all the people contributing to the semantics discussion on the mailing list for a lot of valuable comments.
我们要感谢所有参与邮件列表上语义学讨论的人，他们提供了很多有价值的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MDC-FRM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[MDC-FRM]Srisuresh，P.，Kuthan，J.，Rosenberg，J.，Molitor，A.，和A.Rayhan，“中间箱通信架构和框架”，RFC 3303，2002年8月。
[MDC-REQ] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002.
[MDC-REQ]Swale，R.，Mart，P.，Sijben，P.，Brim，S.，和M.Shore，“中间箱通信（midcom）协议要求”，RFC 33042002年8月。
[MDC-SEM] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communications (MIDCOM) Protocol Semantics", RFC 3989, February 2005.
[MDC-SEM]Stieemerling，M.，Quittek，J.，和T.Taylor，“中间盒通信（MIDCOM）协议语义”，RFC 3989，2005年2月。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-TRAD]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[RFC3198]威斯特林，A.，施尼兹莱因，J.，斯特拉斯纳，J.，舍林，M.，奎因，B.，赫尔佐格，S.，休恩，A.，卡尔森，M.，佩里，J.，和S.瓦尔德布瑟，“基于政策的管理术语”，RFC 3198，2001年11月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[RFC3398]Camarillo，G.，Roach，A.，Peterson，J.，和L.Ong，“综合业务数字网（ISDN）用户部分（ISUP）到会话发起协议（SIP）的映射”，RFC 3398，2002年12月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
1. The example in section 4.2 used a SIP proxy server modifying the body of a SIP message. This was a violation of RFC 3261. This has been fixed by replacing the SIP proxy server with a back-to-back user agent.
1. 第4.2节中的示例使用SIP代理服务器修改SIP消息体。这违反了RFC 3261。通过使用背对背的用户代理替换SIP代理服务器，解决了这一问题。
2. Clarifications concerning the used set of transaction types have been added.
2. 已添加关于所用交易类型集的说明。
3. Section 3.1, "General Implementation Conformance", now uses key words from RFC 2119.
3. 第3.1节“一般实施一致性”现在使用RFC 2119中的关键词。
4. Minor editorial changes have been made and references have been updated.
4. 编辑上做了一些小改动，参考文献也进行了更新。
Authors' Addresses
作者地址
Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
Martin Stieemerling NEC欧洲有限公司Kurfuersten Anlage 36 69115德国海德堡
Phone: +49 6221 4342-113
EMail: stiemerling@nw.neclab.eu
Phone: +49 6221 4342-113
EMail: stiemerling@nw.neclab.eu
Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
德国海德堡Juergen Quittek NEC欧洲有限公司Kurfuersten Anlage 36 69115
Phone: +49 6221 4342-115
EMail: quittek@nw.neclab.eu
Phone: +49 6221 4342-115
EMail: quittek@nw.neclab.eu
Tom Taylor Nortel 1852 Lorraine Ave. Ottawa, Ontario Canada K1H 6Z8
汤姆·泰勒北电1852加拿大安大略省渥太华洛林大道K1H 6Z8
Phone: +1 613 763 1496
EMail: tom.taylor@rogers.com
Phone: +1 613 763 1496
EMail: tom.taylor@rogers.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.