[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 RFC 2749

Internet Draft                                          Jim Boyle
Expiration: Feb 1999                                       L3
File: draft-ietf-rap-cops-rsvp-00.txt                   Ron Cohen
                                                           Cisco
                                                        David Durham
                                                            Intel
                                                        Shai Herzog
                                                            IPHighway
                                                        Raju Rajan
                                                            IBM
                                                        Arun Sastry
                                                            Cisco

                          COPS usage for RSVP


                     Last Updated: August 19, 1998


Status of this 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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "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 ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or
   munnari.oz.au.

   A revised version of this draft document will be submitted to the
   RFC editor as a Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested.  This
   document will expire before June 1998. Distribution of this draft is
   unlimited.

Abstract

   This document describes usage directives for supporting COPS policy
   services in RSVP environments.




Internet Draft                                                [Page 1]


Internet Draft           COPS usage for RSVP            April 4, 1998

1. Introduction

   The Common Open Policy Service (COPS) protocol is a query response
   protocol used to exchange policy information between a network
   policy server and a set of clients [COPS]. COPS is being developed
   within the RSVP Admission Policy Working Group (RAP WG) of the IETF,
   primarily for use as a mechanism for providing policy-based
   admission control over requests for network resources [RAP].

   This document is based on and assumes prior knowledge of RAP
   framework [RAP] and the basic COPS [COPS] protocol. It provides
   specific usage directives for using COPS in outsourcing policy
   control decisions by RSVP clients (PEPs) to policy servers (PDPs).

   Given the COPS protocol design, client specific functionality is
   mainly limited to interoperability usage guidelines as well as
   client specific examples.

2. RSVP values for COPS objects

   The format and usage of several COPS objects is affected when used
   for client type RSVP. This section describes these objects and the
   usage.

  2.1. Context Object (Context)

   The semantics of the Context object for RSVP is as follows:

   R-Type (Request Type Flag)

   0x01 = Incoming-Message request
          The arrival of an incoming RSVP message

          Allows processing of incoming policy information as well as
          the decision whether to accept an incoming message. If It is
          rejected, the message is treated as if it never Arrived.

   0x02 = Resource-Allocation request
          Applies only for Resv messages.

          The decision whether to admit a reservation and commit local
          resources to it is performed for the merge of all
          reservations that arrived on a particular interface
          (potentially from several Previous Hops).

   0x04 = Outgoing-Message request
          The forwarding of an outgoing RSVP message.

          The Decision whether to allow the forwarding of an outgoing


Boyle et. al.             Expires June 1998                  [Page 2]


Internet Draft           COPS usage for RSVP            April 4, 1998

          RSVP message as well as providing the relevant outgoing
          policy information.

   M-Type (Message Type)

   The M-Type field in the Context Object may have one of the
   Following values that correspond to supported RSVP messages
   In COPS:

   1 = Path
   2 = Resv
   3 = PathErr
   4 = ResvErr

   Note: The PathTear, ResvTear, and the Resv Confirm message types are
   not supported.

  2.2. Client Specific Information (ClientSI)

   All objects contained within RSVP messaging are encapsulated inside
   the Client Specific Information Object without alteration. The
   multiple RSVP objects are simply contained within a single Signalled
   Client Specific Information Object (Signaled ClientSI) exchanged
   between the PEP and remote PDP.

   To prevent ambiguity, the number of object instances appearing in
   the ClientSI are restricted by the rules native to RSVP. For
   example, it is forbidden to include two different FlowSpec objects
   in one ClientSI encapsulation, while perfectly legal to include
   multiple FilterSpecs for a WF or SE reservation.

   For applicability example, see Section 3.6.

  2.3. Decision Object (Decision)

   COPS allows PDP to control RSVP’s response to messages. Beyond
   traditional accept/deny, PDPs may use the Trigger Error flag to
   allow a request yet trigger a warning at the same time. To allow
   resource allocation yet deny forwarding of a message, etc.

   Replacement Data

   The Replacement object may contain multiple RSVP objects to be
   replaced (from the original RSVP request). Typical replacement is
   performed on the “Forward Outgoing” request (for instance, replacing
   outgoing Policy Data), but is not limited to this context flag.
   Another example, for controlling resources across a trusted zone
   (with PIN nodes) the RSVP FlowSpec object may need to be replaced.



Boyle et. al.             Expires June 1998                  [Page 3]


Internet Draft           COPS usage for RSVP            April 4, 1998

   Currently, RSVP clients are only required to allow replacement of
   two objects: Policy Data and FlowSpec.

   Client Specific decision Object

   In support of the verification integrity of incoming RSVP messages,
   the COPS protocol may optionally return a security key in the Client
   Specific Decision Data object (C-Type = 4) useful for future
   integrity checks by the PEP. Refer to the document on User Identity
   Representation for RSVP [UserID] for details on the format and
   application of this security key when supported by the PEP.

3. Operation of COPS for Policy Control Over RSVP

  3.1. RSVP flows

   Policy Control is performed per RSVP flow. An RSVP flow corresponds
   to an atomic unit of reservation as identified by RSVP (TC
   reservation). It should be noted that RSVP allows multiple flows to
   be packed (which is different from merged) into a single FF Resv
   message. To support such messages a separate COPS request must be
   issued for each of the packed flows as if they were individual RSVP
   messages.

  3.2. Expected Associations for RSVP Requests

   RSVP signaling requires the participation of both senders and
   receivers. RSVP processing rules define what is the subset of the
   Path state that matches each Resv state. In the common unicast case,
   the RSVP session includes one Path state and one Resv state. In
   multicast cases the correspondence might be many to many. Since the
   decision to admit a reservation for a session may depend on
   information carried both in Path and Resv messages, we term the Path
   States that match with a single Resv state as its associated states.
   It is assumed that the PDP is capable of determining these
   associations based on the RSVP message processing rules given the
   RSVP objects expressed in the COPS Client Specific Information
   Object.

  3.3. RSVP's Capacity Admission Control: Commit and Delete

   In RSVP, the admission of a new reservation requires both an
   administrative approval (policy control) and capacity admission
   control. Once local admission control accepts the reservation, the
   PEP notifies the remote PDP by sending a report message specifying
   the Commit type. The Commit type report message is to be used to
   signify when billing should effectively begin, and performing
   heavier operations (e.g., debiting a credit card) is permissible.



Boyle et. al.             Expires June 1998                  [Page 4]


Internet Draft           COPS usage for RSVP            April 4, 1998

   If instead a reservation approved by the PDP fails admission due to
   lack of resources, the PEP must resort to its previous state
   (previously installed reservation). If none was previously
   installed, the PEP should issue a delete. Otherwise, it should issue
   a report no-commit and then send a request update for the previously
   allocated reservation state.

  3.4. Policy Control Over Path and Resv Tear

   Path and Resv Tear messages are not controlled by this policy
   architecture. This relies on two assumptions: First, that MD-5
   authentication verifies that the Tear is received from the same node
   that sent the initial reservation, and second, that it is
   functionally equivalent to that node holding-off refreshes for this
   reservation. When a Resv or Path Tear is received at the PEP, all
   affected states installed on the PDP should either be deleted or
   updated by the PEP.

  3.5. PEP Caching COPS Decisions

   Because COPS is a stateful protocol, refreshes for RSVP Path and
   Resv messages need not be constantly sent to the remote PDP. Once a
   decision has been returned for a request, the PEP can cache that
   decision and apply it to future refreshes. The PEP is only
   responsible for updating a request state if there is a change
   detected in the corresponding Resv or Path message.

   If the connection is lost between the PEP and the PDP, the cached
   RSVP state may be retained for the RSVP timeout interval. If no
   connection can be reestablished with the PDP or a backup PDP, the
   RSVP PEP is expected to default back to using its LDP. Additionally,
   the LDP is to be used for the admission control of any new RSVP
   messages that may have arrived while connectivity was lost. If any
   such messages were admitted by the LDP, the PEP is expected to issue
   requests to the PDP for them once a connection is reestablished and
   a COPS session for RSVP is opened.

  3.6. Using Multiple Context Flags in a single query

   RSVP is a store-and-forward control protocol where messages are
   processed in three distinctive steps (input, output and resource
   allocation). Each step requires a separate policy decision as
   indicated by context flags (see Section 2.1). In many cases, setting
   multiple context flags can serve as a mean for bundling two of three
   operations together in one request (for instance, validating both an
   incoming message as well as allocating resources for it).

   The following rules apply when multiple Context flags are set:


Boyle et. al.             Expires June 1998                  [Page 5]


Internet Draft           COPS usage for RSVP            April 4, 1998


   a. Multiple context flags can be set simultaneously when their merge
      doesn’t create ambiguity in ClientSI interpretation. Two context
      flags become mutually exclusive for a specific REQ or DEC message
      when identical ClientSI objects carry different values for each
      of them.

   b. The DEC message contains a context object that correspond to all
      or a subset of the context flags set in original REQ. A DEC is
      assumed to be complete (as far as reuse of handles) only when all
      flags have been replied to (set in the following DEC message).

   c. The PEP may act based on partial (context subset) decision and is
      not required to wait for the others, although it may. Consistency
      is an issue for the PDP to worry about.

  3.7. Trusted zones and secure policy tunneling

  Security for RSVP messages is provided by inter-router MD5
  authentication [MD5], assuming a chain-of-trust model.
  A possible deployment scenario calls for PEPs to be deployed at the
  network edge (boundary nodes) while PINs are deployed in the core of
  the network (backbone). In this case, MD5 trust (authentication) must
  be established between boundary (non-neighboring) PEPs, which is
  achieved through internal signing of the Policy Data object. [RSVP-
  EXT].


4. Illustrative Examples, Using COPS for RSVP

  This section details both typical unicast and multicast scenarios.

  4.1. Unicast Flow Example

   This section details the steps in using COPS for controlling a
   Unicast RSVP flow. It details the contents of the COPS messages
   with respect to the following figure.

                                    PEP (router)
                                 +-----------------+
                                 |                 |
                  R1 ------------+if1           if3+------------ S1
                                 |       if2       |
                                 +--------+--------+
                                          |
                                          |
                                         PDP (server)

                    figure 1: Unicast Example: a single router view

Boyle et. al.             Expires June 1998                  [Page 6]


Internet Draft           COPS usage for RSVP            April 4, 1998



   The PEP router has three interfaces (1,2,3). Sender S1 sends to
   receiver R1.

   A Path message arrives from S1:

          PEP --> PDP   REQ := <Handle A><Context in&out, Path>
                               <In-Interface if3> <Out-Interface if1>
                               <ClientSI: all objects in Path message>

          PDP --> PEP   DEC := <Handle A>><Context in&out, Path>
                               <Decision accept>

   A Resv message arrives from R1:

          PEP --> PDP   REQ := <Handle B><Context in&merge&out, Resv>
                               <In-Interface if1> <Out-Interface if3>
                               <ClientSI: all objects in Resv message>

          PDP --> PEP   DEC := <Handle B>
                               <Context in&merge&out, Resv>
                               <Decisions: accept, Priority=7,
                                Replace: POLICY.DATA1>

          PEP --> PDP   RPT := <Handle B>
                               <Report type: commit>

   Time Passes, the PDP changes its decision:

          PDP --> PEP   DEC := <Handle B>
                               <Context in&merge&out, Resv>
                               <Decisions: accept, Priority=3,
                                Replace: POLICY.DATA2>

   Because the priority is too low, the PEP preempts the flow:

          PEP --> PDP   DRQ := <Handle B>
                               <Reason Code: Preempted>

   Time Passes, the sender S1 ceases to send Path messages:

          PEP --> PDP   DRQ := <Handle A>
                               <Reason: Timeout>

  4.2. Shared Multicast Flows

   This section details the steps in using COPS for controlling a
   multicast RSVP flow. It details the contents of the COPS messages
   with respect to the following figure.


Boyle et. al.             Expires June 1998                  [Page 7]


Internet Draft           COPS usage for RSVP            April 4, 1998

                               -----------------
                     r1       |                 |
               H1-------------|i1               |      r4
                              |              o1 |---------------- S1
                     r2       |     Router      |
               H2 ------------|i2               |
                     |        |              o2 |---------------- S2
                     | r3     |                 |
                     |         -----------------
                    H3

                figure 1: 2 senders and 3 receivers

   Figure 1 shows an RSVP router which has two senders and three
   receivers for the same multicast session. Interface i2 is connected
   to a shared media. H1, H2, and H3 are all receivers that send the
   corresponding reservations r1, r2, and r3 for the flows for senders
   S1 & S2.

   First detailed is the request message content for a Path sent by
   sender S1, assuming that both receivers have already joined the
   multicast session, but haven't sent a Resv message as yet. Assume
   sender S2 has not yet sent a path message. The Path message arrives
   on interface o1:

       PEP -----> PDP    REQ   := <handle A><context in, Path>
                                  <in-interface o1><client info: all
                                  objects in Path message>
       PDP -----> PEP    DEC   := <handle A><context in, Path>
                                  <Decision accept>

   Here the PDP decides to allow the Path message. Next, the Router
   consults its forwarding table, and finds two outgoing  interfaces,
   i1 and i2, for the path. The exchange below is for interface i1,
   another exchange would likewise be completed for i2 using the new
   handle B2.

       PEP -----> PDP    REQ   := <handle B1><context out, Path>
                                  <out-interface i1><client info: all
                                  objects in outgoing Path message>
       PDP -----> PEP    DEC   := <handle B1><Decision forward>
                                  <context out, Path>
                                  <Decision replacement object:
                                   policy object>

   Here, the PDP decided to allow the forwarding of the Path message
   via interface i1, and determined the appropriate policy objects for
   the message going out on this interface.



Boyle et. al.             Expires June 1998                  [Page 8]


Internet Draft           COPS usage for RSVP            April 4, 1998

   Next, the receiver r2 sends a Resv message of WF style. The Resv
   arrives on interface i2. Here the PEP queries the PDP which decides
   to accept this reservation with priority 5 as shown below.

       PEP -----> PDP    REQ   := <handle C><context in, Resv>
                                  <in-interface i2><client info: all
                                  objects in Resv message>
       PDP -----> PEP    DEC   := <handle C><Context in, Resv>
                                  <Decision accept>

   This assumes the PEP is not itself capable of merging priority
   information, and, thus, must make another query for the incoming
   interface merge.

       PEP -----> PDP    REQ   := <handle D><context merge, Resv>
                                  <in-interface i2><client info: all
                                  objects in merged Resv message>
       PDP -----> PEP    DEC   := <handle D><context merge, Resv>
                                  <Decision Priority: 5>

   After PEP successfully admitted the reservation it sends a report
   message that signals to the PDP that it can start an accounting log
   for this reservation.

       PEP -----> PDP    RPT   := <handle D>
                                  <commit>

   The reservation r2 needs to be sent upstream towards sender S1 out
   interface o1. An outgoing Resv request is made which carries the
   associated handle of the Path message for which this Resv is being
   forwarded.

       PEP -----> PDP    REQ   := <handle E><context out,Resv>
                                  <out-interface o1><client info: all
                                  objects in outgoing Resv message>
       PDP -----> PEP    DEC   := <handle E><Context out, Resv>
                                  <Decision forward><Decision
                                  replacement object: policy object>

   Next, receiver H3 sends the Resv message r3. The PEP sends an
   incoming request for handle F and the PDP decides to accept the Resv
   (as before). The new reservation also requires the PEP to update the
   merged request (handle D) due to the modified flowspec. The PDP now
   gives this request priority 7. If accepted by local admission
   control, a report is again sent.

       PEP -----> PDP    REQ   := <handle D><context merge, Resv>
                                  <in-interface i2><client info: all
                                  objects in merged Resv message w/
                                  new merged FLOWSPEC>

Boyle et. al.             Expires June 1998                  [Page 9]


Internet Draft           COPS usage for RSVP            April 4, 1998

       PDP -----> PEP    DEC   := <handle D><Context merge, Resv>
                                  <Decision priority 7>
       PEP -----> PDP    RPT   := <handle D>
                                  <commit>

   Now the outgoing request for handle E is reissued for the merged (R2
   & R3) outgoing Resv to be sent towards sender S1 due to a modified
   flowspec.

       PEP -----> PDP    REQ   := <handle E><context out,Resv>
                                  <out-interface o1><client info: all
                                  objects in outgoing Resv message w/
                                  new merged FLOWSPEC>
       PDP -----> PEP    DEC   := <handle E><Context out, Resv>
                                  <Decision forward><Decision
                                  replacement object: policy object>

   When S2 joins the session by sending a Path message, incoming and
   outgoing Path requests are issued for the new Path. The two incoming
   Resv requests may then be reissued for handle C and handle E if
   there is a change in their shared sender filter list (e.g. if this
   was a SE filter example) specifying the new sender. A new outgoing
   Resv request would then be issued for the Resv to be sent to s2 out
   interface o2.

5. References

   [RSVP-EXT]  Herzog, S. "RSVP Extensions for Policy Control",
          Internet-Draft, draft-ietf-rap-rsvp-ext-00.txt, Apr. 1998.

   [UserID]  Yadav, S., Pabbati, R., Ford, P., Herzog, S., "User
          Identity Representation for RSVP", Internet-Draft, draft-
          ietf-rap-user-identity-00.txt, March 1998.

   [RAP]  Yavatkar, R., et al., "A Framework for Policy Based Admission
          Control",IETF <draft-ietf-rap-framework-00.txt>, November,
          1997.

   [COPS]  Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R.,
          Sastry, A., "The COPS (Common Open Policy Service) Protocol",
          IETF <draft-ietf-rap-cops-02.txt>, Aug. 1998.

   [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,
   "Resource Reservation Protocol (RSVP) Version 1 Functional
   Specification", IETF RFC 2205, Proposed Standard, September 1997.

6. Author Information and Acknowledgments




Boyle et. al.             Expires June 1998                 [Page 10]


Internet Draft           COPS usage for RSVP            April 4, 1998

   Special thanks to Timothy O'Malley our WG Chair, Raj Yavatkar,
   Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan,
   and Dimitrios Pendarakis for their valuable contributions.

       Jim Boyle                        Ron Cohen
       Level 3 Communications           CISCO Systems
       1450 Infinite Drive13            Hasadna St.
       Louisville, CO 80027             Ra'anana 43650 Israel
       303.926.3100                     972.9.7462020
       email: jboyle@l3.net             ronc@cisco.com

       David Durham                     Raju Rajan
       Intel                            IBM T.J. Watson Research Cntr
       2111 NE 25th Avenue              P.O. Box 704
       Hillsboro, OR 97124              Yorktown Heights, NY 10598
       503.264.6232                     914.784.7260
       David_Durham@mail.intel.com      raju@watson.ibm.com

       Shai Herzog                      Arun Sastry
       IPHighway                        Cisco Systems
       2055 Gateway Pl., Suite 400      506210 W Tasman Drive
       San Jose, CA 95110               San Jose, CA 95134
       408.390.3045                     408.526.7685
       herzog@iphighway.com             asastry@cisco.com




























Boyle et. al.             Expires June 1998                 [Page 11]


Internet Draft           COPS usage for RSVP            April 4, 1998

   Table of Contents

Abstract..............................................................1
1. Introduction.....................................................2
2. RSVP values for COPS objects.....................................2
2.1. Context Object (Context)........................................2
2.2. Client Specific Information (ClientSI)..........................3
2.3. Decision Object (Decision)......................................3
3. Operation of COPS for Policy Control Over RSVP...................4
3.1. RSVP flows......................................................4
3.2. Expected Associations for RSVP Requests.........................4
3.3. RSVP's Capacity Admission Control: Commit and Delete............4
3.4. Policy Control Over Path and Resv Tear..........................5
3.5. PEP Caching COPS Decisions......................................5
3.6. Using Multiple Context Flags in a single query..................5
3.7. Trusted zones and secure policy tunneling.......................6
4. Illustrative Examples, Using COPS for RSVP.......................6
4.1. Unicast Flow Example............................................6
4.2. Shared Multicast Flows..........................................7
5. References......................................................10
6. Author Information and Acknowledgments..........................10





























Boyle et. al.             Expires June 1998                 [Page 12]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/