draft-ietf-rsvp-policy-oops-00.txt   draft-ietf-rsvp-policy-oops-01.txt 
Internet Draft Shai Herzog Internet Draft Shai Herzog
Expiration: Oct. 1997 Dimitrios Pendarakis Expiration: Oct. 1997 IPHighway
File: draft-ietf-rsvp-policy-oops-00.txt Raju Rajan File: draft-ietf-rsvp-policy-oops-01.txt
Dimitrios Pendarakis
Raju Rajan
Roch Guerin Roch Guerin
IBM T.J. Watson Research Center IBM T.J. Watson Research Center
Apr. 1997
Open Outsourcing Policy Service (OOPS) for RSVP Open Outsourcing Policy Service (OOPS) for RSVP
03/19/97 07/30/97
Status of Memo Status of Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Rim). Rim).
Abstract Abstract
This document describes a protocol for exchanging policy information This document describes a protocol for exchanging policy information
and decisions between an RSVP-capable router (client) and a policy and decisions between an RSVP-capable router (client) and a policy
server. The OOPS protocol supports a wide range of router server. The OOPS protocol supports a wide range of router
configurations and RSVP implementations, and is compatible with the configurations and RSVP implementations, and is compatible with the
RSVP Extensions for Policy Control [Ext]. RSVP Extensions for Policy Control [Ext].
Internet Draft OOPS: Policy Protocol for RSVP 1. Overview Reservation protocols function by discriminating between
users by providing some users with better service at the expense of
Table of Contents others. The utility of reservation protocols is sharply degraded in
the absence of mechanisms for restricting access to higher service
1 Overview 4 categories and enforcing network and bandwidth usage criteria. In
this document, we refer to such mechanisms as "policy control". This
1.1 Representative OOPS Scenarios .......................... 4 term is quite broad; it ranges from simple access control to
sophisticated accounting and debiting mechanisms.
2 Query-Response Protocol 6
2.1 Division of Labor between Client and Server ............ 6
2.1.1 Error Reporting ................................. 7
2.2 State Management ...................................... 8
2.2.1 Client State Information Cached at Server ........ 9
2.2.2 Server State Information Cached at Client ........ 9
2.2.3 State Change Notification ........................ 10
3 Client-Server Communications 10
3.1 Connection Establishment .............................. 10
3.1.1 Secure Communications ............................ 11
3.2 Reliable Communication ................................. 11
3.2.1 Sequence Numbers ................................ 12
3.2.2 Receiver initiated retransmit .................... 12
3.2.3 Keep-Alive Messages ............................. 12
3.2.4 Overhead ........................................ 13
3.3 Connection Termination ................................ 13
3.3.1 Explicit Termination ............................ 13
3.3.2 Implicit Termination ............................ 13
3.3.3 Post Termination ................................. 14
3.3.4 Switching to An Alternative Server .............. 14
4 OOPS Message Format 15
Internet Draft OOPS: Policy Protocol for RSVP
4.1 OOPS Operations ....................................... 16
4.1.1 Null-Notification (a.k.a Keep-Alive) ............. 17
4.1.2 Connection-Initiation-Query ..................... 17
4.1.3 Connection-Accept-Response ...................... 17
4.1.4 Connection-Reject-Response ...................... 18
4.1.5 Bye-Notification ................................ 18
4.1.6 Incoming-Policy-Query ........................... 18
4.1.7 Incoming-Policy-Response ........................ 19
4.1.8 Outgoing-Policy-Query ........................... 19
4.1.9 Outgoing-Policy-Response ........................ 19
4.1.10 Status-Query ................................... 20
4.1.11 Status-Response ................................ 20
4.1.12 Delete-State-Notification ...................... 21
4.1.13 Schedule-RSVP-Notification ..................... 21
4.1.14 Client-Status-Notification ..................... 22
4.1.15 Resend-Notification ............................ 22
4.1.16 Error-Notification ............................. 22
4.2 Fields format ......................................... 23
5 Acknowledgment 25
Internet Draft OOPS: Policy Protocol for RSVP
1. Overview
Open Outsourcing Policy Service (OOPS) is a protocol for exchanging The policy control component may reside fully within the router (as
policy information and decisions between an RSVP-capable router an add-on module to RSVP). However, it is often advantageous for
(client) and a policy server. As the name suggests, OOPS is an routers to outsource some of their policy decision making to external
outsourcing protocol which allows the partial or complete delegation entities. Open Outsourcing Policy Service (OOPS) is a protocol for
of the task of policy control from the local router to an external exchanging policy information and decisions between Local Policy
server. Moreover, it is an open protocol in a sense that it does not Modules (LPMs) located within RSVP-capable routers and one or more
define or depend on particular policies; instead, it provides a external policy servers. OOPS is an open protocol in a sense that it
framework for adding, modifying and experimenting with new policies does not define or depend on particular policies; instead, it
in a modular, plug-n-play fashion. provides a framework for adding, modifying and experimenting with new
policies in a modular, plug-n-play fashion. Moreover, the OOPS
protocol supports both partial and complete delegation of policy
control.
The OOPS protocol was designed to be compatible with the RSVP The OOPS protocol was designed to be compatible with the RSVP
Extensions for Policy Control [Ext], both in the format of RSVP Extensions for Policy Control [Ext], both in the format of RSVP
objects, as well as the set of supported services. objects, as well as the set of supported services.
The basic features of OOPS design are as follows: The basic features of OOPS are as follows:
Asymmetry between client and server Asymmetry between client and server
Adding policy support to RSVP may require substantial Adding policy support to RSVP may require substantial
modifications to platforms (e.g., routers) which may not have modifications to platforms (e.g., routers) which may not have
the required implementation flexibility and/or processing power. the required implementation flexibility and/or processing power.
OOPS assumes that the server is more sophisticated than the OOPS assumes that the server is more sophisticated than the
client, in terms of processing power and support for diverse client, in terms of processing power and support for diverse
policies. policies.
Support for a wide range of client implementation Support for a wide range of client implementation
The OOPS protocol supports a wide range of client The OOPS protocol supports a wide range of client
implementations. At one end of the spectrum, a "dumb" client implementations. At one end of the spectrum, a "dumb" client
may delegate total responsibility to the server for all policy may delegate total responsibility to the server for all policy
decisions without even maintaining cached states. At the other decisions without even maintaining cached states. At the other
end, smart clients can perform most policy processing locally end, smart clients can perform most policy processing locally
and only address the server for a small number of policies and and only address the server for a small number of sub-policy
only when they change (otherwise, cache can be used). elements and only when things change (otherwise, cache can be
used).
Support for different policy interfaces
The OOPS protocol allows clients and servers to negotiate the
nature and sophistication of their interaction. For instance,
responses from the server to the client may be restricted to
allow the server to merely accept, deny or remain neutral on
reservation requests, while a more sophisticated implementation
may allow the server to respond with preemption priorities or
other characteristics of the reservation. The negotiation
handshake is simple, and may always fall back onto the lowest
level of interaction that must always be supported.
Minimal knowledge of RSVP's processing rules. Minimal knowledge of RSVP's processing rules.
The server must be aware of the format of several RSVP objects The server must be aware of the format of several RSVP objects
and basic RSVP message types. However, it is not required to and basic RSVP message types. However, it is not required to
understand RSVP's processing rules (e.g., different reservation understand RSVP's processing rules (e.g., different reservation
styles). styles). Moreover, OOPS functionality is not tied to that of
RSVP, and OOPS may be extended to be used by other, non-RSVP,
connection setup protocols.
Asynchronicity Asynchronicity
Both client and server may asynchronously generate queries or Both client and server may asynchronously generate queries or
requests. requests.
Internet Draft OOPS: Policy Protocol for RSVP
TCP for reliable communications TCP for reliable communications
TCP is used as a reliable communication protocol between client TCP is used as a reliable communication protocol between client
and server. and server.
1.1 Representative OOPS Scenarios 1.1 Glossary
Policy
Comprehensive set of rules for controlling some aspects of
the network.
Sub-policies
Modular building blocks out of which comprehensive policies
are compiled.
POLICY_DESC
Data representation of policy information (e.g., POLICY_DATA
objects in RSVP).
Sub-policy element
Data representation of sub-policy information, as
encapsulated in POLICY_DESC objects.
1.2 Representative OOPS Scenarios
Figure 1 depicts some representative scenarios for policy control Figure 1 depicts some representative scenarios for policy control
along an RSVP path, as envisioned in OOPS. Nodes A, B and C along an RSVP path, as envisioned in OOPS. Nodes A, B and C
belong to one administrative domain AD-1 (advised by policy server belong to one administrative domain AD-1 (advised by policy server
PS-1), while D and E belong to AD-2 and AD-3, respectively. PS-1), while D and E belong to AD-2 and AD-3, respectively.
AD-1 AD-2 AD-3 AD-1 AD-2 AD-3
_______________/\___________ __/\__ __/\__ _______________/\___________ __/\__ __/\__
{ } { } { } { } { } { }
skipping to change at page 5, line 43 skipping to change at page 5, line 29
\ / | PS-2 | \ / | PS-2 |
\ / +------+ \ / +------+
+------+ +------+
|Policy| |Policy|
|Server| |Server|
| PS-1 | | PS-1 |
+------+ +------+
Figure 1: Policy Control along an RSVP path Figure 1: Policy Control along an RSVP path
The scenario includes four typical node types: Policy objects are carried in RSVP messages along the path
consisting of four typical node types:
(1) Policy incapable nodes: Node B. (2) Self-sufficient policy (1) Policy incapable nodes: Node B. (2) Self-sufficient policy
node: Node D is self-sufficient since its local LPM satisfies its node: Node D does not need to outsource policy tasks to external
entire policy needs. (It has no need for server advice.) (3) servers since its LPM satisfies its entire policy needs. (3)
"Dumb" policy nodes: Node E is an unsophisticated node that lacks "Dumb" policy nodes: Node E is an unsophisticated node that lacks
processing power, code support or caching capabilities, and needs processing power, code support or caching capabilities, and needs
to rely on PS-2 for every policy processing operation. In this to rely on PS-2 for every policy processing operation. In this
case, the volume of traffic and delay requirements make it case, the volume of traffic and delay requirements make it
imperative to connect Node E to PS-2 a direct link or a LAN. (4)
Internet Draft OOPS: Policy Protocol for RSVP "Smart" policy nodes: Nodes A and C include sophisticated LPMs,
in that these nodes can process some sub-policy elements, and have
imperative to connect PS-2 to node E by a direct link or a LAN. the capacity to cache responses from PS-1. In this case, the
(4) "Smart" policy nodes: Nodes A and C include sophisticated contact between the clients and server would be limited to
LPMs, in that these nodes can process some policies, and have the occasional updates, and PS-1 could be located somewhere in AD-1.
capacity to cache responses from PS-1. In this case, the contact
between the clients and server will be limited to occasional
updates, and PS-1 could be located somewhere in AD-1.
Consider the case where the receiver R1 sends a Resv message Consider the case where the receiver R1 sends a Resv message
upstream toward sender S1. Assuming that the reservation is upstream toward sender S1. Assuming that the reservation is
successful, the conceptual flow of policy objects is: successful, the conceptual flow of policy objects is:
R1 -- E -- ELPM -- PS-2 -- ELPM -- E -- D -- DLPM -- D -- C -- CLPM R1 -- E -- ELPM -- PS-2 -- ELPM -- E -- D -- DLPM -- D -- C -- CLPM
-- PS-1 -- CLPM -- C -- B -- A -- ALPM -- PS-1 -- ALPM -- A -- S1. -- PS-1 -- CLPM -- C -- B -- A -- ALPM -- PS-1 -- ALPM -- A -- S1.
Of course, other OOPS messages may be exchanged between policy Of course, other OOPS messages may be exchanged between policy
servers and nodes before authorizing the reservation at individual servers and nodes before authorizing the reservation at individual
nodes. nodes.
2. Query-Response Protocol The functioning of the policy module at a policy aware router is
presented through the following conceptual diagram.
+---------+ +----------+
| RSVP | | Policy |
| Module | | Server |
+---------+ OOPS | |
| LPM |---------| |
+- - - - -+ +----------+
|PSM| |PSM| |PSM| |PSM|
|___| |___| |___| |___|
Figure 2: Local Policy Modules and Policy Server communications
The policy server and the local policy module provide support for
a number of sub-policy elements, each embodied by a policy sub-
module (PSM). The policy object forwarded by RSVP may contain a
number of elements, each identified by a number, and hence
destined to the sub-module that enforces that sub-policy element's
number. For instance, some of these sub-objects may deal with
authentication, others with security, accounting and so on. The
LPM is aware of the sub-modules it is capable of processing
locally; After the handshake comes to know the set of sub-policies
that are supported by the server. Processing of policy sub-objects
can be split between the LPM and the policy server, and responses
may be merged back before returning a unified response to RSVP.
2. OOPS Protocol: Basic Features
OOPS is a transaction protocol, in which most communication is in the OOPS is a transaction protocol, in which most communication is in the
form of queries from the client followed by responses from the form of queries from the client followed by responses from the
server. However, a small portion of the communication may also server. However, a small portion of the communication may also
consist of queries originating from the server, or of unidirectional consist of queries originating from the server, or of unidirectional
notifications from one entity to another. In this context, it is notifications from one entity to another. In this context, it is
important that messages be distinguished by a unique sequence number, important that messages be distinguished by a unique association, so
so that responses may identify the query to which they correspond. that responses may identify the query to which they correspond.
This section discusses two fundamental concepts of the OOPS protocol: This section discusses four fundamental concepts of the OOPS
(a) flexible division of labor between client and server. (b) protocol: (a) query/response mechanism, (b) flexible division of
consistent management of client, server and RSVP state. labor between client and server, and (c) consistent management of
client, server and RSVP state.
2.1 Division of Labor between Client and Server 2.1 Query/Response mechanism
Each OOPS message is uniquely identified by a sequence number;
Both client and server begin communication with Mseq = 0 (the
handshake message), and number consecutive messages in increasing
order. These sequence numbers do not imply the order of execution;
while the server receives messages in-order, it is free to execute
them in any reasonable order.
These sequence numbers are mainly used by the Error-Notification
operation as a means to identify the message that is associated
with the reported error. [Note 2]
2.1.1 Associating Queries and Responses
Queries and responses carry a Q_ASSOC object which relates
newly received responses to their original query operations.
The contents of this object is client-specific and therefore
opaque to the server; it is set by the client for each query
and is echoed back as-is by the server. The client must store
enough information in the Q_ASSOC object to enable its own
unique identification of the original query.
2.2 Division of Labor between Client and Server
The OOPS protocol allows for a flexible division of The OOPS protocol allows for a flexible division of
responsibilities between server and client. Processing of policies responsibilities between server and client. First, the client must
(policy elements within POLICY_DATA objects) can be performed by be able to decide how to distribute the processing and second, it
the server, the client, or by both. The decision on which must be able to merge the distributed responses into one unified
policies are to be handled locally and which are to be sent to the result.
server is always made by the client based on information exchanged
during the connection establishment handshake (see Section 3.1).
Before the client forwards incoming POLICY_DATA objects to the 2.2.1 Distributed Processing
server (Incoming-Policy-Query) it removes or marks the policy
elements it wishes the server to ignore. (Marking is performed by
changing the policy element P-type to zero.) When forwarding
incoming policy objects, the client may also set header flags to
inform the server that message integrity and/or rsvp hop has been
Internet Draft OOPS: Policy Protocol for RSVP Processing of sub-policies (sub-policy elements within
POLICY_DESC objects) can be performed by the server, the
client, or by both. The decision on which sub-policies are to
be handled locally and which are to be sent to the server is
always made by the client based on information exchanged during
the connection establishment handshake (see Section 3.1).
already checked. The client may remove sub-policy elements which are not to be
processed by the server. In this case, the client is solely
responsible for checking the integrity of the incoming policy
object; [Note 3]
_________________________
[Note 1] Execution order is implementation and policy specific; any
order that does not violate the policy specific requirements is assumed
to be reasonable.
OOPS does not impose limitations on the number of servers [Note 2] Senders must be informed about the receiver's failure to
connected to the client; when appropriate, the client could divide process their messages. This is especially critical given that OOPS
the work along policy lines between several servers, and be relies on TCP's reliability and lacks additional reliability mechanisms.
responsible for combining their results. In the rest of this
document we describe the protocol for a single server-client pair.
When the client receives outgoing POLICY_DATA objects in response [Note 3] If any portion of the POLICY_DESC object is modified, the
to a previous query (Outgoing-Policy-Response) it is responsible digest integrity verification at the server is bound to fail.
for merging the server response with the locally generated
outgoing POLICY_DATA object. Merging is performed by
concatenating the local and server policy elements and if
necessary, computing some of the POLICY_DATA object fields (e.g.,
length, INTEGRITY, etc.)
When the client receive status results in response to a previous the client must also set the OP-Code header flag to inform the
query (Status-Policy-Response) it is responsible for merging the server to that fact.
results from the server with the local results. The following
rule applies for combining any number of policies, and
specifically, local and server policies:
o When responding to a status query (authorization check), During connection establishment, the server may request to have
individual policy handlers may vote to ACCEPT, SNUB or VETO oversight over the clients local decisions; in this case, the
the request. As their names suggest, a vote of accept client should forward incoming policy objects in their
authorizes the request; a snub fails it, but remains entirety, and consult the server for all RSVP flows, regardless
indifferent on its final outcome (i.e., other policies could of whether they include POLICY_DATA objects. This oversight is
provide authorization); a veto vote excludes the possibility transparent to the client and is therefore post factum. [Note
of authorizing the request, even if other policy handlers 4]
cast accept votes.
o The merge result provides an authorization if there is at OOPS does not impose limitations on the number of servers
least one accept, and no vetoes. [Note 1] connected to the client; when appropriate, the client could
(See [LPM]) for more details). divide the work along policy lines between several servers, and
be responsible for combining their results. In the rest of this
document we describe the protocol for a single server-client
pair.
o The client and/or server should complete their policy 2.2.2 Unification of Distributed Responses
processing even if a veto was cast by some policy. [Note 2]
Division of labor between client and server is only possible to
the extent that the client has the capability to unify or merge
results; the client must be able to merge the results of
queries arriving from servers with its own local results, to
produce a single unified response to the underlying protocol
(e.g., RSVP).
Results unification is straight-forward for outgoing
POLICY_DESC object; since sub-policy elements are independent,
their unification is performed by concatenating all local and
server elements and packing them in POLICY_DESC objects. [Note
5]
Unification is more complex for status queries, since the
various responses must truly be merged to produce a single
status result. OOPS defines one basic (default) status
response interface (object and unification rules).
_________________________ _________________________
[Note 1] A veto has a stronger semantics than a snub, since it has the [Note 4] The client should not wait for an oversight decision; if the
power to forcefully reject a flow regardless of any accept decisions server overrides a local decision, it may notify the client sometime
made by others. later, even after the local client authorized the RSVP operation.
[Note 2] A wide range of policies may not care about the final status [Note 5] An oversight sub-policy element would override the locally
results and should be activated regardless. For instance: a policy that generated element, if the two are of the same type.
logs all policy queries.
Internet Draft OOPS: Policy Protocol for RSVP However, given that OOPS is an extensible framework, it allows
the the client and server to negotiate a more sophisticated
interface (see Section 3.1). Additional response interfaces
could be described in separate documents which should define
the response object format and unification rules. [Note 6]
o Protocol errors are always considered as snubs, and thus, 2.2.3 Default Status Response
neutral.
It is recommended (although not required) that all local status The default status response object is of the C-Type 1. C-Type
processing at the client be completed before querying the server. 1 objects may contain two values: a policy admission decision
This allows the server to immediately commit the transaction (PAD) and a preemption priority value (PP). It is reasonable
rather than having to wait until the client is done. (See the to assume that some clients would not be able to utilize the
Client-Status-Notification operation.) flow preemption priority information; such clients are free to
ignore this value and assume that all flows are created equal.
(have priority 0).
2.1.1 Error Reporting PADs may have one of three values: ACCEPT, SNUB, and VETO.
ACCEPT authorizes the query, SNUB signifies neutrality (neither
accept nor reject). A VETO from the server or LPM has a
stronger semantics than a snub, since it has the power to
forcefully reject a flow regardless of any accept decisions
made by the other.
Policy error reporting is policy specific; it is performed by The rules for unification of PAD values A and B are straight-
sending POLICY_DATA objects with specific error objects toward forward:
the originator of the error. The rules governing error
reporting are described in [Ext].
In this document, we discuss only error reporting between the +----------------------+---------------------+
client and the server, which is intended to help the client | A+B | IF... |
determine whether error reporting is required at all. +----------------------+---------------------+
| SNUB | A=SNUB and B=SNUB |
| VETO | A=VETO or B=VETO |
| ACCEPT (+PP value) | Otherwise |
+----------------------+---------------------+
There are two types of possible errors; policy errors and A unified result of ACCEPT provides approval for the status
protocol errors. For the purpose of this protocol, policy query; both SNUB and VETO signal the rejection of the query.
errors are considered as legitimate results (e.g., reject) and
not as errors. Protocol errors must be reported as such.
However, since they do not reveal any policy decisions they
should always be considered as snubs (and therefore neutral to
the overall policy decision).
When the client (or server) discovers a protocol error (syntax, Note that a client and/or server should complete their policy
missing parameters, etc.), it is reported alongside and processing even if a veto was cast by some policy. [Note 7]
orthogonal to the status results (accept, reject or veto). _________________________
[Note 6] A separate template document and a list of more sophisticated
responses should be prepared.
Internet Draft OOPS: Policy Protocol for RSVP [Note 7] A wide range of sub-policies may not care about the final
status results and should be activated regardless. For instance: a
policy that logs all policy queries.
2.2 State Management An ACCEPT response is accompanied by a PP value between 0..255.
Lower values describe higher priorities (priority 1 is the
highest). The value 0 is reserved for "N/A"; this value is
used when preemption priority is not applicable.
The unification of PP values A and B attempts to provide the
highest priority (lowest value) which is supported by an ACCEPT
decision. The value 0 has no effect on the unified priority:
+----------------------+---------------------+
| A+B | IF... |
+----------------------+---------------------+
| MIN(A,B) | A!=0 and B!=0 |
| A | B=0 |
| B | A=0 |
| 0 (n/a) | A=0 and B=0 |
+----------------------+---------------------+
2.3 State Management
In order for policy objects contained in RSVP messages to be In order for policy objects contained in RSVP messages to be
processed quickly and correctly, it is often required that the processed quickly and correctly, it is often required that the
results of past policy decisions be cached and maintained at the results of past policy decisions be cached and maintained at the
LPM or the policy server. Maintenance of policy state must be LPM or the policy server. During normal operations, the state
done in a manner that is consistent with the division of maintained in the client and in the server must remain consistent,
responsibility for policy processing between client and server and and must timeout at roughly the identical times in RSVP, the
with RSVP's state management rules. [Note 3] client, and the server.
The most straightforward method for state maintenance is for the The most straightforward method for state maintenance is for the
LPM and the policy server to use the same soft-state mechanism as LPM and the policy server to use the same soft-state mechanism as
the RSVP capable router. Unfortunately, this soft-state approach the RSVP capable router. Unfortunately, this soft-state approach
has undesirable scaling properties since it requires the client to has undesirable scaling properties since it requires the client to
contact the server on each refresh period (regardless of state contact the server on each refresh period (regardless of state
changes). changes).
An alternative approach is to allow both client and server to use An alternative approach is to allow both client and server to use
hard-state mechanisms that could limit the client-server hard-state mechanisms that could limit the client-server
communication to updates only. This alternative implies that the communication to state updates only. To support the hard-state
client must be capable of recognizing objects that would result in mode, the client must be able to distinguish between repeats
a change of policy state, as well as being able to translate (refreshes) and updates; it must also be able to translate the
between the soft-state provided by RSVP and the hard-state soft-state that is provided by RSVP into the hard-state exchanged
exchanged with the server. with the server.
Thus, we envision one end of the spectrum where a "dumb" client Thus, we envision one end of the spectrum where a "dumb" client
would use a soft-state approach and simply pass all policy objects would use a soft-state approach and simply pass all policy objects
to the server relying on it for all policy processing. The rate to the server relying on it for all policy processing. The rate
of queries and lack of caching at the client implies the need for of queries and lack of caching at the client implies the need for
a dedicated, close-by server (PS-2, in our example). As we move a dedicated, close-by server (PS-2, in our example). As we move
towards the other extreme, clients become smarter, more capable of towards the other extreme, clients become smarter, split the work
caching, and dividing the work between themselves and the server. between themselves and the server, utilize caching capabilities.
Such clients could take advantage of the benefits of hard-state Such clients could take advantage of the benefits of hard-state
management, and initiate queries only on actual state updates. management, and initiate queries only on actual state updates.
OOPS supports soft and hard state mechanisms seamlessly, as OOPS supports soft and hard state mechanisms seamlessly, as
described in this section. The client determines its desired type described in this section. The client determines its desired type
of state management, and communicates it on an object-by-object of state management, and communicates it on an object-by-object
basis. A single client can use soft-state for some information, basis. A single client can use soft-state for some information,
and hard state for others. Furthermore, the OOPS protocol allows and hard state for others. Furthermore, the OOPS protocol allows
clients to modify their caching strategies on the fly (without clients to modify their caching strategies on the fly (without
_________________________
[Note 3] During normal processing, state split between client and server
should remain consistent, and timeout at roughly the same time at RSVP,
the client, and the server.
Internet Draft OOPS: Policy Protocol for RSVP
having to renegotiate with the server). While the protocol does having to renegotiate with the server). While the protocol does
not impose strategy limitations, a client implementation could not impose strategy limitations, a client implementation could
restrict itself to a more modest and simple combination of soft restrict itself to a more modest and simple combination of soft
and hard state. and hard state.
There are two types of state information that is stored at the There are two types of state information that is stored at the
client: (a) client state information that was forwarded to the client: (a) client state information that was forwarded to the
server (e.g., policy objects in incoming Path/Resv messages). (b) server (e.g., policy objects in incoming Path/Resv messages). (b)
server state which is cached at the client (e.g., policy results server state which is cached at the client (e.g., policy results
computed by the server). The OOPS protocol addresses each of these computed by the server). The OOPS protocol addresses each of these
types of states: types of states separately:
2.2.1 Client State Information Cached at Server 2.3.1 Client State Information Cached at the Server
The client indicates that it desires hard (or soft) state The client indicates its choice of state management approach by
management of client state information cached at the server by
setting (or resetting) the OOPS_HardState flag in objects sent setting (or resetting) the OOPS_HardState flag in objects sent
to the server. When the client chooses soft-state management to the server. When the client chooses soft-state management,
for a particular object, policy state for that object would age policy state for that specific object ages and expires at the
and expire at the server according to the timeout specified in server according to the specified timeout (refresh-period * K).
the object. The client must, therefore, forward each policy Therefore, the state cached at the server is kept alive by
refresh (update or not) to the server, to keep the soft-state constant refreshing (the client must forward ALL incoming RSVP
at the server from becoming stale and expiring. On the other messages, whether or not they represent refreshes or updates).
hand, when the client indicates hard-state management, it On the other hand, when indicating a choice of hard-state
assumes responsibility for reliably informing the server on management, the client assumes responsibility for reliably
every policy update. In this case, the state cached at the informing the server on every policy update. In this case, the
server would not expire unless explicitly modified by the state cached at the server would not expire unless explicitly
client, or when the communication channel to the client breaks. modified by the client, or when the communication channel to
The client may refrain from forwarding to the server any policy the client breaks. [Note 8]
objects that are identical to objects previously sent to the The client may refrain from forwarding to the server any
server. repeat policy objects (which represent no updated information).
The client may switch between hard and soft states on the fly The client may switch between hard and soft states on the fly
_________________________
[Note 8] Clearly the channel breaks when either the client or server
become disfunctional or die.
by modifying the OOPS_HardState flag while forwarding input to by modifying the OOPS_HardState flag while forwarding input to
the server. the server.
2.2.2 Server State Information Cached at Client 2.3.2 Server State Information Cached at the Client
The client indicates that it is capable of hard (or soft) state
management of server state information by setting (or
resetting) the OOPS_HardState flag in queries sent to the
server. Here, hard state management refers to the caching of
response results at the client. Soft state management means
that the client, being incapable of caching, would purge them
after usage (one-time, or disposable results).
A non-cached response has no strings attached, but the client
must issue a query each time that responses are needed. When
Internet Draft OOPS: Policy Protocol for RSVP The client indicate its state management capabilities by
setting (or resetting) the OOPS_HardState flag in queries sent
to the server. A choice of soft-state indicates that the client
is incapable of caching, and it purges the server responses
after usage (one-time, or disposable results). Clearly, without
caching, the client must issue a new query each time that
responses are needed.
the server responds to a cached (hard-state) query, it assumes When the server responds to a cached (hard-state) query, it
responsibility to reliably inform the client about any changes assumes responsibility to reliably inform the client about any
that may occur later to the original results of this query. changes that may occur later with the original response to this
The client may rely on cached results as long as the there is query. The client may rely on cached results as long as there
no change in RSVP's state (which includes incoming policy is no change in RSVP's state (which includes incoming policy
objects), [Note 4] objects), [Note 9]
and the communication channel with the server is intact. and the communication channel with the server is intact.
The client may switch between hard and soft states on the fly The client may switch between hard and soft states on the fly
by issuing a new query with a modified flag. by issuing a new query with a modified flag.
2.2.3 State Change Notification 2.3.3 State Change Notification
State change notification is done by resending the same type as State change notification is done by resending the same type as
the original message but with the modified state instead. the original message but with the modified state instead.
Client notification example (incoming POLICY_DATA objects for Client notification example (incoming POLICY_DESC objects for
Resv-X): Resv-X):
Seq# Type Data _________________________
--- ---- ---- [Note 9] A configurable option may allow the client to use cached
Client ==> Server: 50 Notify:input Resv-X: PD-1 results even when some RSVP state changes. There is a clear trade-off
here between fast and accurate policy processing, however, given that
the server is up, and that authorization was already granted previously
for that RSVP flow, some may find it a reasonable policy approach.
Time passes; the input POLICY_DATA object associated with TYPE DATA
---- ----
CLIENT ==> SERVER: NOTIFY:INPUT RESV-X: PD-1
Time passes; the input POLICY_DESC object associated with
Resv-X changed to PD-2. Resv-X changed to PD-2.
Client ==> Server: 90 Notify:input Resv-X: PD-2 CLIENT ==> SERVER: NOTIFY:INPUT RESV-X: PD-2
Server notification example (status query for reservation Server notification example (status query for reservation
Resv-X): Resv-X):
Seq# Type Data TYPE DATA
--- ---- ---- ---- ----
Client ==> Server: 150 Query:status Resv-X CLIENT ==> SERVER: QUERY:STATUS Q_ASSOC=ID1, RESV-X
Server ==> Client: 151 Resp :status #150: accept SERVER ==> CLIENT: RESP :STATUS Q_ASSOC=ID1, ACCEPT
Time passes; the status of Resv-X changed to "reject". Time passes; the status of Resv-X changed to "reject".
_________________________
[Note 4] A configurable option may allow the client to use cached
results even when some RSVP state changes. Clearly, there is a trade-
off between fast and accurate policy processing, however, given that the
server is up, and that authorization was already granted previously for
that RSVP flow, some may find it a reasonable policy approach.
Internet Draft OOPS: Policy Protocol for RSVP SERVER ==> CLIENT: RESP :STATUS Q_ASSOC=ID1, REJECT
Server ==> Client: 205 Resp :status #150: reject 2.3.4 State Re-synchronization
3. Client-Server Communications Both client and server may re-synchronize their respective
states at any time during the connection. The reset initiator
sends a Bye-Notification with a RESET code, and the receiver
responds with a Bye-Notification with the same code. After
this exchange, all cached state becomes soft, and a new logical
connection is reestablished (beginning with Connection-
Initiation-Query,...). New/hard state gradually replaces
old/soft state as described in Section 2.3.4.
This section describes the fundamentals of client-server 2.4 Error Handling
communications: connection establishment, communication channel
management, and connection termination.
3.1 Connection Establishment We distinguish between two types of possible errors; policy errors
and protocol errors.
Connections are always initiated by clients. The client 2.4.1 Protocol Errors
establishes a TCP connection to its preferred policy server, and
then initiates the OOPS session through a two way handshake.
o Communication Initiation by the Client Protocol errors (e.g., missing or bad parameters) do not reveal
either positive or negative policy decisions and are therefore
neutral (represented as SNUBs). [Note 10]
_________________________
[Note 10] This neutrality allows, when appropriate, other valid sub-
policy elements to support an accept decision.
The client sends a Connection-Initiation-Query to the server. It is recommended (although not required) that all local status
This message identifies the client to the server and provides processing at the client be completed before querying the
the basic characteristics of the client. server. This allows the server to immediately commit the
transaction rather than having to wait until the client is
done. (See the Client-Status-Notification Op-Code.)
o Response by the Server Some OOPS protocol errors may only affect the OOPS protocol
processing or simply be logged. Other errors may escalate to
become policy errors (e.g., a bad POLICY_DESC is reported as a
policy error).
The server responds with a Connection-Accept-Response to 2.4.2 Policy Errors
connect to the client. It may also respond with a
Connection-Reject-Response to refuse and disconnect from the
client.
After connection establishment both the client and server Policy errors are reported in a sub-policy element specific
know the set of policies that the client can send to the format. These elements are encapsulated in POLICY_DESC objects
server, and which one of them should handle default and are forwarded toward the originator (cause) of the error.
(unrecognized) policies. The Keep-Alive period is determined In most cases, a negative Status-Response initiates an
as the minimum between the two values declared in the automatic error response (e.g., RSVP ResvErr or PathErr),
handshake messages. however, OOPS allows reporting of other error situations by
scheduling an explicit error message (using the Protocol-
Message-Notification op-code). (See [Ext] for more about the
rules governing error reporting).
3.1.1 Secure Communications Consider a scenario where two receivers R1 and R2 listen to a
multicast transmission from S1. A reservation sent by R1 is
propagated upstream until it reaches node A, where it
encounters a policy rejection.
The integrity of the communication channel between client and R1------------+
server is guaranteed by the use of shared-key message digest. B--------------A----------- S1
(e.g., keyed MD5). A client, wishing to establish secure / \ |
communications adds a "Cookie" to the Connection-Initiation- R2------------+ \ |
Query. The server may respond with a reply Cookie or with an \ |
Error-Description [Note 5] PS1 PS2
_________________________ Figure 3: An Error Reporting Scenario
[Note 5] The Error-Description provides reasons for rejecting the secure
communications request.
Internet Draft OOPS: Policy Protocol for RSVP The following table describes a subset of the relevant
signaling which begins with reservation initiation by R1 and R2
and ends by R1 receiving the appropriate error response.
Shared keys may be obtained from local static configurations or From/To Message Comments
could be distributed dynamically. The exchange of cookies ________________________________________________________________________________
provides the client and server with an opportunity for R1->B Resv [PD1]
establishing a temporary shared-key (e.g., from Kerberos) for R2->B Resv [PD2]
the connection length. B->PS1 OOPS-Incoming-Policy-Query[PD1,PD2] ;B queries PS1
OOPS-Status-Query?
OOPS-Outgoing-Policy-Query? [Resv]
PS1->B OOPS-Status-Response: ACCEPT
OOPS-Outgoing-Policy-Response[PD3]
B->A Resv [PD3] ;B forwards the Resv to A
A->PS2 OOPS-Incoming-Policy-Query[PD3] ;A queries PS2
OOPS-Status-Query?
PS2->A OOPS-Status-Response: SNUB (reject) ;PS2 reject the reservation
A->PS2 OOPS-Outgoing-Policy-Query? [ResvErr] ;PS2 provides error PD
PS2->A OOPS-Outgoing-Policy-Response [PD1-E]
A->B ResvErr [PD1-E] ;A sends back ResvErr to B
B->PS1 OOPS-Incoming-Policy-Query[PD1-E]
OOPS-Outgoing-Policy-Query? [ResvErr] ;PS1 builds error PD
PS1->B OOPS-Outgoing-Policy-Response[PD1-E'],R1 ; (directed to R1 only)
B->R1 ResvErr [PD1-E'] ;B sends back ResvErr to R1
________________________________________________________________________________
Once a shared key is available, each message sent by either Figure 4: Error Reporting Signaling
client or server includes an INTEGRITY object as described in
[Bak96]. The format and functionality of the INTEGRITY object
are identical to that of RSVP. The sender client or server
computes the message digest over the entire OOPS message; if
the receiver fails to verify the message, it response with an
error message.
The format of "cookies" is left for future versions of this All error information is carried in POLICY_DESC objects (as
document. sub-policy elements). OOPS server may read and modify this
information along the ResvErr path; it may also direct the
error responses only to the relevant branches of the reserved
tree (in this scenario, the error is associated with R1 but not
with R2).
3.2 Reliable Communication 3. Client-Server Connection
We expect TCP to provide us with reliable, in-order delivery of The following section describes the fundamentals of client-server
packets, as well as information on the liveliness of the connection: establishment, channel, and termination.
communication channel. Given that TCP is responsible for all the
time critical network operations, reliability errors are assumed
to be virtually nonexistent. However, to maintain application-
level reliability, OOPS uses a minimalistic reliability mechanism
using sequence numbers, selective retransmit and keep-alive
messages. This requires no retransmission timeouts, and has low
overhead.
3.2.1 Sequence Numbers 3.1 Connection Establishment
Each OOPS message, except a Resend-Notification, is uniquely OOPS uses a well known port number (OOPS = 3288) for incoming
identified by a sequence number [Note 6] connection requests. Usually, the client would attempt to
(Mseq). These numbers do not imply any order of execution; establish a TCP connection to its preferred policy server,
while the server receives messages in-order, it is free to however, both client and server listen to the OOPS port. [Note 11]
execute them in any reasonable order. [Note 7]
In addition, each message also carries the sequence number of
the last received message (Rseq). Both client and server begin
communication with Mseq = 0 (the handshake message), and number
consecutive messages in increasing order.
_________________________ _________________________
[Note 6] Not counting wraparounds [Note 11] New (or recovering) policy servers are allowed to notify
[Note 7] Execution order is implementation and policy specific; any clients on their existence by issuing a TCP connection request to the
order that does not violate the policy specific requirements is assumed client's OOPS port number.
to be reasonable.
Internet Draft OOPS: Policy Protocol for RSVP Regardless of who initiated the TCP connection, once the
connection is in place, the OOPS logical connection establishment
is always initiated by the client and is performed through a two
way handshake.
A transmitted message with Mseq = m is considered to be o Communication Initiation by the Client
acknowledged if m <= Rseq (Rseq from the latest received
message). [Note 8]
The sender must be prepared to retransmit (as requested) any The client sends a Connection-Initiation-Query to the server.
message that has not been acknowledged yet. Missing, or out- This message identifies the client to the server and provides
of-order messages are identified by a gap in sequence numbers the basic characteristics of the client as well as a list of
of received messages. policy responses that are acceptable to the client. This list
is in decreasing order of acceptability, and terminates with
the default element.
3.2.2 Receiver initiated retransmit o Response by the Server
When the receiver (client or server) detects missing messages The server responds with a Connection-Accept-Response to
it immediately sends an explicit Resend-Notification listing connect to the client. It may also respond with a
these messages. The Resend-Notification has a sequence number Connection-Reject-Response to refuse and disconnect from the
0. [Note 9] client.
Upon receiving the Resend-Notification, the sender must After connection establishment both the client and server
retransmit all the requested messages before sending new ones. know the set of sub-policies that the client can send to the
server, which one of them should handle default
(unrecognized) sub-policies, as well as the format of status
responses from server to client. They also establish the
Channel-Hold period which is determined as the minimum
between the two values declared in the handshake messages,
but must be at least 3 seconds.
3.2.3 Keep-Alive Messages 3.1.1 Reliable Communication
Many platforms provide system support for detecting broken TCP We expect TCP to provide us with reliable, in-order delivery of
connections. OOPS can utilize, but does not depend on such packets. Given that TCP is responsible for all the time
mechanisms. Instead, it relies on Keep-Alive messages to critical network operations, reliability errors are assumed to
provide application-level communication-channel verification, be virtually nonexistent.
as a server may be in a dysfunctional state while its TCP
connection is still open and viable.
The client sends a Keep-Alive message to the server only after 3.1.2 Secure Communications
the receiving channel has been idle for longer than the Keep-
Alive period. The server responds promptly with a Keep-Alive
ack.
3.2.4 Overhead OOPS relies on standard protocols for security of client-server
communications. An emerging standard protocol IPSEC [IPSEC] is
the mechanism of choice for ensuring either integrity or
secrecy. The use of IPSEC and/or other security protocols is
transparent to OOPS.
These reliability mechanisms were designed to be simple and 3.2 Connection Termination
impose minimal overhead in a busy working environment. When
the client supports a large number of RSVP sessions and has
frequent message exchange with the server, it would not be
_________________________
[Note 8] Mseq <= Rseq should take into account possible wrap-around of
sequence numbers.
[Note 9] Thus, Resend-Notification cannot participate in sequence number This section describes the handling of communication breakdown.
reliability verification. A lost Resend-Notification cannot not be
detected, however, a new one is bound to be triggered sometime again.
Internet Draft OOPS: Policy Protocol for RSVP 3.2.1 Implicit Termination
sending Keep-Alive messages. Similarly, since TCP is used for The communication channel may be unexpectedly disconnected
reliable communications, there is a virtually zero probability because of a misbehaving client or server, network split, or
that Resend-Notification messages would be required. The only for other reasons. Both client and server must be able to
timer required is for the Keep-Alive period; the timer is reset detect such channel failures and act accordingly. Consider the
on each message arrival and a Keep-Alive message is initiated case where OOPS is used for quota enforcement. The server may
only when it expires. approve a reservation while debiting X/min from a local
account. If the OOPS communication channel breaks, it is
critical for the server to detect the break and stop debiting
this account.
3.3 Connection Termination The OOPS protocol relies on Keep-Alive messages to provide
application-level communication-channel verification. [Note 12]
This section describes how communication breakdown is handled. Implicitly, the communications channel is assumed to be
disconnected after it has been idle (no message was received on
it) for more than a Channel-Hold period (see Section 3.1).
Keep-Alive messages are sent by both client and server as
needed [Note 13]
to ensure the liveness of the connection (to prevent a
Channel-Hold timeout). Keep-Alive messages are not
acknowledged.
3.3.1 Explicit Termination 3.2.2 Explicit Termination
The client (or server) may terminate the connection by sending The client (or server) may terminate the connection by sending
a Bye-Notification, and wait until either it receives an echoed a Bye-Notification, and wait until either it receives an echoed
Bye-Notification or a Keep-Alive period had passed. In between, Bye-Notification or the Channel-Hold period had passed. In
it should ignore incoming messages (and not reset the Keep- between, it should ignore incoming messages (and not reset the
Alive timer). Channel-Hold timer).
At the opposite side, when a client (or server) receive a Bye- At the opposite side, when a client (or server) receive a Bye-
Notification message, they should echo it, and close the Notification message, it should echo it, and close the
connection.
After an explicit termination, both client and server may
cleans up and purges the state related to the closed
connection. connection.
3.3.2 Implicit Termination _________________________
[Note 12] OOPS implementations may utilize system dependent mechanisms
The communication channel may be unexpectedly disconnected for detecting broken TCP connections, but does not rely on them. This is
because of a misbehaving client or server, network split, or especially important since a server may be in a dysfunctional state
other reasons. Both client and server must be able to detect while its TCP connection is still open and viable.
such channel failures and act accordingly.
Consider the case where OOPS is used for quota enforcement.
The server may approve a reservation while debiting X/min from
a local account. If the OOPS communication channel breaks, it
is critical for the server to detect it and stop debiting this
account.
A communication channel is assumed to be disconnected when the [Note 13] When the intermediate period in between two OOPS messages
channel was idle (no message was received on it) for over two approaches the Channel-Hold time.
Keep-Alive periods.
3.3.3 Post Termination 3.2.3 Post Termination
Soft-state has an inherent cleanup mechanism; when the channel Soft-state has an inherent cleanup mechanism; when the channel
disconnects, the soft-state would age and eventually expire disconnects, the soft-state begins to age until it eventually
expires (using the same mechanism and refresh-period * K used
Internet Draft OOPS: Policy Protocol for RSVP by RSVP).
based on the same mechanism and refresh-period used by RSVP.
When hard-state is used, cached state is assumed to be valid
unless explicitly modified. However, when the channel
disconnects such an explicit notification is not possible.
Purging all state immediately upon disconnection is not an
acceptable approach since it may cause a disruption of service
before an alternate server is contacted. OOPS uses the
following simple rule:
When the communication channel disconnects, the hard state In contrast, hard-state is assumed to be valid unless
associated with it is assumed to be soft-state that was just explicitly modified. However, when the channel disconnects such
refreshed. an explicit notification is not possible. Clearly, purging all
state immediately upon disconnection is not an acceptable
approach since should cause disruption of service and would not
allow enough time to contact an alternate server. OOPS uses
the following simple rule:
Naturally, when any RSVP state changes (e.g., routing changes, When the communication channel disconnects, all hard state
policy input changes, etc.), cached results at the client associated with it is assumed to be soft-state that had been
should not be used and must be purged. refreshed recently.
3.3.4 Switching to An Alternative Server 3.2.4 Switching to An Alternative Server
We assume that the client is provided a list of policy servers We assume that as part of their local configuration, clients
and site specific selection criteria. obtain a list of policy servers and site specific selection
criteria. This list can be the basis for server switching
decisions.
A switch to an alternate server may be triggered by a voluntary A switch to an alternate server may be triggered by a voluntary
disconnection (i.e., Bye-Notification) or an unexpected break disconnection (i.e., Bye-Notification) or an unexpected break
in the communication channel. in the communication channel. During normal operations, the
client may wish to switch to an alternate server (for any
During normal operations, the client may wish to switch to an reason). The client is advised to first connect to the new
alternate server (for any reason). The client is advised to server before sending a Bye-Notification to the original one.
first connect to the new server before sending a Bye- If the communication channel unexpectedly disconnects, the
Notification to the original one. If the communication channel client should quickly attempt to connect to an alternate
unexpectedly disconnects, the client should quickly attempt to server.
connect to an alternate server.
In both cases, after the connection to a new server [Note 10] In both cases, after the connection to a new server [Note 14]
is established, the aging cached state from the old server is established, the aging cached state from the old server
would be gradually replaced by responses from the new server. would be gradually replaced by responses from the new server.
[Note 11] [Note 15]
_________________________ _________________________
[Note 10] The term "new server" may be the same as the "previous [Note 14] The term "new server" may be the same as the "previous
server"; it may happen that the connection encounters a problem and the server"; it may happen that the connection encounters a problem and the
client chooses to disconnected and re-established the connection. client chooses to disconnected and re-established the connection.
[Note 11] The client could speed-up replacement of cached state by [Note 15] The client could speed-up replacement of cached state by
sending copies of cached input to the server and issuing repeated sending copies of cached input to the server and issuing repeated
queries, on connection establishment (instead of waiting until objects queries, on connection establishment (instead of waiting until objects
arrive from RSVP).
Internet Draft OOPS: Policy Protocol for RSVP
As general guidelines, state replacement from a new server As general guidelines, state replacement from a new server
should not cause a disruption of service that would not should not cause a disruption of service that would not
otherwise occur (if a new server was not found). [Note 12] otherwise occur (if a new server was not found). [Note 16]
After switching to an alternate server, the client may
periodically poll its old (preferred) server by attempting a
TCP connection to its OOPS port. Similarly, a new (or recovered
server) may notify clients about its liveness by attempting to
connect to their OOPS port. In the latter case, clients may
disconnect the TCP connection or respond with a Connection-
Initiation-Query as if the client initiated the connection in
the first place. [Note 17]
%% TOO EARLY: WE SHOULD PUT IT IN THE NEXT VERSION (02)
%% ----------------------------------------------------
%%The client may choose to use both the main and the alternate
servers
%%in tandem. In this case, the client would send inputs and
updates to
%%both servers, but will make status and outgoing-policy
queries only
%%to the main server. Given that both servers have the same
state image,
%%a switch between them could be fast without causing
disruption of
%%service.
4. OOPS Message Format 4. OOPS Message Format
OOPS messages serve as a wrapper that may include one or more OOPS messages serve as a wrapper that may include one or more Op-
protocol operations; this wrapper allows common operation (e.g., MD5 Codes; the message wrapper allows common operation (e.g., MD5
integrity, RSVP_HOPs, protocol version, etc.) to be verified and integrity, HOP_DESCs, protocol version, etc.) to be performed and
performed in one-shot. verified in one-shot. All OOPS messages are composed of the following
fields:
_________________________
arrive from RSVP).
[Note 16] Practically, this means that as long as there is no change in
RSVP messages, the client is advised to choose between cached and new
results in favor of authorizing the request.
[Note 17] Future version of this document may include the use of
multicast to advertise the liveness of servers.
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Vers | Flags | op-objs# | Reserved (0) | | Ver | #Op-Codes | Flags | ////// |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Message Length | | Message Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Message Sequence Number | | Message Sequence Number |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Ack-ed Sequence Number | | OOPS_MSG_AUTH (Optional) |
+---------------+---------------+---------------+---------------+
| INTEGRITY Object... (optional) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| List of operations | | List of Op-Codes... |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Any OOPS message is composed of the following fields:
Version: 8 bits Version: 8 bits
Protocol version number. The current version is 1. Protocol version number. The current version is 1.
Flags: 8 bits Flags: 8 bits
0x01 H_Integrity_Checked Integrity already checked by client 0x01 H_Integrity_Checked POLICY_DESC Integrity already checked by client
0x01 H_Hops_Checked RSVP_HOPs already checked by client 0x02 H_Hops_Checked Prev/Next HOPs already checked by client
op-objs#: 8 bits #Op-Codes: 8 bits
Number of objects included in this message. Number of Op-Codes included in this message.
Message Length: 32 bits Message Length: 32 bits
_________________________
[Note 12] Practically, this means that as long as there is no change in
RSVP messages, the client is advised to choose between cached and new
results in favor of authorizing the request.
Internet Draft OOPS: Policy Protocol for RSVP
The total length of this OOPS message in bytes. The total length of this OOPS message in bytes.
Message Sequence Number: 32 bits Message Sequence Number: 32 bits
The sequence number of the message being sent. The sequence number of the message being sent.
Ack-ed Sequence Number: 32 bits OOPS_MSG_AUTH (optional): variable length
The sequence number of the last message received in-order from
the peer entity (client or server).
RSVP INTEGRITY Object (optional): variable length This Message Authenticator provides integrity verification based
on a shared-keyed message digest. The message digest is
calculated over the entire OOPS message.
This object is defined in [Bak96]. It provides a message digest There is only one object format currently defined is identical
based on a shared key between the client and sender. The message to the RSVP INTEGRITY object (defined in [Bak96]).
digest is calculated over the entire OOPS message.
List of OOPS operations: variable length List of OOPS operation codes (Op-Codes): variable length
Described in the following section. Described in the following section.
4.1 OOPS Operations 4.1 OOPS Operation Codes (Op-Codes)
Each OOPS message may contain multiple OOPS operations each Each OOPS message may contain multiple OOPS operations each
encapsulating a different query, response or notification. For encapsulating a different query, response or notification. For
example, multiple Incoming-Policy-Queries might be followed by a example, multiple Incoming-Policy-Queries might be followed by a
Status-Query operation in the same message. Operations within an Status-Query operation in the same message.
OOPS message are sequentially numbered.
Individual OOPS operations have the following header: Individual OOPS Op-Codes have the following header:
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Operation Type| Op. Subtype | Op. Seq# | Flags | | Operation Code| Op. Subtype | Flags | ////// |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Length (bytes) | | Length (bytes) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | RSVP's Refresh Period | | Refresh Period |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
The operation header has the following fields: The operation header has the following fields:
operation Type: 8 bits operation Code: 8 bits
The type of OOPS operation. The type of OOPS operation.
Operation Subtype: 8 bits Operation Subtype: 8 bits
Internet Draft OOPS: Policy Protocol for RSVP This field can be used to indicate an attribute of the Op-
Code, such as its version; currently it is always set to 1.
This field can be used to indicate an attribute of the
operation type, such as its version; currently it is always
set to 1.
Operation Sequence Number: 8 bits
The operation sequence number within the message.
Flags: 8 bits Flags: 8 bits
0x01 OOPS_HardState: Hard State (soft-state if not set (0) ) 0x01 OOPS_HardState: Hard State (soft-state if not set (0) )
0x02 OOPS_Shared : Resv shared among sources as filter specs 0x02 OOPS_Shared : Resv shared among sources as filter specs
0x02 OOPS_FullList : Last in the set of status queries. 0x02 OOPS_FullList : Last in the set of status queries.
Length: 32 bits Length: 32 bits
Contains the total operation length in bytes. Contains the total operation length in bytes (including
header).
RSVP's Refresh Period Refresh Period
The refresh-period RSVP associates with this object. The refresh-period associates with this object (e.g., RSVP's
refresh period).
This remainder of this section describes the set of operations The remainder of this section describes the set of operations that
that may appear in OOPS messages. Many data fields of these may appear in OOPS messages and their object format. OOPS does
operations are RSVP objects; they are typed in uppercase letters not bind itself to a particular protocol (i.e., RSVP) and is built
and their format is defined in [RSVPSP]. The format of other around objects that may belong to different (other) protocols. The
operations is listed in the following section. current draft is based on the assumption that RSVP would be one
(the first) of these protocols and thus, the draft provides the
appropriate RSVP objects format.
4.1.1 Null-Notification (a.k.a Keep-Alive) 4.1.1 Null-Notification (a.k.a Keep-Alive)
Operation Type = 0, sub-type = 0 Operation Type = 0, sub-type = 1
<Null-Notification> ::= <Common OOPS header> <Null-Notification> ::= <Common OOPS header>
This empty or null notification triggers no operation; thus, This empty or null notification triggers no operation; thus,
can be used as as Keep-Alive signal to test the viability of can be used as as Keep-Alive signal to test the viability of
the communication channel between client and server (see the communication channel between client and server (see
Section 3.2.3). Section 3.2.1).
4.1.2 Connection-Initiation-Query 4.1.2 Connection-Initiation-Query
Operation Type = 1, sub-type = 1 Operation Type = 1, sub-type = 1
<Connection-Initiation-Query> ::= <Common OOPS header> <Connection-Initiation-Query> ::= <Common OOPS header>
<Ver> <RSVP-K> <Flags> <CONNECT_DESC>
<Client-ID> <CLASS_ID>
<CLIENT_ID>
Internet Draft OOPS: Policy Protocol for RSVP <RESP_INT>
<COOKIE>
<Max-Pkt-Size> <Keep-Alive period>
<Class Indicator>
<Cookie>
The client sends this query to establish a connection with a The client sends this query to establish a connection with a
server. This message is sent following the establishment of a server. This message is sent following the establishment of a
transport connection (TCP). transport connection (TCP).
o CONNECT_DESC
Description of connection parameters.
o CLASS_ID
The client's class provides an implicit description of the
client's capabilities and requirements; the CLASS_ID is an
index into the class list maintained by the server; it is
used in conjunction with the CLIENT_ID.)
o CLIENT_ID
The network address of the client. From the combination
of CLIENT_ID and CLASS_ID the server can learn about the
set of sub-policies it is required to support for this
particular client; it can also learn which of these sub-
policies are optional and which are mandatory.
o RESP_INT
A list of possible response interfaces.
o COOKIE
4.1.3 Connection-Accept-Response 4.1.3 Connection-Accept-Response
Operation Type = 2, sub-type = 1 Operation Type = 2, sub-type = 1
<Connection-Accept-Response> ::= <Common OOPS header> <Connection-Accept-Response> ::= <Common OOPS header>
<Max-Pkt-Size> <Keep-Alive period> <CONNECT_DESC>
<Policy list> <PLIST>
<Cookie> <RESP_INT>
<COOKIE>
The server sends this response to accept a client's connection The server sends this response to accept a client's connection
connection request. connection request.
o CONNECT_DESC
o PLIST
Each "From Policy m" and "To Policy m" pair represent a
range of sub-policies that the server is willing to
support.
o RESP_INT
The chosen (agreed upon) status response interface.
o COOKIE
4.1.4 Connection-Reject-Response 4.1.4 Connection-Reject-Response
Operation Type = 3, sub-type = 1 Operation Type = 3, sub-type = 1
<Connection-Reject-Response> ::= <Common OOPS header> <Connection-Reject-Response> ::= <Common OOPS header>
<Error-Description> <ERR_DESC>
The server sends this response to reject a client's connection The server sends this response to reject a client's connection
initiation. It specifies both reason code and text. initiation. It specifies both reason code and text.
4.1.5 Bye-Notification 4.1.5 Bye-Notification
Operation Type = 4, sub-type = 1 Operation Type = 4, sub-type = 1
<Bye-Notification> ::= <Common OOPS header> <Bye-Notification> ::= <Common OOPS header>
<BYE_DESC>
[<ERR_DESC>]
This message is used by either client or server to terminate This message is used by either client or server to terminate
the OOPS connection. (Section 3.3.1 includes a description of the OOPS connection.
explicit termination )
o BYE_DESC
(Section 3.2.2 includes a description of explicit termination
using Bye-Notification)
4.1.6 Incoming-Policy-Query 4.1.6 Incoming-Policy-Query
Operation Type = 5, sub-type = 1 Operation Type = 5, sub-type = 1
<Incoming-Policy-Query> ::= <Common OOPS header> <Incoming-Policy-Query> ::= <Common OOPS header>
<RSVP MESSAGE TYPE> <Q_ASSOC>
<SESSION> <PROT_MSG_TYPE>
<DST_DESC>
Internet Draft OOPS: Policy Protocol for RSVP <SRC_DESC list>
<HOP_DESC>
<FILTER_SPEC list> <RSVP_HOP> [<ADV_DESC>]
<resv_handle> <RESV_FLOWSPEC> <POLICY_DESC list>
<counter (of in P.D.)>
<in POLICY_DATA objects>
This operation is used to forward POLICY_DATA objects from the This operation is used to forward POLICY_DESC objects from the
client to the server. Selection between hard and soft state client to the server. Selection between hard and soft state
management is reflected in the OOPS_HardState flag. The other management is reflected in the OOPS_HardState flag. The other
fields are copied from the PC_InPolicy() function called by fields are copied from the PC_InPolicy() function called by
RSVP. (See [Ext]). RSVP. (See [Ext]).
4.1.7 Incoming-Policy-Response 4.1.7 Incoming-Policy-Response
Operation Type = 6, sub-type = 1 Operation Type = 6, sub-type = 1
<Incoming-Policy-Query> ::= <Common OOPS header> <Incoming-Policy-Response> ::= <Common OOPS header>
<Query Sequence Number> <Q_ASSOC>
<Error-Description> <ERR_DESC>
Incoming-Policy-Response is used ONLY to report protocol errors Incoming-Policy-Response is used ONLY to report protocol errors
(e.g., syntax) found with incoming policy objects. (it is not (e.g., syntax) found with incoming policy objects. (it is not
used in the normal operation of the protocol). used in the normal operation of the protocol).
The <Query Sequence Number> links the response to the original
query.
4.1.8 Outgoing-Policy-Query 4.1.8 Outgoing-Policy-Query
Operation Type = 7, sub-type = 1 Operation Type = 7, sub-type = 1
<Outgoing-Policy-Query> ::= <Common OOPS header> <Outgoing-Policy-Query> ::= <Common OOPS header>
<RSVP MESSAGE TYPE> <Q_ASSOC>
<SESSION> <PROT_MSG_TYPE>
<FILTER_SPEC list> <DST_DESC>
<counter (of RSVP_HOPs)> <SRC_DESC list>
<RSVP_HOP list> <HOP_DESC list>
This operation queries the server for a set of outgoing policy This operation queries the server for a set of outgoing policy
objects for a set of RSVP_HOPs. The client can choose between objects for a set of HOP_DESCs. The client can choose between
hard and soft state management through the OOPS_HardState flag. hard and soft state management through the OOPS_HardState flag.
When hard state is selected, the client caches copies of the When hard state is selected, the client caches copies of the
outgoing objects and assumes they remain valid unless outgoing objects and assumes they remain valid unless
explicitly modified by the server. explicitly modified by the server.
4.1.9 Outgoing-Policy-Response 4.1.9 Outgoing-Policy-Response
Operation Type = 8, sub-type = 1 Operation Type = 8, sub-type = 1
Internet Draft OOPS: Policy Protocol for RSVP
<Outgoing-Policy-Response> ::= <Common OOPS header> <Outgoing-Policy-Response> ::= <Common OOPS header>
<Query Sequence Number> <Q_ASSOC>
<Counter (of triplets)> { <HOP_DESC>
{ <RSVP_HOP> <ERR_DESC> or <POLICY_DESC>
<Error-Description> } pairs list
<out POLICY_DATA objects>
} pair list
The <Query Sequence Number> links the response to the original The <Query Sequence Number> links the response to the original query.
query.
In the response, the server provides a list of triplets, one In the response, the server provides a list of triplets, one
for each outgoing RSVP_HOP (For Path messages, only the LIH for each outgoing HOP_DESC (For Path messages, only the LIH
part is significant). Each triplet contains a list of policy part is significant). Each triplet contains a list of policy
objects for that hop and an error description. objects for that hop and an error description.
The OOPS server can block an outgoing RSVP message by replacing
the outgoing POLICY_DESC list for a particular HOP_DESC with an
<Error-Description> with an appropriate value.
The ability to block outgoing RSVP control messages is
especially useful when policy is enforcement is performed at
border nodes of a network; RSVP control messages that are
allowed through are capable of installing state at internal
nodes without being subject to further policy control.
4.1.10 Status-Query 4.1.10 Status-Query
Operation Type = 9, sub-type = 1 Operation Type = 9, sub-type = 1
<Status_Query> ::= <Common OOPS header> <Status_Query> ::= <Common OOPS header>
<RSVP MESSAGE TYPE> <Q_ASSOC>
<SESSION> <PROT_MSG_TYPE>
<FILTER_SPEC_LIST> <DST_DESC>
<counter (of Triplets)> <SRC_DESC list>
{ <LIH> <resv_handle> <RESV_FLOWSPEC> } { <HOP_DESC>
<QOS_DESC>
} triplets list
This operation queries the server for status results of a list This operation queries the server for status results of a list
of LIHs. The client can choose between hard and soft state of LIHs. The client can choose between hard and soft state
management through the OOPS_HardState flag. When hard state is management through the OOPS_HardState flag. When hard state is
selected, the client caches the status results and assumes they selected, the client caches the status results and assumes they
remain valid unless explicitly modified by the server. remain valid unless explicitly modified by the server.
In the upstream direction (e.g., Resv) status may need to be In the upstream direction (e.g., Resv) status may need to be
checked on multiple LIHs (all reservations for a flow). In such checked on multiple LIHs (all reservations for a flow). In such
cases, status queries can be perform separately for each LIH, cases, status queries can be perform separately for each LIH,
once for all LIHs, or anything in between. Flag OOPS_FullList once for all LIHs, or anything in between. Flag OOPS_FullList
must be set at the last of status query of the series. [Note must be set at the last of status query of the series. [Note 18]
13]
_________________________ _________________________
[Note 13] When policies are interdependent across LIHs (as when the cost [Note 18] When sub-policies are interdependent across LIHs (as when the
is shared among downstream receivers), flag OOPS_FullList notifies the cost is shared among downstream receivers), flag OOPS_FullList notifies
server that the list of reserved LIH is complete and that it can safely the server that the list of reserved LIH is complete and that it can
compute the status of these reservations. safely compute the status of these reservations.
Internet Draft OOPS: Policy Protocol for RSVP
4.1.11 Status-Response 4.1.11 Status-Response
Operation Type = 10, sub-type = 1 Operation Type = 10, sub-type = 1
<Status_Response> ::= <Common OOPS header> <Status-Response> ::= <Common OOPS header>
<Query Sequence Number> <Q_ASSOC>
<Counter (of triplets)> { <HOP_DESC>
{ <LIH> <STATUS_DESC>
<Status Result> [<ERR_DESC>]
<Error-Description> } triplet list
} pair list
The <Query Sequence Number> links the response to the original The <Q_ASSOC> links the response to the original query.
query.
In the response, the server provides a list of triplets, each In the response, the server provides a list of triplets, each
of which contains an LIH, status, and any applicable error of which contains an LIH, status, and any applicable error
results. The set of LIHs is an attribute of the results and results. The set of LIHs is an attribute of the results and
not of the query; the server is allowed to respond with a not of the query; the server is allowed to respond with a
superset of LIHs specified in the original query, as in the superset of LIHs specified in the original query, as in the
following example: following example:
Seq# Type Data SEQ# TYPE DATA
--- ---- ---- --- ---- ----
Client ==> Server: 150 Query:status Resv-X, LIH={2} Client ==> Server: 150 Query:status Q_ASSOC=ID2, Resv-X, LIH={2}
Server ==> Client: 153 Resp :status #150:{2,rej} Server ==> Client: 153 Resp :status Q_ASSOC=ID2, {2,rej}
Two new reservations arrive, carrying new policy data objects: Two new reservations arrive, carrying new policy data objects:
Client ==> Server: 160 Query:status Resv-X, LIH={4,7} Client ==> Server: 160 Query:status Q_ASSOC=ID3, Resv-X, LIH={4,7}
Server ==> Client: 169 Resp :status #160:{2,acc;4,acc;7,rej} Server ==> Client: 169 Resp :status Q_ASSOC=ID3, {2,acc;4,acc;7,rej}
4.1.12 Delete-State-Notification 4.1.12 Delete-State-Notification
Operation Type = 11, sub-type = 1 Operation Type = 11, sub-type = 1
<Delete-State-Notification> ::= <Common OOPS header> <Delete-State-Notification> ::= <Common OOPS header>
<RSVP MESSAGE TYPE> <STATE_OP_DESC>
<SESSION> <DST_DESC>
<FILTER_SPEC_LIST> [<PROT_MSG_TYPE>]
<RSVP_HOP> [<SRC_DESC list>]
<Op-type> [<HOP_DESC>]
[<ERR_DESC>]
o STATE_OP_DESC
This object describes the type of requested operation (see
Appendix A).
This operation informs the sender about an immediate RSVP This operation informs the sender about an immediate RSVP
teardown of state caused by PATH_TEAR, RESV_TEAR, routes teardown of state caused by PATH_TEAR, RESV_TEAR, routes
change, etc. As a result, the server should ignore the change, etc. As a result, the server should ignore the
described state as if it was never received from the client. described state as if it was never received from the client.
Internet Draft OOPS: Policy Protocol for RSVP
Despite its name, this operation can be used to switch between Despite its name, this operation can be used to switch between
blockaded and non-blockaded state. blockaded and non-blockaded state.
The semantics of this operation is described for PC_DelState() The semantics of this operation is described for PC_DelState()
in [Ext]. in [Ext].
4.1.13 Schedule-RSVP-Notification Error description is used to provide the server with a reason
for the delete (for logging purposes).
4.1.13 Protocol-Message-Notification
Operation Type = 12, sub-type = 1 Operation Type = 12, sub-type = 1
<Schedule-RSVP-Notification> ::= <Common OOPS header> <Protocol-Message-Notification> ::= <Common OOPS header>
<RSVP MESSAGE TYPE> <PROT_MSG_TYPE>
<SESSION> <DST_DESC>
<FILTER_SPEC list> <SRC_DESC list>
<RSVP_HOP> <HOP_DESC>
The operation results in the generation of an outgoing RSVP The operation results in the generation of an outgoing protocol
message (Path, Resv, etc.) in the client's RSVP. RSVP should message (e.g., RSVP's Path, Resv). The client should schedule
schedule the requested message to the specified RSVP_HOP. the requested message to the specified HOP_DESC.
4.1.14 Client-Status-Notification 4.1.14 Client-Status-Notification
Operation Type = 13, sub-type = 1 Operation Type = 13, sub-type = 1
<Client-Status-Notification> ::= <Common OOPS header> <Client-Status-Notification> ::= <Common OOPS header>
<Query Sequence Number> <Q_ASSOC>
<Status Result> <STATUS_DESC>
The Client notifies the server about the status results The Client notifies the server about the status results
computed at the client (that may also include results from computed at the client (that may also include results from
other servers, if policy computation is spread among several other servers, if policy computation is spread among several
servers). servers).
The overall status of an RSVP flow is computed by merging the The overall status of an RSVP flow is computed by merging the
client's status report with the server's. The server should not client's status report with the server's. The server should not
commit a transaction (e.g., charge an account) before knowing commit a transaction (e.g., charge an account) before knowing
its final status. The Client-Status-Results operation can be its final status. The Client-Status-Results operation can be
sent with the query, if the client computed its status prior to sent with the query, if the client computed its status prior to
making the query. It can also be sent later, after the server making the query. It can also be sent later, after the server
sent its response to the status query. sent its response to the status query.
4.1.15 Resend-Notification 4.1.15 Error-Notification
Operation Type = 14, sub-type = 1 Operation Type = 14, sub-type = 1
<Resend-Notification> ::= <Common OOPS header> <Message-Error-Notification> ::= <Common OOPS header>
<Counter (of missing messages)> <Message-Sequence-Number>
<Message sequence number> list <ERR_DESC>
Internet Draft OOPS: Policy Protocol for RSVP Message-Error-Notification can be used by either client or
server to report errors associated with an entire message (as
opposed to a specific operation). Error-Notification may be
triggered by both syntax or substantive errors (e.g., failure
to verify the integrity of the message).
Both client and server may issue a Resend-Messsage request when <Message-Sequence-Number> identified the message that triggered
they detect missing or out-of-order messages. The Resend- the error. It uses identical format to the one used by the OOPS
Notification has message sequence number 0. The message message header.
explicitly lists the sequence numbers of all missing messages.
Notice that since OOPS uses a reliable transmission protocol
this list should never be long. (See Section 3.2).
4.1.16 Error-Notification Message-Error-Notification is not acked.
Operation Type = 6, sub-type = 1 5. Acknowledgment
<Error-Notification> ::= <Common OOPS header> This document reflects feedback from Paul Amsden, Fred Baker, Lou
<Message Sequence Number> Berger, Bob Braden, Ron Cohen, Deborah Estrin, Steve Jackowski, Tim
<Error-Description> O'Malley, Claudio Topolcic, Raj Yavatkar, and many other IPC and RSVP
collaborators,
Error-Notification can be used by either client or server to 6. Authors' Address
report errors associated with an entire message (as opposed to
a specific operation). Error-Notification may be triggered by
both syntax or substantive errors (e.g., failure to verify the
integrity of a previous message).
<Message Sequence Number> identified the message that triggered Shai Herzog Phone: (917) 318-7938
the error. IP"Highway" Email: herzog@iphighway.com
Error-Notification is not acked. Dimitrios Pendarakis Phone: (914) 784-7536
Email: dimitris@watson.ibm.com
Raju Rajan Phone: (914) 784-7260
Email: raju@watson.ibm.com
Roch Guerin Phone: (914) 784-7038
Email: guerin@watson.ibm.com
4.2 Fields format IBM T. J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
o <Ver> <RSVP-K> <Flags> 7. References
+---------------+---------------+---------------+---------------+ References
| Version | RSVP-K | Flags | 0 |
+---------------+---------------+---------------+---------------+
Ver: Currently, version 1. [IPSEC] R. Atkinson, Security Architecture for the Internet Protocol,
"RFC1825", Aug. 1997.
RSVP-K: The K value used by RSVP as a refresh-period [Bak96] F. Baker. RSVP Cryptographic Authentication "Internet-Draft",
multiplier. draft-ietf-rsvp-md5-02.txt, 1996.
Flags: [RSVPSP] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin,
0x01 OOPS_CONNECT_DefaultC Client handles default policies. Resource ReSerVation Protocol (RSVP) Version 1 Functional
Specification. "Internet-Draft", draft-ietf-RSVPSP-14.[ps,txt],
Nov. 1996.
o <Max-Pkt-Size><Keep-Alive period> [Arch] S. Herzog Accounting and Access Control Policies for Resource
Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-policy-
arch-01.[ps,txt], Nov. 1996.
[LPM] S. Herzog Local Policy Modules (LPM): Policy Enforcement for
Resource Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-
policy-lpm-01.[ps,txt], Nov. 1996.
[Ext] S. Herzog RSVP Extensions for Policy Control. "Internet-Draft",
draft-ietf-rsvp-policy-ext-02.[ps,txt], Apr. 1997.
A Appendix: OOPS Objects
This section describes objects that are used within OOPS OP-Codes. All
objects have a common header:
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Max-Pkt-Size (in KBytes) | Keep-Alive period (in seconds)| | Length | Class | C-Type |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Internet Draft OOPS: Policy Protocol for RSVP Length describes the length of the entire object, in bytes. Class
describes the type of object and C-Type describes the a class sub-type.
o <Class Indicator> o CLASS_ID class
- Class = 1, C-Type = 1
+---------------+---------------+---------------+---------------+
| Length (total) | Class Code |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| ASCII String ........ 0 Padded to multiples of 32 bits | | ASCII String ........ 0 Padded to multiples of 32 bits |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
o <Client-ID> o CLIENT_ID class
Client address, uses the same format as RSVP's FILTER_SPEC - Class = 2, C-Type = 1
objects.
From the combination of Client-ID and Class-Indicator the A Network Address.
server can learn about the set of policies it is required to
support for this particular client.
o <Cookie> +---------------+---------------+---------------+---------------+
| IPv4 Address |
+---------------+---------------+---------------+---------------+
- Class = 2, C-Type = 2
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Length (total) | Type | 0 | | IPv6 Address |
| |
| |
| |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Octet String ........ 0 Padded to multiples of 32 bits | From the combination of Client-ID and Class-Indicator the server
can learn about the set of sub-policies it is required to support
for this particular client; it can also learn which of these sub-
policies are optional and which are mandatory.
o RESP_INT class
- Class = 3, C-Type = 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Most-Prefered |..... | | |
+---------------+---------------+---------------+---------------+
| | Least-Pref. |...0 Padded to 32 bit multiples|
+---------------+---------------+---------------+---------------+
o COOKIE class
- Class = 4, C-Type = 1
Currently, no values are defined. Currently, no values are defined.
o <Policy list> o PLIST class
- Class = 5, C-Type = 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Number (or pairs) | 0 | | Number (or pairs) | ////// |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| From Policy 1 | To Policy 1 | | From Policy 1 | To Policy 1 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| From Policy n | To Policy n | | From Policy n | To Policy n |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Each "From Policy m" and "To Policy m" pair represent a range Each "From Policy m" and "To Policy m" pair represent a range of
of policies that the server is willing to support. sub-policies that the server is willing to support.
o <Error-Description> o ERR_DESC class
- Class = 6, C-Type = 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Length (*) | Error-Type | Reason Code | | Error-Code | ////// | Reason Code |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Error ASCII String .... 0 Padded to multiples of 32 bits | | Error ASCII String .... 0 Padded to multiples of 32 bits |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Internet Draft OOPS: Policy Protocol for RSVP Detailed Error-Code and Reason-Codes would be defined in future
versions of this document.
(*) Length of the overall <Error-Description> in 4 bytes o Q_ASSOC class
increments (i.e., length value of X should be interpreted as
X*4 bytes description and an (X-1)*4 bytes Error ASCII
String.
No errors are reported by setting the length to 1 (4 bytes) - Class = 7, C-Type = 1
and setting the Error-Type to 0.
Detailed Error-Types and Reason-Codes would be defined in +---------------+---------------+---------------+---------------+
future versions of this document. | Client-Specific Semantics |
// (Variable Length) //
| |
+---------------+---------------+---------------+---------------+
o <resv_handle> The client-specific contents of this object is opaque to the
server; it is set by the client for a query and is echoed by
the server as-is. The client must store enough information
there that will enable it to uniquely identify the original
query when the response arrive. This must at least include a
counter to identify the version of the latest query. [Note 19]
_________________________
[Note 19] A simple association could be the combination of a pointer to
an internal client (router) control-block that describes the query, and
a query version counter.
o PROT_MSG_TYPE class
- Class = 8, C-Type = 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| IntServ or Client-Specific Semantics | | RSVP MSG TYPE |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
The server may use the <resv_handle> to obtain IntServ and Values specified in [RSVPSP].
other low-level information about the reservation.
The current version of this document does not define the o DST_DESC class
semantics of this field. It may be a pointer into some router
specific data structures (proprietary) or an index into mib
records obtainable through SNMP.
o <Query Sequence Number> (and internally, <Message Sequence - Class = 9, C-Type = 1
Number>)
The RSVP SESSION object as defined in [RSVPSP].
o SRC_DESC class
- Class = 10, C-Type = 1
The RSVP FILTER_SPEC object as defined in [RSVPSP].
o HOP_DESC class
- Class = 11, C-Type = 1
The RSVP_HOP object as defined in [RSVPSP].
o ADV_DESC class
- Class = 12, C-Type = 1
The RSVP ADSPEC object as defined in [RSVPSP].
o QOS_DESC class
- Class = 13, C-Type = 1
The RSVP FLOWDESC object as defined in [RSVPSP].
o POLICY_DESC class
- Class = 14, C-Type = 1
The RSVP POLICY_DATA object as defined in [Ext] and [RSVPSP].
o OOPS_MSG_AUTH class
- Class = 15, C-Type = 1
The RSVP INTEGRITY object as defined in [RSVPSP] and [Bak96].
o STATUS_DESC class
- Class = 16, C-Type = 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| <Message Sequence Number> | | Results | Priority | ////// |
+---------------+---------------+---------------+---------------+
| Obj. Seq. Num.| 0 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
o <Counter> Results may have one of the following values:
1 : Accept
2 : Snub
3 : Veto
Priority ranges between 1..255 (see 2.2.3).
o CONNECT_DESC class
- Class = 17, C-Type = 1
This object describes the OOPS connection parameters; in the
Connection-Accept-Response, the refresh-multiplier is an echo
of the value received with the Connection-Initiation-Query.
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| <Counter> | | Version | Flags | Refresh-Mult. | ////// |
+---------------+---------------+---------------+---------------+
| Max-Msg-Size (in KBytes) | Channel-Hold period (in sec.) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
o <Status Result> Ver: 8 bits
Currently, version 1.
Flags:
0x01 OOPS_CONNECT_DefaultC Client handles default sub-policies.
Refresh-Mult.:
The refresh-period multiplier (e.g., RSVP's K value).
Max-Msg-Size: Upper limit on the length of an OOPS message
Channel-Hold period: Implicit disconnection timeout
o BYE_DESC class
- Class = 18, C-Type = 1
BYE_DESC provides details about the Bye-Notification request.
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Results | 0 | | Bye-Flags | ////// | BYE_DELAY (seconds) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Results may have one of the following values: Bye-Flags:
0x01 An echo (response) to a received Bye-Notification
Internet Draft OOPS: Policy Protocol for RSVP The BYE_DELAY could provide both sides with some time delay to
be better prepared to a pending bye. [Note 20]
The delay value is determined by the originator of the bye-
notification, and is echoed in the bye response. The delay
effect should be as if the Bye-Notification was sent BYE_DELAY
seconds later with a delay timer value of 0.
1 : Accept o STATE_OP_DESC class
2 : Snub
3 : Veto
o <Op-Type> - Class = 19, C-Type = 1
_________________________
[Note 20] Similar to the delayed shutdown command known in Unix.
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Mod-Type | 0 | | Op-Type | ////// |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Op-Type values: Op-Type values:
1 : Delete State 1 : Delete State
2 : Block State 2 : Block State
3 : Unblock State 3 : Unblock State
5. Acknowledgment B Appendix: Error Codes
This document reflects feedback from many other RSVP collaborators.
Internet Draft OOPS: Policy Protocol for RSVP
References This appendix describes an initial list of error codes available in
OOPS, as well as the set of Reason Codes for each error code. (Reason
Code of 0 must be used when Reason Codes are not applicable). This list
should evolve and not be considered conclusive. [Note 21]
[Bak96] F. Baker. RSVP Cryptographic Authentication "Internet-Draft", o Code = 1, Connection Management
draft-ietf-rsvp-md5-02.txt, 1996.
[RSVPSP] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, 1: Connection Reject: Server does not support client version.
Resource ReSerVation Protocol (RSVP) Version 1 Functional 2: Bye: Reset due to routine state re-synchronization
Specification. "Internet-Draft", draft-ietf-RSVPSP-14.[ps,txt], 3: Bye: Reset due to connection problems (Bad message formats)
Nov. 1996.
[Arch] S. Herzog Accounting and Access Control Policies for Resource o Code = 2, Protocol problems
Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-policy-
arch-01.[ps,txt], Nov. 1996.
[LPM] S. Herzog Local Policy Modules (LPM): Policy Enforcement for 1: Syntax: Bad OOPS message
Resource Reservation Protocols. "Internet-Draft", draft-ietf-rsvp- 2: Syntax: Bad OOPS Op-Code
policy-lpm-01.[ps,txt], Nov. 1996. 3: Syntax: Bad POLICY_DESC format
[Ext] S. Herzog RSVP Extensions for Policy Control. "Internet-Draft", o Code = 3, Policy Decisions
draft-ietf-rsvp-policy-ext-02.[ps,txt], Apr. 1997.
Authors' Address 1: Don't forward: refrain from forwarding an outgoing message.
2: Policy Reject: cancel protocol operation (Reservation, path, etc.)
Shai Herzog Phone: (914) 784-6059 o Code = 4, State Management
Email: herzog@watson.ibm.com
Dimitrios Pendarakis Phone: (914) 784-7536
Email: dimitris@watson.ibm.com
Raju Rajan Phone: (914) 784-7260
Email: raju@watson.ibm.com
Roch Guerin Phone: (914) 784-7038
Email: guerin@watson.ibm.com
IBM T. J. Watson Research Center 1: Delete State: Reservation Canceled
P.O. Box 704 2: Delete State: route change
Yorktown Heights, NY 10598 3: Delete State: State Timeout
4: Blockade State
5: Unblock State
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/