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]