- 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.
2.3.13. Asynchronous Policy Rule Event (ARE)
transaction-name: asynchronous policy rule event
transaction-type: notification
transaction-compliance: mandatory
notification message type: Policy Rule Event Notification (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 an 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).
The ARE transaction corresponds to the REN message handling described
in section 2.3.4 for multiple agents.
2.3.14. Policy Rule State Machine
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.
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
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.
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.
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.
A failed request transactions does not change state at the middlebox.
Note that transitions initiated by RLC transactions may also be
initiated by GLC transactions.
2.4. Policy Rule Group Transactions
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)
All are request transactions initiated by the agent. GLC is a
convenience transaction. GL and GS are monitoring transactions that
do not have any effect on the group state machine.
2.4.1. Overview
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.
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.
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.
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).
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 retrieve whichever policies have been
established by the failed agent.
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.
2.4.2. Group Lifetime Change (GLC)
transaction-name: group lifetime change
transaction-type: convenience
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)
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)
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
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.
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.
2.4.3. Group List (GL)
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.
2.4.4. Group Status (GS)
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 lifetime 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.
3. Conformance Statements
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, concrete
implementations of the protocol may support only some of the optional
transactions, not all of them. Which transactions are required for
compliance is different for agent and middlebox.
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.
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
- 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
- Policy Rule Group Transactions
- Group Lifetime Change (GLC) optional
- Group List (GL) optional
- Group Status (GS) optional
3.1. General Implementation Conformance
A compliant implementation of a MIDCOM protocol must support all
mandatory transactions.
A compliant implementation of a MIDCOM protocol may support none,
one, or more of the following transactions: 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.
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 when interface-specific policy rules are supported.
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.3.
3.2. Middlebox Conformance
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.
A middlebox implementation of a MIDCOM protocol supports an
asynchronous transaction if it is able to generate the corresponding
notification message properly.
A compliant middlebox implementation of a MIDCOM protocol must inform
the agent about the list of supported transactions within the SE
transaction.
3.3. Agent Conformance
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.
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.
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.
4. Transaction Usage Examples
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].
4.1. Exploring Policy Rules and Policy Rule Groups
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.
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 transaction
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).
In the following, the agent explores these four policy rules. The