Internet DRAFT - draft-xu-cops-push

draft-xu-cops-push






Network Working Group                                              H. Xu
Internet-Draft                                                  H. Huang
Updates: 2748 (if approved)                                    CATR, MII
Intended status: Standards Track                         T. Taylor (Ed.)
Expires: August 19, 2007                                          Nortel
                                                       February 15, 2007


     A Modification to COPS to Improve Implementation of Push Mode
                         draft-xu-cops-push-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 19, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).












Xu, et al.               Expires August 19, 2007                [Page 1]

Internet-Draft               COPS Push Mode                February 2007


Abstract

   COPS (RFC 2748) was originally designed for pull mode operation.  The
   message exchanges for pull mode are efficient and support a close
   relationship between the protocol operations and state associated
   with particular events detected at the Policy Enforcement Point
   (PEP).  The operation of push mode, as defined in COPS-PR (RFC 3084),
   is more awkward.  Push mode involves extra messaging between the PEP
   and the Policy Decision Point (PDP) if one again wants to associate
   state arising from specific events (this time detected at the PDP)
   with specific protocol operations.

   This memo proposes to modify RFC 2748 to make push mode operation
   more efficient.  Comments are invited on whether there are issues
   with the proposed solution.




































Xu, et al.               Expires August 19, 2007                [Page 2]

Internet-Draft               COPS Push Mode                February 2007


1.  Introduction

1.1.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant implementations.

1.2.  Description of the Problem

   Consider a system consisting of a Policy Enforcement Point (PEP) and
   Policy Decision Point (PDP) as defined in RFC 2748 [2], bound
   together in a COPS signalling relationship.  Suppose this
   relationship has progressed to the point where the Client-Open sent
   by the PEP has been exchanged with a Client-Accept response from the
   PDP.  Both the PEP and the PDP face other nodes which can originate
   events that require communication between the PEP and PDP.  These
   events are of three types:

   o  initiating events introduce new state at the PEP and PDP;

   o  modifying events require changes in existing state at the PEP and
      PDP;

   o  clearing events require deletion of existing state at the PEP and
      PDP.

   In each case, the state can consist of multiple pieces of information
   bound together by a common correlating object.

   Consider the case where an initiating event is detected at the PEP --
   the basic pull mode of operation.  In COPS terms, the PEP sends a
   Request (REQ) message to PDP, carrying a correlator in the Client-
   Handle object along with other objects carrying the information the
   PDP needs to have to generate the policy appropriate to the event.
   The PDP associates state with the Client-Handle value, generates the
   necessary policy update for the event, and returns that policy in a
   Decision (DEC) message.  The PEP must respond to every DEC message
   with a Report-State (RPT) message indicating the outcome of the
   request.

   If the PEP detects a modifying event, it sends an unsolicited RPT
   message to the PDP using the same Client-Handle value it allocated
   for the initiating event.  The PDP observes that the Client-Handle
   matches active local state, modifies that state on the basis of the
   new information in the RPT message, and returns any necessary policy
   updates in another DEC message.



Xu, et al.               Expires August 19, 2007                [Page 3]

Internet-Draft               COPS Push Mode                February 2007


   Finally, if the PEP detects a clearing event, it sends a Delete
   Request (DRQ) message with the same Client-Handle value as in the
   previous messages.  It clears local state and deallocates the Client-
   Handle value.  Upon receiving the Delete Request, the PDP does the
   same.

   These sequences are illustrated in Figure 1.

                PEP                    PDP
   Initiating    |                      |
      event      |                      |
   ------------->|  REQ (new handle)    |
                 |--------------------->|
                 |  DEC (handle, policy)|
                 |<---------------------|
                 |  RPT (handle, ...)   |
                 |--------------------->|
                        . . .
   Modifying     |                      |
      event      |                      |
   ------------->|  RPT (handle, ...)   |
                 |--------------------->|
                 |  DEC (handle, policy)|
                 |<---------------------|
                 |  RPT (handle, ...)   |
                 |--------------------->|
                        . . .
   Clearing      |                      |
      event      |                      |
   ------------->|  DRQ (handle, ...)   |
                 |--------------------->|


                 Figure 1: Message Sequences In Pull Mode

   In summary, in pull mode, the COPS protocol mechanisms support an
   efficient exchange of information between the PEP and PDP throughout
   the event life cycle.

   Now consider the event-driven push mode case.  The PDP detects an
   event that requires the installation of new policy at the PEP.  Under
   the rules of COPS, however, it cannot send that policy information
   until the PEP has allocated a new Client-Handle value in a Request
   message.  This has two implications:

   o  The COPS session is not initialized for push mode operation until
      the PEP has sent a first Request message to the PDP.  This is
      illustrated in the first sequence in Figure 2, where the PEP



Xu, et al.               Expires August 19, 2007                [Page 4]

Internet-Draft               COPS Push Mode                February 2007


      supplies handle 0 in the initial REQ.

   o  If the PDP wants to install new state in response to an initiating
      event, it must first ask the PEP to allocate a new Client-Handle
      value by sending a new REQ message containing that value.  This
      means an extra messaging round-trip and an extra RPT before the
      new state can be installed.

   The COPS rule for deallocation of Client-Handle values also imposes
   two extra messages when the PDP detects a clearing event.  The PDP
   must request the PEP to deallocate the Client-Handle value, and does
   so using a DEC message.  The PEP returns a Delete Request (DRQ) to do
   so, and also the usual RPT response to the DEC.  This sequence is
   clearly redundant.  At least one message could be saved with a
   different approach.  Since unacknowledged deletion is acceptable in
   the pull mode case, it could be argued that neither PEP message, DRQ
   or RPT, is strictly necessary.

   The one case where push mode works better than pull is that of a
   modifying event.  Compared with pull mode, push requires one less RPT
   in this case.

   The push mode sequences as specified by RFC 3084 (COPS-PR) are shown
   in Figure 2.



























Xu, et al.               Expires August 19, 2007                [Page 5]

Internet-Draft               COPS Push Mode                February 2007


     PEP                    PDP
      |                      |
      |                      |
      |  REQ (handle 0)      |
      |--------------------->|
      |  DEC (handle 0, ...) |
      |<---------------------|
      |  RPT (handle 0, ...) |
      |--------------------->|
             . . .
      |                      | Initiating
      |                      |    event
      |  DEC (handle 0,      |<------------
      |       Request-State) |
      |<---------------------|
      |  RPT (handle 0, ...) |
      |--------------------->|
      |  REQ (handle 1)      |
      |--------------------->|
      |  DEC (handle 1, ...) |
      |<---------------------|
      |  RPT (handle 1, ...) |
      |--------------------->|
             . . .
      |                      | Modifying
      |                      |    event
      |  DEC (handle 1, ...) |<------------
      |<---------------------|
      |  RPT (handle 1, ...) |
      |--------------------->|
                        . . .
      |                      | Clearing
      |                      |    event
      |  DEC (handle 1,      |<------------
      |       Request-Delete)|
      |<---------------------|
      |  RPT (handle 1, ...) |
      |--------------------->|
      |  DRQ (handle 1, ...) |
      |--------------------->|


            Figure 2: Message Sequences In Push Mode (RFC 3084)

   In sum, when operating in push mode COPS requires two extra messages
   to allocate a Client-Handle value when an initiating event is
   detected, and two extra messages to deallocate a Client-Handle value
   when a clearing event is detected, compared with pull mode.  If this



Xu, et al.               Expires August 19, 2007                [Page 6]

Internet-Draft               COPS Push Mode                February 2007


   extra overhead could be eliminated, it would significantly enhance
   server event handling capacity in push mode.

















































Xu, et al.               Expires August 19, 2007                [Page 7]

Internet-Draft               COPS Push Mode                February 2007


2.  Approaches to a More Efficient Push Mode

   One possible response to the problem statement of the previous
   section is to discard the association between the Client-Handle value
   and the state associated with individual events.  This was the
   approach taken by PacketCable [4].  The initial Request creates a
   permanent session between the PEP and PDP, associated with a single
   Client-Handle value.  The state associated with each initiating and
   modifying event is tied together using a separate correlator value
   defined as a subsidiary object within the messages passed between PEP
   and PDP.  Cleardown requires explicit deletion of the individual
   state objects.  The implication with this approach is that the COPS
   protocol mechanisms that support state management in pull mode are
   ignored in push mode.

   An alternative approach is to modify the COPS protocol so that it is
   possible to handle push mode as efficiently as pull mode.  The
   analysis in the previous section identified four extra messages in
   push mode compared with pull mode.  Two of those messages can be
   saved if the PDP can send new policy data in the same message as the
   request for allocation of a new Client-Handle value.  Another message
   can be saved if the PDP itself is allowed to propose new Client-
   Handle values.  Finally, two messages can be saved if the PDP can
   order Client-Handle deallocation and deletion of the associated state
   without requiring a message from the PEP to complete the action.  Let
   us look at the details of each of these possibilities.

2.1.  Same Message Requests Allocation of Client-Handle Value and
      Provides Associated Policy

   Two ways come to mind to implement the new functionality.  The first
   is to modify the rules specified in section 3.2 of RFC 3084 for using
   the Decision message to request allocation of a new Client-Handle
   value.  These rules currently say that whenever the Request-State
   flag is set in the COPS Decision Flags object in the DEC message, no
   COPS Named Decision Data object can be included in the corresponding
   decision.  Rather than change RFC 3084 itself, it would be
   procedurally simpler to add a new Decision Flag value which allows
   data along with the request for a new state.

   Section 3.2 of RFC 3084 also specifies that the PEP responds to the
   Request-State flag with a new REQ message carrying the new Client-
   Handle value (as shown in the second sequence in Figure 2).  If a new
   Decision Flag value is defined, it would make sense to skip the now-
   redundant REQ step and return the new Client-Handle value in the
   mandatory RPT response.

   This approach has a couple of issues beyond introducing new COPS



Xu, et al.               Expires August 19, 2007                [Page 8]

Internet-Draft               COPS Push Mode                February 2007


   behaviour.  One is fairly easily resolved: the question of what
   Client-Handle value to use in the DEC message containing the new
   Decision Flag value.  The simplest answer is that this could be
   handle 0 from the initial startup sequence shown in Figure 2.  The
   second issue is how the PDP will correlate the RPT response with the
   DEC message that it sent.  The base COPS rules for solicited message
   flagging might serve to resolve this, but another solution is
   proposed in the next section.

   The alternative to adding a new Decision Flag value and associated
   behaviour is to define an entirely new COPS command, e.g., Push-
   Request (PRQ).  The command syntax could omit the Client-Handle
   object.  Otherwise the operation would be similar to that for the
   Decision message with the new Decision Flag value, with the allocated
   Client-Handle value returned in an obligatory RPT response.  The
   resulting message sequence is shown in Figure 3.  The sequence would
   be the same if using DEC with a new decision flag value as discussed
   earlier in this section.

                PEP                    PDP
      |                      |
      |                      |
      |  REQ (handle 0)      |
      |--------------------->|
      |  DEC (handle 0, ...) |
      |<---------------------|
      |  RPT (handle 0, ...) |
      |--------------------->|
             . . .
      |                      | Initiating
      |                      |    event
      |  PRQ (handle 0,      |<------------
      |       policy)        |
      |<---------------------|
      |  RPT (handle 1, ...) |
      |--------------------->|
             . . .
      |                      | Modifying
      |                      |    event
      |  DEC (handle 1, ...) |<------------
      |<---------------------|
      |  RPT (handle 1, ...) |
      |--------------------->|
                        . . .


        Figure 3: Push Mode Message Sequences With New PRQ Command




Xu, et al.               Expires August 19, 2007                [Page 9]

Internet-Draft               COPS Push Mode                February 2007


   Backward compatibility is a minor concern here.  In the case of a new
   Decision Flag value, RFC 2748 section 2.2.6 states that: "Flag values
   not applicable to a given context's R-Type or client-type MUST be
   ignored by the PEP."  It is not totally clear what this implies in
   terms of the response received from the PEP, but it is likely the PDP
   would be able to recognize that its request had not been honoured.
   The probable PEP response to a new command type it didn't recognize
   would be to close the client session.  In either case (new Decision
   Flag value or new command), a PDP recognizing that its request had
   not been recognized would be required to revert to the behaviour
   required by section 3.2 of RFC 3084 as illustrated in Figure 2.

2.2.  PDP-Allocated Client-Handle Value

   This section builds on the proposal in the previous section to add a
   new Decision Flag value.  The suggestion in that section was to try
   to avoid following the DEC with a new REQ request from the PEP.  The
   issue with that was the problem of correlating the handle in the RPT
   response from the PEP with the DEC message that requested it.

   A way to get around the correlation problem is to offer a Client-
   Handle value in the DEC message.  The PEP would either accept this
   offer by including the proposed value as the Client-Handle in the
   answering RPT, or reject it by returning an error (e.g. because the
   value collides with one generated by the PEP).  This solution would
   save three messages compared with the five-message sequence shown in
   Figure 2.  Figure 4 shows the new message sequence with this
   proposal.























Xu, et al.               Expires August 19, 2007               [Page 10]

Internet-Draft               COPS Push Mode                February 2007


                PEP                    PDP
      |                      |
      |                      |
      |  REQ (handle 0)      |
      |--------------------->|
      |  DEC (handle 0, ...) |
      |<---------------------|
      |  RPT (handle 0, ...) |
      |--------------------->|
             . . .
      |                      | Initiating
      |                      |    event
      |  DEC (handle 1,      |<------------
      |   policy, PUSH-STATE)|
      |<---------------------|
      |  RPT (handle 1, ...) |
      |--------------------->|
             . . .
      |                      | Modifying
      |                      |    event
      |  DEC (handle 1, ...) |<------------
      |<---------------------|
      |  RPT (handle 1, ...) |
      |--------------------->|
                        . . .


   Figure 4: Push Mode Message Sequences With New Decison Flag Value and
                     PDP-Proposed Client Handle Value

2.3.  Allowing the PDP To Delete Request State

   Two more messages would be saved if the PDP could order state
   deletion directly.  The simplest way to specify this capability would
   be by adding another new COPS command, Push-Delete (PDL).  The new
   command syntax would include the Client-Handle object with the value
   the PDP wishes to retire.  The PEP would retire the handle and delete
   all associated state without sending any response.













Xu, et al.               Expires August 19, 2007               [Page 11]

Internet-Draft               COPS Push Mode                February 2007


3.  Design Proposal

   We propose to standardize the design changes proposed in Section 2.2
   and Section 2.3.  Comments are requested before this document is
   fleshed out.














































Xu, et al.               Expires August 19, 2007               [Page 12]

Internet-Draft               COPS Push Mode                February 2007


4.  Security Considerations

   To be filled in when design choices are confirmed.  At the moment, it
   does not appear that the proposals introduce security concerns beyond
   those of the basic COPS and COPS-PR specifications.














































Xu, et al.               Expires August 19, 2007               [Page 13]

Internet-Draft               COPS Push Mode                February 2007


5.  IANA Considerations

   To be filled in when design choices are confirmed.
















































Xu, et al.               Expires August 19, 2007               [Page 14]

Internet-Draft               COPS Push Mode                February 2007


6.  References

6.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A.
        Sastry, "The COPS (Common Open Policy Service) Protocol",
        RFC 2748, January 2000.

   [3]  Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
        Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS
        Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.

6.2.  Informative References

   [4]  Cable Television Laboratories, Inc., "PacketCable (TM) 1.5
        Specifications; Dynamic Quality-of-Service;", PacketCable (TM)
        1.5 Specifications PKT-SP-DQOS1.5-I02-050812, August 2005.































Xu, et al.               Expires August 19, 2007               [Page 15]

Internet-Draft               COPS Push Mode                February 2007


Authors' Addresses

   Heyuan Xu
   CATR, MII
   Beijing
   CN

   Email: xuheyuan@mail.ritt.com.cn


   Hexian Huang
   CATR, MII
   Beijing
   CN

   Email: huanghexian@mail.ritt.com.cn


   Tom Taylor
   Nortel
   1852 Lorraine Ave
   Ottawa, Ontario  K1H 6Z8
   CA

   Email: taylor@nortel.com


























Xu, et al.               Expires August 19, 2007               [Page 16]

Internet-Draft               COPS Push Mode                February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Xu, et al.               Expires August 19, 2007               [Page 17]