Internet Draft                                               Shai Herzog
Expiration: Oct. 1997                                          IPHighway
File: draft-ietf-rsvp-policy-oops-01.txt
                                                    Dimitrios Pendarakis
File: draft-ietf-rsvp-policy-oops-00.txt
                                                              Raju Rajan
                                                             Roch Guerin
                                         IBM T.J. Watson Research Center
                                                               Apr. 1997

            Open Outsourcing Policy Service (OOPS) for RSVP

                                03/19/97

                                07/30/97

Status of Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

Abstract

   This document describes a protocol for exchanging policy information
   and decisions between an RSVP-capable router (client) and a policy
   server. The OOPS protocol supports a wide range of router
   configurations and RSVP implementations, and is compatible with the
   RSVP Extensions for Policy Control [Ext].

Internet Draft       OOPS: Policy Protocol for RSVP

Table of Contents

1

1. Overview                                                        4

      1.1   Representative OOPS Scenarios  .......................... 4

2     Query-Response Protocol                                         6

      2.1   Division of Labor Reservation protocols function by discriminating 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
   users by providing some users with better service 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 the expense of
   others.  The utility of reservation protocols is sharply degraded in
   the absence of mechanisms 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 restricting access to higher service
   categories and enforcing network and bandwidth usage criteria. In
   this document, we refer to such mechanisms as "policy control". This
   term is quite broad; it ranges from simple access control to
   sophisticated accounting and debiting mechanisms.

   The policy control component may reside fully within the router (as
   an add-on module to RSVP). However, it is often advantageous for RSVP

1. Overview
   routers to outsource some of their policy decision making to external
   entities.  Open Outsourcing Policy Service (OOPS) is a protocol for
   exchanging policy information and decisions between an Local Policy
   Modules (LPMs) located within RSVP-capable router
   (client) routers and a policy server.  As the name suggests, OOPS is an
   outsourcing protocol which allows the partial one or complete delegation
   of the task of policy control from the local router to an more
   external
   server. Moreover, it policy servers. OOPS is an open protocol in a sense that it
   does not define or depend on particular policies; instead, it
   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
   Extensions for Policy Control [Ext], both in the format of RSVP
   objects, as well as the set of supported services.

   The basic features of OOPS design are as follows:

   Asymmetry between client and server

        Adding policy support to RSVP may require substantial
        modifications to platforms (e.g., routers) which may not have
        the required implementation flexibility and/or processing power.
        OOPS assumes that the server is more sophisticated than the
        client, in terms of processing power and support for diverse
        policies.

   Support for a wide range of client implementation

        The OOPS protocol supports a wide range of client
        implementations.  At one end of the spectrum, a "dumb" client
        may delegate total responsibility to the server for all policy
        decisions without even maintaining cached states.  At the other
        end, smart clients can perform most policy processing locally
        and only address the server for a small number of policies sub-policy
        elements and only when they things change (otherwise, cache can be
        used).

   Minimal

   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.

        The server must be aware of the format of several RSVP objects
        and basic RSVP message types. However, it is not required to
        understand RSVP's processing rules (e.g., different reservation
        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

        Both client and server may asynchronously generate queries or
        requests.

Internet Draft       OOPS: Policy Protocol for RSVP

   TCP for reliable communications

        TCP is used as a reliable communication protocol between client
        and server.

   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
      along an RSVP path, as envisioned in OOPS.  Nodes A, B and C
      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.

                             AD-1                AD-2       AD-3
               _______________/\___________     __/\__     __/\__
              {                            }   {      }   {      }

              +------+   +------+   +------+   +------+   +------+
      +----+  |  A   |   |  B   |   |  C   |   |  D   |   |  E   |  +----+
      | S1 |--| RSVP |---| RSVP |---| RSVP |---| RSVP |---| RSVP |--| R1 |
      +----+  +------+   +------+   +------+   +------+   +------+  +----+
              | LPM  |              | LPM  |   | LPM  |   | LPM  |
              +------+              +------+   +------+   +------+
                    \                /                       |
                     \              /                     +------+
                      \            /                      |Policy|
                       \          /                       |Server|
                        \        /                        | PS-2 |
                         \      /                         +------+
                         +------+
                         |Policy|
                         |Server|
                         | PS-1 |
                         +------+

               Figure 1: Policy Control along an RSVP path

      The scenario includes

      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
      node: Node D is self-sufficient does not need to outsource policy tasks to external
      servers since its local LPM satisfies its entire policy needs. (It has no need for server advice.)  (3)
      "Dumb" policy nodes: Node E is an unsophisticated node that lacks
      processing power, code support or caching capabilities, and needs
      to rely on PS-2 for every policy processing operation.  In this
      case, the volume of traffic and delay requirements make it

Internet Draft       OOPS: Policy Protocol for RSVP
      imperative to connect PS-2 to node Node E by to PS-2 a direct link or a LAN.  (4)
      "Smart" policy nodes:  Nodes A and C include sophisticated LPMs,
      in that these nodes can process some policies, sub-policy elements, and have
      the capacity to cache responses from PS-1.  In this case, the
      contact between the clients and server will would 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
      upstream toward sender S1.  Assuming that the reservation is
      successful, the conceptual flow of policy objects is:

      R1 -- E -- ELPM -- PS-2 -- ELPM -- E -- D -- DLPM -- D -- C -- CLPM
      -- PS-1 -- CLPM -- C -- B -- A -- ALPM -- PS-1 -- ALPM -- A -- S1.

      Of course, other OOPS messages may be exchanged between policy
      servers and nodes before authorizing the reservation at individual
      nodes.

2. Query-Response Protocol

   OOPS is

      The functioning of the policy module at a transaction protocol, in which most communication policy aware router is in the
   form of queries from
      presented through the client followed by responses from 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
   server.  However, local policy module provide support for
      a small portion number of the communication sub-policy elements, each embodied by a policy sub-
      module (PSM).  The policy object forwarded by RSVP may also
   consist contain a
      number of queries originating from the server, or 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
   form of queries from the client followed by responses from the
   server.  However, a small portion of the communication may also
   consist of queries originating from the server, or of unidirectional
   notifications from one entity to another.  In this context, it is
   important that messages be distinguished by a unique sequence number, association, so
   that responses may identify the query to which they correspond.

   This section discusses two four fundamental concepts of the OOPS
   protocol:  (a) query/response mechanism, (b) flexible division of
   labor between client and server.  (b) server, and (c) consistent management of
   client, server and RSVP state.

   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
      responsibilities between server and client. Processing of policies
      (policy elements First, the client must
      be able to decide how to distribute the processing and second, it
      must be able to merge the distributed responses into one unified
      result.

      2.2.1 Distributed Processing

         Processing of sub-policies (sub-policy elements within POLICY_DATA
         POLICY_DESC objects) can be performed by the server, the
         client, or by both.  The decision on which
      policies 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).

      Before the

         The client forwards incoming POLICY_DATA objects may remove sub-policy elements which are not to be
         processed by the
      server (Incoming-Policy-Query) it removes or marks server. In this case, the client is solely
         responsible for checking the integrity of the incoming policy
      elements it wishes
         object; [Note 3]
_________________________
[Note 1] Execution order is implementation and policy specific; any
order that does not violate the server policy specific requirements is assumed
to be reasonable.

[Note 2] Senders must be informed about the receiver's failure to ignore.  (Marking
process their messages. This is performed by
      changing especially critical given that OOPS
relies on TCP's reliability and lacks additional reliability mechanisms.

[Note 3] If any portion of the policy element P-type POLICY_DESC object is modified, the
digest integrity verification at the server is bound to zero.)  When forwarding
      incoming policy objects, fail.

         the client may must also set the OP-Code header flags flag to inform the
         server to that message integrity and/or rsvp hop has been

Internet Draft       OOPS: Policy Protocol fact.

         During connection establishment, the server may request to have
         oversight over the clients local decisions; in this case, the
         client should forward incoming policy objects in their
         entirety, and consult the server for all RSVP

      already checked. flows, regardless
         of whether they include POLICY_DATA objects. This oversight is
         transparent to the client and is therefore post factum. [Note
         4]

         OOPS does not impose limitations on the number of servers
         connected to the client; when appropriate, the client could
         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.

      When the

      2.2.2 Unification of Distributed Responses

         Division of labor between client receives outgoing POLICY_DATA objects in response
      to a previous query (Outgoing-Policy-Response) it is responsible
      for merging the and server response with the locally generated
      outgoing POLICY_DATA object.  Merging is performed by
      concatenating only possible to
         the local and server policy elements and if
      necessary, computing some of extent that the POLICY_DATA object fields (e.g.,
      length, INTEGRITY, etc.)

      When client has the capability to unify or merge
         results; the client receive status results in response must be able to a previous
      query (Status-Policy-Response) it is responsible for merging merge the results of
         queries arriving from the server servers with the local results.  The following
      rule applies for combining any number of policies, and
      specifically, its own local and server policies:

      o    When responding results, to
         produce a status query (authorization check),
           individual policy handlers may vote single unified response to ACCEPT, SNUB or VETO
           the request. As their names suggest, a vote of accept
           authorizes the request; a snub fails it, but remains
           indifferent on its final outcome (i.e., other policies could
           provide authorization); a veto vote excludes the possibility
           of authorizing the request, even if other policy handlers
           cast accept votes.

      o    The merge result provides an authorization if there underlying protocol
         (e.g., RSVP).

         Results unification is at
           least one accept, and no vetoes. [Note 1]
            (See [LPM]) straight-forward for more details).

      o    The client and/or server should complete outgoing
         POLICY_DESC object; since sub-policy elements are independent,
         their policy
           processing even if a veto was cast unification is performed by some policy. [Note 2]

_________________________ concatenating all local and
         server elements and packing them in POLICY_DESC objects. [Note 1] A veto has a stronger semantics than a snub,
         5]

         Unification is more complex for status queries, since it has the
power
         various responses must truly be merged to forcefully reject produce a flow regardless of any accept decisions
made by others.

[Note 2] A wide range of policies may not care about the final single
         status
results result.  OOPS defines one basic (default) status
         response interface (object and unification rules).
_________________________
[Note 4] The client should be activated regardless.  For instance: a policy that
logs all policy queries.

Internet Draft       OOPS: Policy Protocol for RSVP

      o    Protocol errors are always considered as snubs, and thus,
           neutral.

      It is recommended (although not required) that all wait for an oversight decision; if the
server overrides a local status
      processing at decision, it may notify the client be completed before querying sometime
later, even after the server.
      This allows local client authorized the server to immediately commit RSVP operation.

[Note 5] An oversight sub-policy element would override the transaction
      rather than having to wait until locally
generated element, if the client is done.  (See two are of the
      Client-Status-Notification operation.)

      2.1.1 Error Reporting

         Policy error reporting same type.

         However, given that OOPS is policy specific; an extensible framework, it is performed by
         sending POLICY_DATA objects with specific error objects toward allows
         the originator of the error. The rules governing error
         reporting are client and server to negotiate a more sophisticated
         interface (see Section 3.1).  Additional response interfaces
         could be described in [Ext].

         In this document, we discuss only error reporting between separate documents which should define
         the
         client response object format and the server, which unification rules. [Note 6]

      2.2.3 Default Status Response

         The default status response object is intended to help of the client
         determine whether error reporting is required at all.

         There are C-Type 1.  C-Type
         1 objects may contain two types of possible errors; values: a policy errors admission decision
         (PAD) and
         protocol errors.  For a preemption priority value (PP).  It is reasonable
         to assume that some clients would not be able to utilize the purpose of
         flow preemption priority information; such clients are free to
         ignore this protocol, policy
         errors value and assume that all flows are considered as legitimate results (e.g., reject) created equal.
         (have priority 0).

         PADs may have one of three values: ACCEPT, SNUB, 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 VETO.
         ACCEPT authorizes the overall policy decision).

         When query, SNUB signifies neutrality (neither
         accept nor reject).  A VETO from the client (or server) discovers server or LPM has a protocol error (syntax,
         missing parameters, etc.),
         stronger semantics than a snub, since it is reported alongside and
         orthogonal to has the status results (accept, power to
         forcefully reject or veto).

Internet Draft       OOPS: Policy Protocol a flow regardless of any accept decisions
         made by the other.

         The rules for RSVP

   2.2 unification of PAD values A and B are straight-
         forward:

                   +----------------------+---------------------+
                   |  A+B                 | IF...               |
                   +----------------------+---------------------+
                   |  SNUB                | A=SNUB and B=SNUB   |
                   |  VETO                | A=VETO or  B=VETO   |
                   |  ACCEPT (+PP value)  | Otherwise           |
                   +----------------------+---------------------+

         A unified result of ACCEPT provides approval for the status
         query; both SNUB and VETO signal the rejection of the query.

         Note that a client and/or server should complete their policy
         processing even if a veto was cast by some policy. [Note 7]
_________________________
[Note 6] A separate template document and a list of more sophisticated
responses should be prepared.

[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.

         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
      processed quickly and correctly, it is often required that the
      results of past policy decisions be cached and maintained at the
      LPM or the policy server.  Maintenance of policy During normal operations, the state must be
      done
      maintained in a manner that is consistent with the division of
      responsibility for policy processing between client and in the server must remain consistent,
      and
      with RSVP's state management rules. [Note 3] must timeout at roughly the identical times in RSVP, the
      client, and the server.

      The most straightforward method for state maintenance is for the
      LPM and the policy server to use the same soft-state mechanism as
      the RSVP capable router. Unfortunately, this soft-state approach
      has undesirable scaling properties since it requires the client to
      contact the server on each refresh period (regardless of state
      changes).

      An alternative approach is to allow both client and server to use
      hard-state mechanisms that could limit the client-server
      communication to state updates only.  This alternative implies that To support the hard-state
      mode, the client must be capable of recognizing objects that would result in
      a change of policy state, as well as being able to translate distinguish between repeats
      (refreshes) and updates; it must also be able to translate the
      soft-state that is provided by RSVP and into the hard-state exchanged
      with the server.

      Thus, we envision one end of the spectrum where a "dumb" client
      would use a soft-state approach and simply pass all policy objects
      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
      a dedicated, close-by server (PS-2, in our example). As we move
      towards the other extreme, clients become smarter, more capable of
      caching, and dividing split the work
      between themselves and the server. server, utilize caching capabilities.
      Such clients could take advantage of the benefits of hard-state
      management, and initiate queries only on actual state updates.

      OOPS supports soft and hard state mechanisms seamlessly, as
      described in this section. The client determines its desired type
      of state management, and communicates it on an object-by-object
      basis.  A single client can use soft-state for some information,
      and hard state for others.  Furthermore, the OOPS protocol allows
      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
      not impose strategy limitations, a client implementation could
      restrict itself to a more modest and simple combination of soft
      and hard state.

      There are two types of state information that is stored at the
      client:  (a) client state information that was forwarded to the
      server (e.g., policy objects in incoming Path/Resv messages).  (b)
      server state which is cached at the client (e.g., policy results
      computed by the server). The OOPS protocol addresses each of these
      types of states:

      2.2.1 states separately:

      2.3.1 Client State Information Cached at the Server

         The client indicates that it desires hard (or soft) state
         management its choice of client state information cached at the server management approach by
         setting (or resetting) the OOPS_HardState flag in objects sent
         to the server.  When the client chooses soft-state management
         for a particular object, management,
         policy state for that specific object would age ages and expire expires at the
         server according to the timeout specified in
         the object. The client must, therefore, forward each policy
         refresh (update or not) to the server, to keep timeout (refresh-period * K).
         Therefore, the soft-state state cached at the server from becoming stale and expiring. is kept alive by
         constant refreshing (the client must forward ALL incoming RSVP
         messages, whether or not they represent refreshes or updates).
         On the other hand, when the client indicates indicating a choice of hard-state
         management, it the client assumes responsibility for reliably
         informing the server on every policy update.  In this case, the
         state cached at the server would not expire unless explicitly
         modified by the client, or when the communication channel to
         the client breaks. [Note 8]
          The client may refrain from forwarding to the server any
         repeat policy objects that are identical to objects previously sent to the
         server. (which represent no updated information).

         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
         the server.

      2.2.2

      2.3.2 Server State Information Cached at the Client

         The client indicates that it is capable of hard (or soft) indicate its state management of server state information capabilities by
         setting (or resetting) the OOPS_HardState flag in queries sent
         to the server. Here, hard state management refers to the caching A choice of
         response results at the client. Soft state management means soft-state indicates that the client, being client
         is incapable of caching, would purge them and it purges the server responses
         after usage (one-time, or disposable results).

         A non-cached response has no strings attached, but Clearly, without
         caching, the client must issue a new query each time that
         responses are needed.

         When

Internet Draft       OOPS: Policy Protocol for RSVP the server responds to a cached (hard-state) query, it
         assumes responsibility to reliably inform the client about any
         changes that may occur later to with the original results of response to this
         query.  The client may rely on cached results as long as the there
         is no change in RSVP's state (which includes incoming policy
         objects), [Note 4] 9]
          and the communication channel with the server is intact.

         The client may switch between hard and soft states on the fly
         by issuing a new query with a modified flag.

      2.2.3

      2.3.3 State Change Notification

         State change notification is done by resending the same type as
         the original message but with the modified state instead.

         Client notification example (incoming POLICY_DATA POLICY_DESC objects for
         Resv-X):

                             Seq#  Type           Data
                             ---   ----           ----
         Client ==> Server:   50   Notify:input   Resv-X: PD-1

         Time passes;

_________________________
[Note 9] A configurable option may allow the input POLICY_DATA object associated with
         Resv-X changed to PD-2.

         Client ==> Server:   90   Notify:input   Resv-X: PD-2

         Server notification example (status query for reservation
         Resv-X):

                              Seq#   Type            Data
                              ---    ----            ----
         Client ==> Server:  150   Query:status   Resv-X
         Server ==> Client:  151   Resp :status   #150: accept

         Time passes; the status of Resv-X changed to "reject".
_________________________
[Note 4] A configurable option may allow the client client to use cached
results even when some RSVP state changes.  Clearly, there  There is a trade-
off 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.

Internet Draft       OOPS: Policy Protocol for RSVP

                                  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.

         CLIENT ==> SERVER:       NOTIFY:INPUT   RESV-X: PD-2

         Server notification example (status query for reservation
         Resv-X):

                                  TYPE            DATA
                                  ----            ----
         CLIENT ==> Client:  205   Resp :status   #150: reject

3. Client-Server Communications

   This section describes SERVER:       QUERY:STATUS   Q_ASSOC=ID1, RESV-X
         SERVER ==> CLIENT:       RESP :STATUS   Q_ASSOC=ID1, ACCEPT

         Time passes; the fundamentals status of client-server
   communications: connection establishment, communication channel
   management, and connection termination.

   3.1 Connection Establishment

      Connections are always initiated by clients. The client
      establishes a TCP connection Resv-X changed to its preferred policy server, "reject".

         SERVER ==> CLIENT:       RESP :STATUS   Q_ASSOC=ID1, REJECT

      2.3.4 State Re-synchronization

         Both client and
      then initiates the OOPS session through a two way handshake.

      o    Communication Initiation by server may re-synchronize their respective
         states at any time during the Client connection. The client reset initiator
         sends a Connection-Initiation-Query to the server.
           This message identifies the client to the server Bye-Notification with a RESET code, and provides
           the basic characteristics of the client.

      o    Response by the Server

           The server receiver
         responds with a Connection-Accept-Response to
           connect to the client. It may also respond Bye-Notification with a
           Connection-Reject-Response to refuse and disconnect from the
           client. same code.  After connection establishment both the client and server
           know the set of policies that the client can send to the
           server,
         this exchange, all cached state becomes soft, and which one of them should handle default
           (unrecognized) policies.  The Keep-Alive period a new logical
         connection is determined reestablished (beginning with Connection-
         Initiation-Query,...). New/hard state gradually replaces
         old/soft state as the minimum described in Section 2.3.4.

   2.4 Error Handling

      We distinguish between the two values declared in the
           handshake messages.

      3.1.1 Secure Communications

         The integrity types of the communication channel between client and
         server is guaranteed by the use of shared-key message digest. possible errors; policy errors
      and protocol errors.

      2.4.1 Protocol Errors

         Protocol errors (e.g., keyed MD5). A client, wishing to establish secure
         communications adds a "Cookie" to the Connection-Initiation-
         Query.  The server may respond with a reply Cookie missing or with an
         Error-Description bad parameters) do not reveal
         either positive or negative policy decisions and are therefore
         neutral (represented as SNUBs). [Note 5] 10]
_________________________
[Note 5] The Error-Description provides reasons for rejecting the secure
communications request.

Internet Draft       OOPS: Policy Protocol for RSVP

         Shared keys may be obtained from 10] This neutrality allows, when appropriate, other valid sub-
policy elements to support an accept decision.

         It is recommended (although not required) that all local static configurations or
         could be distributed dynamically. The exchange of cookies
         provides status
         processing at the client and be completed before querying the
         server.  This allows the server with an opportunity for
         establishing a temporary shared-key (e.g., from Kerberos) for to immediately commit the
         transaction rather than having to wait until the connection length.

         Once a shared key is available, each message sent by either client is
         done.  (See the Client-Status-Notification Op-Code.)

         Some OOPS protocol errors may only affect the OOPS protocol
         processing or server includes an INTEGRITY object simply be logged. Other errors may escalate to
         become policy errors (e.g., a bad POLICY_DESC is reported as described a
         policy error).

      2.4.2 Policy Errors

         Policy errors are reported in
         [Bak96].  The format a sub-policy element specific
         format. These elements are encapsulated in POLICY_DESC objects
         and functionality of the INTEGRITY object are identical to that forwarded toward the originator (cause) of RSVP. The sender client or server
         computes the error.
         In most cases, a negative Status-Response initiates an
         automatic error response (e.g., RSVP ResvErr or PathErr),
         however, OOPS allows reporting of other error situations by
         scheduling an explicit error message digest over (using the entire OOPS message; if Protocol-
         Message-Notification op-code).  (See [Ext] for more about the receiver fails
         rules governing error reporting).

         Consider a scenario where two receivers R1 and R2 listen to verify the message, a
         multicast transmission from S1. A reservation sent by R1 is
         propagated upstream until it response with an
         error message. reaches node A, where it
         encounters a policy rejection.

           R1------------+
                                            B--------------A----------- S1
                          / \             |
           R2------------+   \            |
                              \           |
                              PS1        PS2

                   Figure 3: An Error Reporting Scenario

         The format of "cookies" is left for future versions following table describes a subset of this
         document.

   3.2 Reliable Communication

      We expect TCP to provide us the relevant
         signaling which begins with reliable, in-order delivery of
      packets, as well as information on reservation initiation by R1 and R2
         and ends by R1 receiving the liveliness of appropriate error response.

From/To   Message                                    Comments
________________________________________________________________________________
R1->B     Resv [PD1]
R2->B     Resv [PD2]
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
      communication channel.  Given that TCP is responsible for all 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
      time critical network operations, reliability errors are assumed 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 be virtually nonexistent. However, 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 maintain application-
      level reliability, R1 only)
B->R1     ResvErr [PD1-E']                           ;B sends back ResvErr to R1
________________________________________________________________________________

          Figure 4: Error Reporting Signaling

         All error information is carried in POLICY_DESC objects (as
         sub-policy elements). OOPS uses a minimalistic reliability mechanism
      using sequence numbers, selective retransmit and keep-alive
      messages. This requires no retransmission timeouts, server may read and has low
      overhead.

      3.2.1 Sequence Numbers

         Each OOPS message, except a Resend-Notification, is uniquely
         identified by a sequence number [Note 6]
          (Mseq).  These numbers do not imply any order of execution;
         while modify this
         information along the server receives messages in-order, it is free to
         execute them in any reasonable order. [Note 7]

         In addition, each message ResvErr path; it may also carries direct the sequence number
         error responses only to the relevant branches of the last received message (Rseq). Both client and server begin
         communication reserved
         tree (in this scenario, the error is associated with Mseq = 0 (the handshake message), R1 but not
         with R2).

3. Client-Server Connection

   The following section describes the fundamentals of client-server
   connection: establishment, channel, and termination.

   3.1 Connection Establishment

      OOPS uses a well known port number
         consecutive messages in increasing order.
_________________________
[Note 6] Not counting wraparounds
[Note 7] Execution order is implementation and policy specific; any
order that does not violate (OOPS = 3288) for incoming
      connection requests. Usually, the policy specific requirements is assumed client would attempt to be reasonable.

Internet Draft       OOPS: Policy Protocol for RSVP

         A transmitted message with Mseq = m is considered
      establish a TCP connection to its preferred policy server,
      however, both client and server listen to be
         acknowledged if m <= Rseq (Rseq from the latest received
         message). OOPS port. [Note 8]

         The sender must be prepared to retransmit (as requested) any
         message that has not been acknowledged yet.  Missing, or out-
         of-order messages 11]

_________________________
[Note 11] New (or recovering) policy servers are identified allowed to notify
clients on their existence by issuing a gap in sequence numbers TCP connection request to the
client's OOPS port number.

      Regardless of received messages.

      3.2.2 Receiver who initiated retransmit

         When the receiver (client or server) detects missing messages
         it immediately sends an explicit Resend-Notification listing
         these messages.  The Resend-Notification has a sequence number
         0. [Note 9]

         Upon receiving the Resend-Notification, TCP connection, once the sender must
         retransmit all
      connection is in place, the requested messages before sending new ones.

      3.2.3 Keep-Alive Messages

         Many platforms provide system support for detecting broken TCP
         connections. OOPS can utilize, but does not depend on such
         mechanisms.  Instead, it relies on Keep-Alive messages to
         provide application-level communication-channel verification,
         as a server may be in a dysfunctional state while its TCP logical connection establishment
      is still open always initiated by the client and viable. is performed through a two
      way handshake.

      o    Communication Initiation by the Client

           The client sends a Keep-Alive Connection-Initiation-Query to the server.
           This message identifies the client to the server only after and provides
           the receiving channel has been idle for longer than basic characteristics of the client as well as a list of
           policy responses that are acceptable to the client. This list
           is in decreasing order of acceptability, and terminates with
           the default element.

      o    Response by the Keep-
         Alive period. Server

           The server responds promptly with a Keep-Alive
         ack.

      3.2.4 Overhead

         These reliability mechanisms were designed Connection-Accept-Response to be simple and
         impose minimal overhead in
           connect to the client. It may also respond with a busy working environment.  When
           Connection-Reject-Response to refuse and disconnect from the
           client.

           After connection establishment both the client supports a large number of RSVP sessions and has
         frequent message exchange with server
           know the set of sub-policies that the client can send to the
           server, it would not be
_________________________
[Note 8] Mseq <= Rseq which one of them should take into account possible wrap-around handle default
           (unrecognized) sub-policies, as well as the format of
sequence numbers.

[Note 9] Thus, Resend-Notification cannot participate 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 sequence number
reliability verification. A lost Resend-Notification cannot not the handshake messages,
           but must be
detected, however, a new one is bound at least 3 seconds.

      3.1.1 Reliable Communication

         We expect TCP to be triggered sometime again.

Internet Draft       OOPS: Policy Protocol for RSVP

         sending Keep-Alive messages.  Similarly, since provide us with reliable, in-order delivery of
         packets.  Given that TCP is used responsible for
         reliable communications, there is a virtually zero probability
         that Resend-Notification messages would all the time
         critical network operations, reliability errors are assumed to
         be required. The only
         timer required is virtually nonexistent.

      3.1.2 Secure Communications

         OOPS relies on standard protocols for the Keep-Alive period; the timer security of client-server
         communications. An emerging standard protocol IPSEC [IPSEC] is reset
         on each message arrival and a Keep-Alive message
         the mechanism of choice for ensuring either integrity or
         secrecy.  The use of IPSEC and/or other security protocols is initiated
         only when it expires.

   3.3
         transparent to OOPS.

   3.2 Connection Termination

      This section describes how communication breakdown is handled.

      3.3.1 Explicit Termination

         The client (or server) may terminate the connection by sending
         a Bye-Notification, and wait until either it receives an echoed
         Bye-Notification or a Keep-Alive period had passed. In between,
         it should ignore incoming messages (and not reset the Keep-
         Alive timer).

         At the opposite side, when a client (or server) receive a Bye-
         Notification message, they 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.

      3.3.2 handling of communication breakdown.

      3.2.1 Implicit Termination

         The communication channel may be unexpectedly disconnected
         because of a misbehaving client or server, network split, or
         for other reasons.  Both client and server must be able to
         detect 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 the break and stop debiting
         this account.

         A communication

         The OOPS protocol relies on Keep-Alive messages to provide
         application-level communication-channel verification. [Note 12]

         Implicitly, the communications channel is assumed to be disconnected when
         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.2.2 Explicit Termination

         The client (or server) may terminate the connection by sending
         a Bye-Notification, and wait until either it receives an echoed
         Bye-Notification or the Channel-Hold period had passed. In
         between, it should ignore incoming messages (and not reset the
         Channel-Hold timer).

         At the opposite side, when a client (or server) receive a Bye-
         Notification message, it should echo it, and close the
         connection.

_________________________
[Note 12] OOPS implementations may utilize system dependent mechanisms
for detecting broken TCP connections, but does not rely on them. This is
especially important since a server may be in a dysfunctional state
while its TCP connection is still open and viable.

[Note 13] When the
         channel was idle (no message was received on it) for over intermediate period in between two
         Keep-Alive periods.

      3.3.3 OOPS messages
approaches the Channel-Hold time.

      3.2.3 Post Termination

         Soft-state has an inherent cleanup mechanism; when the channel
         disconnects, the soft-state would begins to age and until it eventually expire

Internet Draft       OOPS: Policy Protocol for RSVP

         based on
         expires (using the same mechanism and refresh-period * K used
         by RSVP.

         When RSVP).

         In contrast, 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  Clearly, purging all
         state immediately upon disconnection is not an acceptable
         approach since it may should cause a disruption of service
         before and would not
         allow enough time to contact an alternate server is contacted. server.  OOPS uses
         the following simple rule:

         When the communication channel disconnects, the all hard state
         associated with it is assumed to be soft-state that was just
         refreshed.

         Naturally, when any RSVP state changes (e.g., routing changes,
         policy input changes, etc.), cached results at the client
         should not be used and must be purged.

      3.3.4 had been
         refreshed recently.

      3.2.4 Switching to An Alternative Server

         We assume that the client is provided as part of their local configuration, clients
         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
         disconnection (i.e., Bye-Notification) or an unexpected break
         in the communication channel.  During normal operations, the
         client may wish to switch to an alternate server (for any
         reason). The client is advised to first connect to the new
         server before sending a Bye-
         Notification Bye-Notification to the original one.
         If the communication channel unexpectedly disconnects, the
         client should quickly attempt to connect to an alternate
         server.

         In both cases, after the connection to a new server [Note 10] 14]
          is established, the aging cached state from the old server
         would be gradually replaced by responses from the new server.
         [Note 11] 15]
_________________________
[Note 10] 14] The term "new server" may be the same as the "previous
server"; it may happen that the connection encounters a problem and the
client chooses to disconnected and re-established the connection.

[Note 11] 15] The client could speed-up replacement of cached state by
sending copies of cached input to the server and issuing repeated
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
         should not cause a disruption of service that would not
         otherwise occur (if a new server was not found). [Note 12] service that would not
         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

   OOPS messages serve as a wrapper that may include one or more
   protocol operations; this Op-
   Codes; the message wrapper allows common operation (e.g., MD5
   integrity, RSVP_HOPs, HOP_DESCs, protocol version, etc.) to be verified and performed and
   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    Ver        |   Flags  #Op-Codes    |   op-objs#  Flags        | Reserved (0)    //////     |
   +---------------+---------------+---------------+---------------+
   |                  Message Length                               |
   +---------------+---------------+---------------+---------------+
   |                  Message Sequence Number                      |
   +---------------+---------------+---------------+---------------+
   |                  Ack-ed Sequence Number                       |
   +---------------+---------------+---------------+---------------+
   |                      INTEGRITY Object... (optional)                  OOPS_MSG_AUTH (Optional)                     |
   +---------------+---------------+---------------+---------------+
   |                  List of operations Op-Codes...                          |
   +---------------+---------------+---------------+---------------+

   Any OOPS message is composed of the following fields:

   Version: 8 bits

        Protocol version number. The current version is 1.

   Flags: 8 bits

        0x01 H_Integrity_Checked      POLICY_DESC Integrity already checked by client
        0x01
        0x02 H_Hops_Checked           RSVP_HOPs           Prev/Next HOPs already checked by client

   op-objs#:

   #Op-Codes: 8 bits

        Number of objects Op-Codes included in this message.

   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.

   Message Sequence Number: 32 bits

        The sequence number of the message being sent.

   Ack-ed Sequence Number: 32 bits

        The sequence number of the last message received in-order from
        the peer entity (client or server).

   RSVP INTEGRITY Object

   OOPS_MSG_AUTH (optional): variable length

        This object is defined in [Bak96]. It Message Authenticator provides a message digest integrity verification based
        on a shared key between the client and sender. shared-keyed message digest. The message digest is
        calculated over the entire OOPS message.

        There is only one object format currently defined is identical
        to the RSVP INTEGRITY object (defined in [Bak96]).

   List of OOPS operations: operation codes (Op-Codes): variable length

        Described in the following section.

   4.1 OOPS Operations Operation Codes (Op-Codes)

      Each OOPS message may contain multiple OOPS operations each
      encapsulating a different query, response or notification.  For
      example, multiple Incoming-Policy-Queries might be followed by a
      Status-Query operation in the same message. Operations within an
      OOPS message are sequentially numbered.

      Individual OOPS operations Op-Codes have the following header:

      +---------------+---------------+---------------+---------------+
      | Operation Type| Code| Op. Subtype   | Op. Seq#      |  Flags        |    //////     |
      +---------------+---------------+---------------+---------------+
      |                      Length (bytes)                           |
      +---------------+---------------+---------------+---------------+
      |               |  RSVP's                      Refresh Period                           |
      +---------------+---------------+---------------+---------------+

      The operation header has the following fields:

      operation Type: Code: 8 bits

           The type of OOPS operation.

      Operation Subtype: 8 bits

Internet Draft       OOPS: Policy Protocol for RSVP

           This field can be used to indicate an attribute of the
           operation type, Op-
           Code, 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

           0x01 OOPS_HardState:   Hard State (soft-state if not set (0) )
           0x02 OOPS_Shared   :   Resv shared among sources as filter specs
           0x02 OOPS_FullList :   Last in the set of status queries.

      Length: 32 bits

           Contains the total operation length in bytes.

      RSVP's bytes (including
           header).

      Refresh Period

           The refresh-period RSVP associates with this object.

      This object (e.g., RSVP's
           refresh period).

      The remainder of this section describes the set of operations
      that may appear in OOPS messages. Many data fields of these
      operations are RSVP objects; they are typed set of operations that
      may appear in uppercase letters OOPS messages and their format object format.  OOPS does
      not bind itself to a particular protocol (i.e., RSVP) and is defined in [RSVPSP]. built
      around objects that may belong to different (other) protocols. The format of other
      operations
      current draft is listed in based on the following section. 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)

         Operation Type = 0, sub-type = 0 1

         <Null-Notification> ::= <Common OOPS header>

         This empty or null notification triggers no operation; thus,
         can be used as as Keep-Alive signal to test the viability of
         the communication channel between client and server (see
         Section 3.2.3). 3.2.1).

      4.1.2 Connection-Initiation-Query

         Operation Type = 1, sub-type = 1

         <Connection-Initiation-Query> ::=  <Common OOPS header>
                                            <Ver> <RSVP-K> <Flags>
                                            <Client-ID>

Internet Draft       OOPS: Policy Protocol for RSVP

                                            <Max-Pkt-Size> <Keep-Alive period>
                                            <Class Indicator>
                                            <Cookie>
                                            <CONNECT_DESC>
                                            <CLASS_ID>
                                            <CLIENT_ID>
                                            <RESP_INT>
                                            <COOKIE>

         The client sends this query to establish a connection with a
         server. This message is sent following the establishment of a
         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

         Operation Type = 2, sub-type = 1

         <Connection-Accept-Response> ::=  <Common OOPS header>
                                           <Max-Pkt-Size> <Keep-Alive period>
                                           <Policy list>
                                           <Cookie>
                                           <CONNECT_DESC>
                                           <PLIST>
                                           <RESP_INT>
                                           <COOKIE>

         The server sends this response to accept a client's connection
         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

         Operation Type = 3, sub-type = 1

         <Connection-Reject-Response> ::=  <Common OOPS header>
                                           <Error-Description>
                                           <ERR_DESC>

         The server sends this response to reject a client's connection
         initiation. It specifies both reason code and text.

      4.1.5 Bye-Notification

         Operation Type = 4, sub-type = 1

         <Bye-Notification> ::= <Common OOPS header>
                                <BYE_DESC>
                                [<ERR_DESC>]

         This message is used by either client or server to terminate
         the OOPS connection.

         o    BYE_DESC

         (Section 3.3.1 3.2.2 includes a description of explicit termination )
         using Bye-Notification)

      4.1.6 Incoming-Policy-Query

         Operation Type = 5, sub-type = 1

         <Incoming-Policy-Query> ::=  <Common OOPS header>
                                      <RSVP MESSAGE TYPE>
                                      <SESSION>

Internet Draft       OOPS: Policy Protocol for RSVP

                                      <FILTER_SPEC
                                      <Q_ASSOC>
                                      <PROT_MSG_TYPE>
                                      <DST_DESC>
                                      <SRC_DESC list>
                                      <HOP_DESC>
                                      [<ADV_DESC>]
                                      <POLICY_DESC list> <RSVP_HOP>
                                      <resv_handle> <RESV_FLOWSPEC>
                                      <counter (of in P.D.)>
                                      <in POLICY_DATA objects>

         This operation is used to forward POLICY_DATA POLICY_DESC objects from the
         client to the server.  Selection between hard and soft state
         management is reflected in the OOPS_HardState flag.  The other
         fields are copied from the PC_InPolicy() function called by
         RSVP. (See [Ext]).

      4.1.7 Incoming-Policy-Response

         Operation Type = 6, sub-type = 1

         <Incoming-Policy-Query>

         <Incoming-Policy-Response> ::=  <Common OOPS header>
                                      <Query Sequence Number>
                                      <Error-Description>
                                         <Q_ASSOC>
                                         <ERR_DESC>

         Incoming-Policy-Response is used ONLY to report protocol errors
         (e.g., syntax) found with incoming policy objects.  (it is not
         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

         Operation Type = 7, sub-type = 1

         <Outgoing-Policy-Query> ::=  <Common OOPS header>
                                      <RSVP MESSAGE TYPE>
                                      <SESSION>
                                      <FILTER_SPEC
                                      <Q_ASSOC>
                                      <PROT_MSG_TYPE>
                                      <DST_DESC>
                                      <SRC_DESC list>
                                      <counter (of RSVP_HOPs)>
                                      <RSVP_HOP
                                      <HOP_DESC list>

         This operation queries the server for a set of outgoing policy
         objects for a set of RSVP_HOPs. HOP_DESCs.  The client can choose between
         hard and soft state management through the OOPS_HardState flag.
         When hard state is selected, the client caches copies of the
         outgoing objects and assumes they remain valid unless
         explicitly modified by the server.

      4.1.9 Outgoing-Policy-Response

         Operation Type = 8, sub-type = 1

Internet Draft       OOPS: Policy Protocol for RSVP
         <Outgoing-Policy-Response> ::=  <Common OOPS header>
                                         <Query Sequence Number>
                                         <Counter (of triplets)>
                                         <Q_ASSOC>
                                         { <RSVP_HOP>
                                           <Error-Description>
                                           <out POLICY_DATA objects> <HOP_DESC>
                                           <ERR_DESC> or <POLICY_DESC>
                                         } pair pairs list

         The  <Query Sequence Number> links the response to the original query.

         In the response, the server provides a list of triplets, one
         for each outgoing RSVP_HOP HOP_DESC (For Path messages, only the LIH
         part is significant). Each triplet contains a list list of policy
         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
         objects for that hop and an error description. control.

      4.1.10 Status-Query

         Operation Type = 9, sub-type = 1

         <Status_Query> ::=  <Common OOPS header>
                             <RSVP MESSAGE TYPE>
                             <SESSION>
                             <FILTER_SPEC_LIST>
                             <counter (of Triplets)>
                             <Q_ASSOC>
                             <PROT_MSG_TYPE>
                             <DST_DESC>
                             <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
         of LIHs.  The client can choose between hard and soft state
         management through the OOPS_HardState flag. When hard state is
         selected, the client caches the status results and assumes they
         remain valid unless explicitly modified by the server.

         In the upstream direction (e.g., Resv) status may need to be
         checked on multiple LIHs (all reservations for a flow). In such
         cases, status queries can be perform separately for each LIH,
         once for all LIHs, or anything in between. Flag OOPS_FullList
         must be set at the last of status query of the series. [Note
         13] 18]
_________________________
[Note 13] 18] When policies sub-policies are interdependent across LIHs (as when the
cost is shared among downstream receivers), flag OOPS_FullList notifies
the server that the list of reserved LIH is complete and that it can
safely compute the status of these reservations.

Internet Draft       OOPS: Policy Protocol for RSVP

      4.1.11 Status-Response

         Operation Type = 10, sub-type = 1

         <Status_Response>

         <Status-Response> ::=  <Common OOPS header>
                                <Query Sequence Number>
                                <Counter (of triplets)>
                                <Q_ASSOC>
                                { <LIH>
                                  <Status Result>
                                  <Error-Description> <HOP_DESC>
                                  <STATUS_DESC>
                                  [<ERR_DESC>]
                                } pair triplet list

         The  <Query Sequence Number>  <Q_ASSOC> links the response to the original query.

         In the response, the server provides a list of triplets, each
         of which contains an LIH, status, and any applicable error
         results.  The set of LIHs is an attribute of the results and
         not of the query; the server is allowed to respond with a
         superset of LIHs specified in the original query, as in the
         following example:

                             Seq#  Type           Data

                             SEQ#  TYPE           DATA
                             ---   ----           ----
         Client ==> Server:  150   Query:status   Q_ASSOC=ID2, Resv-X, LIH={2}
         Server ==> Client:  153   Resp :status   #150:{2,rej}   Q_ASSOC=ID2, {2,rej}

         Two new reservations arrive, carrying new policy data objects:

         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}   Q_ASSOC=ID3, {2,acc;4,acc;7,rej}

      4.1.12 Delete-State-Notification

         Operation Type = 11, sub-type = 1

         <Delete-State-Notification> ::=  <Common OOPS header>
                                          <RSVP MESSAGE TYPE>
                                          <SESSION>
                                          <FILTER_SPEC_LIST>
                                          <RSVP_HOP>
                                          <Op-type>
                                          <STATE_OP_DESC>
                                          <DST_DESC>
                                          [<PROT_MSG_TYPE>]
                                          [<SRC_DESC list>]
                                          [<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
         teardown of state caused by PATH_TEAR, RESV_TEAR, routes
         change, etc.  As a result, the server should ignore the
         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
         blockaded and non-blockaded state.

         The semantics of this operation is described for PC_DelState()
         in [Ext].

         Error description is used to provide the server with a reason
         for the delete (for logging purposes).

      4.1.13 Schedule-RSVP-Notification Protocol-Message-Notification

         Operation Type = 12, sub-type = 1

         <Schedule-RSVP-Notification>

         <Protocol-Message-Notification> ::=  <Common OOPS header>
                                           <RSVP MESSAGE TYPE>
                                           <SESSION>
                                           <FILTER_SPEC
                                              <PROT_MSG_TYPE>
                                              <DST_DESC>
                                              <SRC_DESC list>
                                           <RSVP_HOP>
                                              <HOP_DESC>

         The operation results in the generation of an outgoing RSVP protocol
         message (Path, Resv, etc.) in the client's RSVP.  RSVP (e.g., RSVP's Path, Resv).  The client should schedule
         the requested message to the specified RSVP_HOP. HOP_DESC.

      4.1.14 Client-Status-Notification

         Operation Type = 13, sub-type = 1

         <Client-Status-Notification> ::=  <Common OOPS header>
                                           <Query Sequence Number>
                                           <Status Result>
                                           <Q_ASSOC>
                                           <STATUS_DESC>

         The Client notifies the server about the status results
         computed at the client (that may also include results from
         other servers, if policy computation is spread among several
         servers).

         The overall status of an RSVP flow is computed by merging the
         client's status report with the server's. The server should not
         commit a transaction (e.g., charge an account) before knowing
         its final status. The Client-Status-Results operation can be
         sent with the query, if the client computed its status prior to
         making the query. It can also be sent later, after the server
         sent its response to the status query.

      4.1.15 Resend-Notification Error-Notification

         Operation Type = 14, sub-type = 1

         <Resend-Notification>

         <Message-Error-Notification> ::=  <Common OOPS header>
                                   <Counter (of missing messages)>
                                   <Message sequence number> list
                                           <Message-Sequence-Number>
                                           <ERR_DESC>

         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).

         <Message-Sequence-Number> identified the message that triggered
         the error. It uses identical format to the one used by the OOPS
         message header.

         Message-Error-Notification is not acked.

5. Acknowledgment

   This document reflects feedback from Paul Amsden, Fred Baker, Lou
   Berger, Bob Braden, Ron Cohen, Deborah Estrin, Steve Jackowski, Tim
   O'Malley, Claudio Topolcic, Raj Yavatkar, and many other IPC and RSVP
   collaborators,

6. Authors' Address

   Shai Herzog              Phone: (917) 318-7938
   IP"Highway"                Email: herzog@iphighway.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
   P.O. Box 704
   Yorktown Heights, NY 10598

7. References

References

[IPSEC]  R. Atkinson, Security Architecture for the Internet Draft       OOPS: Protocol,
    "RFC1825", Aug. 1997.

[Bak96]  F. Baker.  RSVP Cryptographic Authentication "Internet-Draft",
    draft-ietf-rsvp-md5-02.txt, 1996.

[RSVPSP]  R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin,
    Resource ReSerVation Protocol (RSVP) Version 1 Functional
    Specification.  "Internet-Draft", draft-ietf-RSVPSP-14.[ps,txt],
    Nov. 1996.

[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 Protocol Modules (LPM): Policy Enforcement for
    Resource Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-
    policy-lpm-01.[ps,txt], Nov. 1996.

[Ext]  S. Herzog RSVP

         Both client and server may issue a Resend-Messsage request when
         they detect missing or out-of-order messages.  The Resend-
         Notification has message sequence number 0.  The message
         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

         Operation Type = 6, sub-type = 1

         <Error-Notification> ::=  <Common Extensions for Policy Control.  "Internet-Draft",
    draft-ietf-rsvp-policy-ext-02.[ps,txt], Apr. 1997.

A Appendix: OOPS header>
                                   <Message Sequence Number>
                                   <Error-Description>

         Error-Notification can be Objects

This section describes objects that are used by either client or server to
         report errors associated with an entire message (as opposed to within OOPS OP-Codes.  All
objects have a specific operation). Error-Notification may be triggered by
         both syntax or substantive errors (e.g., failure to verify common header:

+---------------+---------------+---------------+---------------+
|            Length             |      Class    |   C-Type      |
+---------------+---------------+---------------+---------------+

Length describes the
         integrity length of a previous message).

         <Message Sequence Number> identified the message that triggered entire object, in bytes.  Class
describes the error.

         Error-Notification is not acked.

   4.2 Fields format type of object and C-Type describes the a class sub-type.

o    <Ver> <RSVP-K> <Flags>    CLASS_ID class

     -    Class = 1, C-Type = 1

          +---------------+---------------+---------------+---------------+
          |   Version     |  RSVP-K       |   Flags       |   ASCII String ........ 0 Padded to multiples of 32 bits      |
          +---------------+---------------+---------------+---------------+

           Ver: Currently, version 1.

           RSVP-K: The K value used by RSVP as a refresh-period
           multiplier.

           Flags:
           0x01  OOPS_CONNECT_DefaultC     Client handles default policies.

o    <Max-Pkt-Size><Keep-Alive period>    CLIENT_ID class

     -    Class = 2, C-Type = 1

          A Network Address.

          +---------------+---------------+---------------+---------------+
          | Max-Pkt-Size (in KBytes)   IPv4 Address                                                | Keep-Alive period (in seconds)|
          +---------------+---------------+---------------+---------------+

Internet Draft       OOPS: Policy Protocol for RSVP

      o    <Class Indicator>

     -    Class = 2, C-Type = 2

          +---------------+---------------+---------------+---------------+
          |            Length (total)   IPv6 Address                                                |
          |                                                               |
          |         Class Code                                                               |
           +---------------+---------------+---------------+---------------+
          |   ASCII String ........ 0 Padded to multiples of 32 bits                                                               |
          +---------------+---------------+---------------+---------------+

      o    <Client-ID>

           Client address, uses the same format as RSVP's FILTER_SPEC
           objects.
     From the combination of Client-ID and Class-Indicator the server
     can learn about the set of policies sub-policies it is required to support
     for this particular client. client; it can also learn which of these sub-
     policies are optional and which are mandatory.

o    <Cookie>    RESP_INT class

     -    Class = 3, C-Type = 1

          +---------------+---------------+---------------+---------------+
          |          Length (total) Most-Prefered |.....          |    Type               |       0               |
          +---------------+---------------+---------------+---------------+
          |   Octet String ........ 0               | Least-Pref.   |...0 Padded to multiples of 32 bits      | bit multiples|
          +---------------+---------------+---------------+---------------+

o    COOKIE class

     -    Class = 4, C-Type = 1

          Currently, no values are defined.

o    <Policy list>    PLIST class

     -    Class = 5, C-Type = 1

          +---------------+---------------+---------------+---------------+
          |          Number (or pairs)    |              0             //////            |
          +---------------+---------------+---------------+---------------+
          |          From Policy 1        |         To Policy 1           |
          +---------------+---------------+---------------+---------------+
          +---------------+---------------+---------------+---------------+
          |          From Policy n        |         To Policy n           |
          +---------------+---------------+---------------+---------------+

     Each "From Policy m" and "To Policy m" pair represent a range of policies
     sub-policies that the server is willing to support.

o    <Error-Description>    ERR_DESC class

     -    Class = 6, C-Type = 1

          +---------------+---------------+---------------+---------------+
          | Length (*) Error-Code    | Error-Type     //////    |        Reason Code            |
          +---------------+---------------+---------------+---------------+
          |   Error ASCII String .... 0 Padded to multiples of 32 bits    |
          +---------------+---------------+---------------+---------------+

Internet Draft       OOPS: Policy Protocol

     Detailed Error-Code and Reason-Codes would be defined in future
     versions of this document.

o    Q_ASSOC class

     -    Class = 7, C-Type = 1

          +---------------+---------------+---------------+---------------+
          |                      Client-Specific Semantics                |
          //                        (Variable Length)                    //
          |                                                               |
          +---------------+---------------+---------------+---------------+

          The client-specific contents of this object is opaque to the
          server; it is set by the client for RSVP

           (*) Length 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 overall <Error-Description> 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

          +---------------+---------------+---------------+---------------+
          |               RSVP MSG TYPE                                   |
          +---------------+---------------+---------------+---------------+

          Values specified in [RSVPSP].

o    DST_DESC class

     -    Class = 9, C-Type = 1

          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 4 bytes
           increments (i.e., length value of X should be interpreted [RSVPSP].

o    POLICY_DESC class

     -    Class = 14, C-Type = 1

          The RSVP POLICY_DATA object as
           X*4 bytes description defined in [Ext] and an (X-1)*4 bytes Error ASCII
           String.

           No errors are reported by setting the length to [RSVPSP].

o    OOPS_MSG_AUTH class

     -    Class = 15, C-Type = 1 (4 bytes)
           and setting the Error-Type to 0.

           Detailed Error-Types and Reason-Codes would be

          The RSVP INTEGRITY object as defined in
           future versions of this document. [RSVPSP] and [Bak96].

o    <resv_handle>    STATUS_DESC class
     -    Class = 16, C-Type = 1

          +---------------+---------------+---------------+---------------+
          |               IntServ or Client-Specific Semantics Results       |   Priority    |             //////            |
          +---------------+---------------+---------------+---------------+

           The server

          Results may use have one of the <resv_handle> to obtain IntServ and
           other low-level information about 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 reservation.

           The current version of this document does not define OOPS connection parameters; in the
           semantics of this field. It may be a pointer into some router
           specific data structures (proprietary) or
          Connection-Accept-Response, the refresh-multiplier is an index into mib
           records obtainable through SNMP.

      o    <Query Sequence Number> (and internally, <Message Sequence
           Number>) echo
          of the value received with the Connection-Initiation-Query.

          +---------------+---------------+---------------+---------------+
          |                <Message Sequence Number>  Version      |
           +---------------+---------------+---------------+---------------+  Flags        | Obj. Seq. Num.|                      0 Refresh-Mult. |    //////     |
          +---------------+---------------+---------------+---------------+

      o    <Counter>

           +---------------+---------------+---------------+---------------+
          |                           <Counter> Max-Msg-Size (in KBytes)      | Channel-Hold period (in sec.) |
          +---------------+---------------+---------------+---------------+

          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    <Status Result>    BYE_DESC class

     -    Class = 18, C-Type = 1

          BYE_DESC provides details about the Bye-Notification request.

          +---------------+---------------+---------------+---------------+
          | Results   Bye-Flags   |                      0   //////      |      BYE_DELAY (seconds)      |
          +---------------+---------------+---------------+---------------+

           Results may have one

          Bye-Flags:
          0x01     An echo (response) to a received Bye-Notification

          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 the following values:

Internet Draft       OOPS: Policy Protocol for RSVP

           1 :         Accept
           2 :         Snub
           3 :         Veto 0.

o    <Op-Type>    STATE_OP_DESC class

     -    Class = 19, C-Type = 1

_________________________
[Note 20] Similar to the delayed shutdown command known in Unix.

          +---------------+---------------+---------------+---------------+
          | Mod-Type   Op-Type     |                       0                      //////                   |
          +---------------+---------------+---------------+---------------+

          Op-Type values:

          1 :         Delete State
          2 :         Block State
          3 :         Unblock State

5. Acknowledgment

B Appendix: Error Codes

This document reflects feedback from many other RSVP collaborators.

Internet Draft       OOPS: Policy Protocol appendix describes an initial list of error codes available in
OOPS, as well as the set of Reason Codes for RSVP

References

[Bak96]  F. Baker.  RSVP Cryptographic Authentication "Internet-Draft",
    draft-ietf-rsvp-md5-02.txt, 1996.

[RSVPSP]  R. Braden, L. Zhang, S. Berson, S. Herzog, each error code.  (Reason
Code of 0 must be used when Reason Codes are not applicable).  This list
should evolve and S. Jamin,
    Resource ReSerVation not be considered conclusive. [Note 21]

o    Code = 1, Connection Management

     1:  Connection Reject: Server does not support client version.
     2:  Bye: Reset due to routine state re-synchronization
     3:  Bye: Reset due to connection problems (Bad message formats)

o    Code = 2, Protocol (RSVP) Version 1 Functional
    Specification.  "Internet-Draft", draft-ietf-RSVPSP-14.[ps,txt],
    Nov. 1996.

[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 problems

     1:  Syntax: Bad OOPS message
     2:  Syntax: Bad OOPS Op-Code
     3:  Syntax: Bad POLICY_DESC format

o    Code = 3, Policy Modules (LPM): Decisions

     1:  Don't forward: refrain from forwarding an outgoing message.
     2:  Policy Enforcement for
    Resource Reject: cancel protocol operation (Reservation, path, etc.)

o     Code = 4, State Management

     1:  Delete State: 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.

Authors' Address

Shai Herzog              Phone: (914) 784-6059
                         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
P.O. Box 704
Yorktown Heights, NY 10598 Canceled
     2:  Delete State: route change
     3:  Delete State: State Timeout
     4:  Blockade State
     5:  Unblock State