Internet Draft Nitsan Elfassy File: draft-nitsan-cops-rsvp-proxy-00.txt Dinesh Dutt Expiration Date: April 2000 Cisco Systems October 1999 COPS Extensions for RSVP Receiver Proxy Support Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document proposes an extension to [COPS-RSVP] and [COPS] documents needed to support RSVP Receiver Proxy [RSVP-PROXY] and the Null Service Type [NULL-SERV]. Elfassy, Dutt [Page 1] COPS extensions for RSVP Receiver Proxy support June 1999 Table of contents 1. Introduction ...................................................3 2. Functionality Required To Support RSVP Receiver Proxy...........3 2.1. Device Capabilities..........................................3 2.2. Role Combinations............................................4 2.3. Additional Decision Information..............................4 2.4. Path forwarding policy.......................................5 3. COPS Objects Used To Communicate The Additional Information.....5 4. Definitions of the New Objects..................................5 4.1. PEP Capabilities.............................................5 4.2. Role Combination.............................................7 5. Communicating Additional Decisions In DEC Message...............9 5.1. Policy Information to be included in the returned Resv.......9 6. Illustrative Example............................................9 7. Compatibility With Existing RSVP COPS Implementations..........10 7. References ....................................................11 8. Intellectual Property Considerations ..........................11 9. Author Information ............................................11 10. Full Copyright Statement .....................................12 Terminology o RSVP: Resource ReSerVation Protocol. o COPS: Common Open Policy Service. o DSCP: DiffServ Code Point. o Metering: the process of measuring the temporal properties (e.g., rate) of a traffic stream selected by a classifier. The instantaneous state of this process may be used to affect the operation of a marker, shaper, or dropper, and/or may be used for accounting and measurement purposes. o Policing: the process of discarding packets (by a dropper) within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile. o Traffic conditioning: control functions performed to enforce rules specified in a TCA, including metering, marking, shaping, and policing. o Microflow: A single instance of an application-to-application flow of packets which is identified by source address, source port, destination address, destination port and protocol id. Elfassy, Dutt [Page 2] COPS extensions for RSVP Receiver Proxy support June 1999 1. Introduction RSVP Receiver Proxy [RSVP-PROXY] defines an extension to the RSVP message processing mainly designed to operate in conjunction with the Null Service Type [NULL-SERV]. Null Service type is a new service type proposed for use with RSVP to support applications which cannot quantify their resource requirements. The determination of resource requirements for these applications is left to the discretion of the network administrator. The extension proposes that an intermediate router/switch receiving an RSVP Path message terminate the Path message instead of forwarding it all the way to the end destination. This router generates a proxy Resv message and sends it upstream. This originated Resv follows the same rules as any Resv message. Existing COPS support for RSVP does not contain mechanisms to support this new functionality proposed by RSVP Receiver Proxy. This document proposes extensions to enable the use of COPS with RSVP Receiver Proxy. 2. Functionality Required to support RSVP Receiver Proxy This section describes the nature of the additional information that needs to be exchanged between the PDP and the PEP to support RSVP Receiver Proxy and the Null Service Type. 2.1. Device capabilities RSVP requires that network nodes be capable of reserving resources to support bandwidth allocation. These devices must also be capable of enforcing the traffic to the specified bandwidth - specified via TSPEC - such that they do not use more than their share of resources. Traffic exceeding the specified TSPEC is dropped. The bandwidth allocation and enforcement needs to be supported per each outgoing interface. For example, a multicast flow going out two separate interfaces, could have different resource requirements. There are other capabilities such as marking that a device may or may not support. In order for the PDP to inform a PEP to enforce a decision, it would be useful for the PDP to know the capabilities of the PEP. Elfassy, Dutt [Page 3] COPS extensions for RSVP Receiver Proxy support June 1999 The device capabilities of interest follow. 2.1.1. Support for RSVP Receiver Proxy Current IntServ capable nodes do not support the additional functionality specified by RSVP Receiver Proxy. Before the PDP can send a decision which uses this functionality, it is necessary for the PDP to know if the device supports it. 2.1.2. Support for Marking This capability defines whether a node can mark packets and also the manner in which it can mark, using DSCP or only IP Precedence. 2.1.3. Support for Resource Reservation and Enforcement This defines the ability of a node to reserve resources and enforce it. It also specifies whether the node can provide this functionality per each outgoing interface or only per input interface. The enforcement is accomplished using a meter and a policer. 2.2. Role Combinations With the Null service type, the QoS assigned to a flow is upto the discretion of the network administrator. The network administrator may decide to use DiffServ to assign a QoS to the flow. The drafts related to provisioning of QoS policy in a DiffServ environment ([COPS-PR], [PIB]) specify that each interface has a set of roles associated with it. A role is simply a string that is associated with an interface and is used to group together interfaces that need to share a QoS policy. Each interface can have many roles. A "role combination" is an unordered set of roles. Specifying the role combination associated with the ingress and egress interface associated with the Path message provides for consistency and compatbility with DiffServ policy. 2.3. Additional Decision Information According to the new RSVP Receiver Proxy behavior, the RSVP Path message is not forwarded further. The node terminating the Path will instead originate the corresponding Resv message. This decision needs to be communicated to the PEP for a Path message. It is the PDP that decides what policy objects need to be in the Resv message. The PDP needs to communicate these objects to the PEP. Elfassy, Dutt [Page 4] COPS extensions for RSVP Receiver Proxy support June 1999 3. COPS Objects Used To Communicate The Additional Information The proposed extension defines new objects that are contained in the existing COPS objects. The objects used are: o Stateless Decision object o Client SI Named object o Policy Data object [POL-EXT] o DCLASS object [DCLASS] Further explanation is provided in the following sections. 4. Definitions of the New Objects 4.1. PEP Capabilities This section defines the objects used to communicate the RSVP-related device capabilities. The container object used to communicate the Client capabilities is a Policy Data Object. The capability information is implemented as policy elements [POL-EXT]. The definitions of the new policy elements follow. 4.1.1 RSVP_PROXY_SUPPORT policy element This policy element indicates if the PEP supports RSVP Receiver Proxy. This policy element MAY be sent in the Client Open message (in a POLICY DATA object that itself is encapsulated in COPS ClientSI Named object). If the Client does not add the RSVP_PROXY_SUPPORT in the Client Open message, the PDP assumes that the PEP does not support RSVP Receiver Proxy. +-------------+-------------+-------------+--------------------+ | Length = 8 | P-Type = RSVP_PROXY_SUPPORT | +------+------+-------------+-------------+--------------------+ | Flags | /// Reserved /// | +------+------+-------------+-------------+--------------------+ Length: 16 bits The overall length of the policy element, in octets. Equals 8. P-Type: 16 bits RSVP_PROXY_SUPPORT policy element, as registered with IANA. Elfassy, Dutt [Page 5] COPS extensions for RSVP Receiver Proxy support June 1999 flags: 16 bits The currently supported flags are: 0x00 - RSVP Receiver Proxy not supported 0x01 - RSVP Receiver Proxy supported 4.1.2. POLICING_SUPPORT policy element definition This policy element indicates if the device supports metering and policing. This policy element MAY be sent in REQ message or in the Client Open message. In case of the REQ message, the object is carried in a Named ClientSI Object following the Signaled ClientSI object that carries the RSVP message objects. If the Client Open or REQ message does not contain the POLICING_SUPPORT policy element, the PDP assumes the PEP supports both input and output policing (the PEP could be running older code which does not define this object). +-------------+-------------+-------------+--------------------+ | Length = 8 | P-Type = POLICING_SUPPORT | +------+------+-------------+-------------+--------------------+ | Flags | /// reserved //// | +------+------+-------------+-------------+--------------------+ Length: 16 bits The overall length of the policy element, in octets. Equals 8. P-Type: 16 bits POLICING_SUPPORT policy element, as registered with IANA. flags: 16 bits The currently supported flags are: 0x0 - No policing supported 0x1 - Only input-based policing 0x2 - Only output-based policing 0x3 - Both input and output-based policing 4.1.3. MARKING_SUPPORT policy element This policy element indicates the marking capabilities of the PEP. Marking is defined as setting the ToS byte of a packet based on some defined rules. This policy element MAY be sent in COPS REQ message or in the Client Open message. When the Client-Open or REQ message does not contain this element the PDP assumes the PEP has no marking capabilities. Elfassy, Dutt [Page 6] COPS extensions for RSVP Receiver Proxy support June 1999 +-------------+-------------+-------------+--------------------+ | Length = 8 | P-Type = MARKING_SUPPORT | +------+------+-------------+-------------+--------------------+ | Flags | /// reserved //// | +------+------+-------------+-------------+--------------------+ Length: 16 bits The overall length of the policy element, in octets. Equals 8. P-Type: 16 bits MARKING_SUPPORT policy element, as registered with IANA. flags: 16 bits The currently supported flags are: 0x0 - No Marking supported 0x1 - Only IP Precedence Marking 0x2 - DSCP based Marking 4.2. Role-Combination As specified in section 2.2, it may also be useful add the role-combinations assigned to the ingress and egress interfaces as part of the information communicated to the PDP. Two new objects have been defined to carry this information. The role-combination objects MAY be present in the REQ Message. The Named Client Specific Information Object (ClientSI Named) which carries the POLICY-DATA object also carries the role combination objects. There are two role-combination objects defined, IN_ROLE_COMB and OUT_ROLE_COMB. 4.2.1. In Interface Role-Combination policy element The format of In Interface Role Combination policy element is as follows: +-------------+-------------+-------------+-------------+ | Length (variable) | P-Type = IN_ROLE_COMB | +------+------+-------------+-------------+-------------+ | IN Role Combination | +------+------+-------------+-------------+-------------+ | ......... | +------+------+-------------+-------------+-------------+ Elfassy, Dutt [Page 7] COPS extensions for RSVP Receiver Proxy support June 1999 Length: 16 bits This is the overall length of the policy element, in octets. If the length in octets does not fall on a 32-bit word boundary, padding must be added to the end of the object so that it is aligned to the next 32-bit boundary. P-Type: 16 bits IN_ROLE_COMB policy element, as registered with IANA. IN Role Combination: Role Combination string. Role Combination is a display string as defined in [PIB]. IN_ROLE_COMB policy element MAY appear only once in the Policy Data object. If this element is absent in the REQ message, the PDP can assume a default IN Role-Combination. It is up to the PDP to figure out that default. 4.2.2. Out Interface Role Combination The format of Out Interface Role Combination policy element is as follows: +-------------+-------------+-------------+-------------+ | Length (variable) | P-Type = OUT_ROLE_COMB | +------+------+-------------+-------------+-------------+ | OUT Role Combination | +------+------+-------------+-------------+-------------+ | ....... | +------+------+-------------+-------------+-------------+ Length: 16 bits This is the overall length of the policy element, in octets. If the length in octets does not fall on a 32-bit word boundary, padding must be added to the end of the object so that it is aligned to the next 32-bit boundary. P-Type: 16 bits OUT_ROLE_COMB policy element, as registered with IANA. OUT Role Combination: Role Combination string. OUT_ROLE_COMB policy element MAY appear only once in the Policy Data object. In the absence of this element in the REQ message, the PDP may assume a default OUT Role-Combination, which makes it a policy decision. Elfassy, Dutt [Page 8] COPS extensions for RSVP Receiver Proxy support June 1999 5. Communicating Additional Decisions In DEC Message The current COPS for RSVP draft [COPS-RSVP] allows for the possibility of multiple context groups (section 3.6). We extend the use of multiple context groups to include the decision to originate a proxy Resv message. When the PDP gets a Path IN context REQ message, it returns back a DEC message with a context group for the Path IN context, as specified in [COPS-RSVP]. In order to instruct the PEP to originate Resv, the PDP will add another context group for Resv OUT context. Appearance of Resv OUT Decision context group in a DEC message sent for Path IN context, MUST be interpreted by the PEP as an instruction to install Resv state and originate a Resv upstream back to the previous hop defined in the Path message. When Path IN context is "bundled" in the same REQ message with other contexts, the following rule applies: The DEC message sent for this REQ MAY include a single Resv OUT Context Group and the PEP MUST take it as an extension to the Path IN Context Group. 5.1. Policy Information to be included in the returned Resv The DEC message described in the previous section will include all the information to be sent back to the Sender inside the Resv. The container object for this information is the Replacement Decision object under the Resv OUT context group added to the DEC message. Among the objects that may populate the Replacement Decision object are Policy Data Object(s), DCLASS object and TSPEC object. 6. Illustrative Example (Modified example from "COPS usage for RSVP" IETF draft). This section illustrates the steps in using COPS for controlling a unicast RSVP Receiver Proxy flow. h1 ----> R1 | | h1 <-----+ Figure 1: Single PEP View Assume that the PEP, R1 has two interfaces (if1, if2). Sender h1 sends to some receiver r1. R1 is a PEP along the path which supports RSVP Receiver Proxy. Let if1 be the interface on which h1 is connected to R1 and if2 be the outgoing interface associated with the receiver r1. Elfassy, Dutt [Page 9] COPS extensions for RSVP Receiver Proxy support June 1999 A. A Path message arrives from h1: PEP --> PDP REQ := PDP --> PEP DEC := The decision message instructs the PEP to accept the Path message in, originate a Resv and to not forward the Path further. 7. Compatibility With Existing RSVP COPS Implementations In order to inter-operate with existing RSVP COPS clients, the PDP must treat a Client-Open received with no capability objects specified as a device which does not support RSVP Receiver Proxy and send decisions which match the existing standard [COPS-RSVP]. The assumption made here is that clients which support the functionality detailed in this draft will also support the RSVP Receiver Proxy functionality. If a PEP supporting RSVP Receiver Proxy talks to an older PDP, the PDP will ignore the capability objects sent. It will therefore treat all incoming messages as quantitative service type objects. 8. Security Considerations This Section is TBD 9. References [RFC2205] 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. [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated Services," September 1997. [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 Elfassy, Dutt [Page 10] COPS extensions for RSVP Receiver Proxy support June 1999 [RSVP-PROXY] Gai S., Dutt D., Elfassy N., Bernet Y., RSVP Receiver Proxy, , October 1999. [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", IETF , February 1999. [COPS-RSVP] Jim Boyle, Ron Cohen, David Durham, Shai Herzog, Raju Rajan, Arun Sastry, "COPS usage for RSVP," , June 14, 1999 [POL-EXT] Shai Herzog, "RSVP Extensions for Policy Control," Internet Draft., < draft-ietf-rap-rsvp-ext-06.txt>, April 1999. [COPS-PR] Reichmeyer F., Kwok Ho Chan, Durham D., Yavatkar R., Gai S., McCloghrie K., Herzog S., Smith A. "COPS Usage for Policy Provisioning", draft-sgai-cops-provisioning-00.txt, February 1999. [DCLASS] Bernet, Y., "Usage and Format of the DCLASS Object With RSVP Signalling", , August 1999. [NULL-SERV] Yoram Bernet, Andrew Smith, Bruce Davie, "Specification of the Null Service Type", , September 1999. [PIB] M. Fine, K. McCloghrie et. al, "An Initial Policy Information Base For COPS-PR Clients and Servers", February 1999. 10. Intellectual Property Considerations The IETF is being notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 11. Author Information Nitsan Elfassy Cisco Systems, Inc. 4 Maskit St, P.O.Box 12497 Herzelia Pituach 46766, Israel Phone: +972 9 970 0066 email: nitsan@cisco.com Elfassy, Dutt [Page 11] COPS extensions for RSVP Receiver Proxy support June 1999 Dinesh Dutt Cisco Systems, Inc. 170 Tasman Dr. San Jose, CA 95134-1706 Phone: (408) 527-0955 email: ddutt@cisco.com 12. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Elfassy, Dutt [Page 12]