HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 10:32:02 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 01 Jul 1999 10:27:00 GMT ETag: "361ce8-8234-377b4274" Accept-Ranges: bytes Content-Length: 33332 Connection: close Content-Type: text/plain Internet Draft Nitsan Elfassy File: draft-nitsan-cops-rsvp-ext-00.txt Dinesh Dutt Cisco Systems June 1999 COPS Extensions for RSVP+ 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. It Describes the COPS extensions needed to communicate RSVP+ [RSVP+] extended policy information between the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP). Elfassy, Dutt [Page 1] COPS extensions for RSVP+ support June 1999 Table of contents 1. Introduction ...................................................3 2. COPS Behavioral Elements Required by RSVP+......................3 2.1. RSVP+ device Capabilities....................................3 2.2. Additional information on Request Message....................4 2.3. Generate Resv................................................4 2.4. Path forwarding policy.......................................5 3. Use of COPS Client Specific Information.........................5 4. COPS extensions.................................................6 4.1. Communicating RSVP PEP capabilities..........................6 4.2. RSVP+ specific information in COPS REQ messages..............9 4.3. Originating Resv............................................11 4.4. Path forward policy.........................................14 5. Compatibility With Existing RSVP COPS Implementations..........16 6. Security Considerations .......................................16 7. References ....................................................16 8. Intellectual Property Considerations ..........................17 9. Author Information ............................................17 9. Full Copyright Statement ......................................18 Terminology o RSVP: Resource ReSerVation Protocol. o COPS: Common Open Policy Service. o DSCP: DiffServ Code Point. o Policer/Limiter: A group of parameters that together provide the needed information to limit or shape a micro-flow. 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+ support June 1999 1. Introduction Current COPS definition does not provide the means to communicate the additional RSVP+ [RSVP+] policy actions and information between the Policy Server (Policy Decision Point) and the Device (Policy Enforcement Point - PEP). This document describes a proposal for COPS extension to provide the needed means. 2. COPS Behavioral elements required by RSVP+ This section describes the extra policy information exchanged by PDP and PEP in RSVP+ [RSVP+], for which COPS protocol has no placeholder. 2.1. RSVP+ device capabilities Traditional RSVP assumes that RSVP nodes are capable of reserving resources to support bandwidth allocation and rate limiting for the signaled traffic up to the specified TSPEC. It was also assumed that the devices could support both input and output-based rate limiting. For example, a mulitcast flow going out two separate interfaces, could be rate-limited differently based on the outgoing interface. Marking of packets with either an IP Precedence or DSCP was not required. With RSVP+, a PEP supporting qualitative service needs to support Marking in addition to supporting rate-limiting. All devices may not be capable of marking packets and they may even differ in their ability to mark packets. Some devices may only support marking using the 8 values of IP precedence whereas some other nodes may support the newer DSCP marking. Also, with qualitative support in RSVP, the rate-limiting requirements are less strict. It maybe acceptable for a PEP to not even support rate-limiting. Elfassy, Dutt [Page 3] COPS extensions for RSVP+ support June 1999 Finally, before downloading policy to a device, the PDP should be aware of whether the PEP supports the relevant service (qualitative or one or more of the quantitative service types). Given these looser requirements from a network device to support RSVP+, it would be useful for the PDP to be able to know a PEP's limitations before attempting to download policy. This leads to the requirement of having the PEP communicate to the PDP its capabilities. The device capabilities should include the following: o Qualitative/Quantitative support. IntServ capable nodes are assumed to support quantitative RSVP only. DiffServ capable nodes shall inform the PDP whether they support also IntServ (quantitative RSVP). o Flow marking capabilities A qualitative PEP SHOULD inform the PDP whether it can do packet marking and whether it supports marking using IP precedence only or marking via the DS byte. o Rate Limiting capabilities Qualitative RSVP node SHOULD inform the PDP whether it can do input output or both directions rate limiting of microflows. 2.2. Additional information on REQ Message: RSVP+ specifies additional information that qualitative PEPs should add in the REQ message. That information is the Role Combination assigned to the ingress and egress interfaces (Role Combination is described in [PIB]). Also the PEP MAY communicate device capabilities that relate to the interfaces specified in the COPS Request message. Refer to 3.1 (two last sub-sections) for the relevant capabilities 2.3. Generate Resv: According to the new qualitative RSVP+ scenarios (cases (b) and (d) in [RSVP+]) when the receiver is not expected or trusted to return Resv, Elfassy, Dutt [Page 4] COPS extensions for RSVP+ support June 1999 the PDP may optionally instruct the PEP to return Resv to the Sender immediately. i.e. before or regardless of Resv arrival from downstream. The PDP should also provide the PEP with the policy information (DCLASS policy object [DCLASS]) to be included in the returned Resv message. 2.4. Path forwarding policy The RSVP+ extension defines two new ways to forward Path messages. Firstly, Path messages could be forwarded directly to the Receiver while skipping the following downstream RSVP Hops by removing the Router Alert Option. The second new way to forward Path messages is to change the RSVP Protocol Number to "qualitative RSVP protocol number" (This protocol number is yet to be defined) in order to ensure being handled only by RSVP+ capable RSVP hops. 3. Use of COPS Client Specific Information COPS protocol [COPS] specifies placeholders for Client Specific information. The following sections specify the use of some of those objects in the context of RSVP+. The following COPS objects are used to carry Client Specific information [COPS] in RSVP and RSVP+ cases: Stateless Decision object Used in COPS Decision Message to transfer stateless Policy information that can be applied by the PEP locally. Client SI Named object Optionally used in Open Client and Request COPS messages to communicate Client specific information. In order to communicate policy data between the PEP and PDP, we make use of conventional RSVP objects as placeholders for this policy. We now identify the following objects as candidates for this use: Policy Data object [POL-EXT] This object is used to communicate various policy data items as described in the following sections. Elfassy, Dutt [Page 5] COPS extensions for RSVP+ support June 1999 DCLASS object [DCLASS] This object is used to communicate DSCP value(s) for the flow in hand. SENDER TSPEC object This object is used as placeholder to communicate token bucket parameters as specified in the following sections. Further explanation is provided by the following sections. 4. COPS extensions This section specifies extensions to COPS that enable communicate the items described above between the PDP and PEP. 4.1. Communicating RSVP PEP capabilities This section defines the placeholders for the RSVP device capabilities. RSVP PEP capabilities SHOULD be reported either within the Client Open or Request (REQ) message issued by the PEP as further specified in this section. The RSVP Client SHOULD add the capabilities within the ClientSI object of either the Client Open (OPN) or Request (REQ) messages. The placeholder to communicate the Client capabilities is a Policy Data Object [POL-EXT]. The capability information items are implemented as policy elements [POL-EXT]. This section specifies the policy elements needed to communicate the device capabilities to the PDP. For each policy element this section specifies whether it is to be sent in the Client Open or Request message. The following new policy elements are defined: 4.1.1 RSVP-SVC-SUPPORT policy element This policy element indicates whether the device supports qualitative, quantitative or both RSVP services. This policy element MIGHT 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-SVC-SUPPORT in the Client Open message, the PDP assumes the Client is qualitative RSVP node. Elfassy, Dutt [Page 6] COPS extensions for RSVP+ support June 1999 +-------------+-------------+-------------+--------------------+ | Length = 8 | P-Type = RSVP-SVC-SUPPORT | +------+------+-------------+-------------+--------------------+ | Flags | /// reserved //// | +------+------+-------------+-------------+--------------------+ Length: 16 bits The overall length of the policy element, in octets. Equals 8. P-Type: 16 bits RSVP-SVC-SUPPORT policy element, as registered with IANA. flags: 16 bits The currently supported flags are: 0x0 - Quantitative Service Only 0x1 - Qualitative Service Only 0x2 - Both qualitative and quantitative 4.1.2. RATE-LIMITING-SUPPORT policy element definition This policy element indicates what kind of rate limiting the device supports, if at all. Rate limiting is defined as ensuring that a microflow conforms to a traffic specification implemented using say, a token bucket. Packets exceeding the contract can either be dropped or optionally remarked with a different codepoint reflecting a degraded service. This policy element MAY be sent in REQ message. (In a Named ClientSI Object following the Signaled ClientSI object that carries the RSVP message objects). If the REQ message lacks the RATE-LIMITING-SUPPORT policy element, the PDP assumes the PEP does not support rate limiting. +-------------+-------------+-------------+--------------------+ | Length = 8 | P-Type = RATE-LIMITING-SUPPORT | +------+------+-------------+-------------+--------------------+ | Flags | /// reserved //// | +------+------+-------------+-------------+--------------------+ Length: 16 bits The overall length of the policy element, in octets. Equals 8. Elfassy, Dutt [Page 7] COPS extensions for RSVP+ support June 1999 P-Type: 16 bits RATE-LIMITING-SUPPORT policy element, as registered with IANA. flags: 16 bits The currently supported flags are: 0x0 - No rate limiting supported 0x1 - Only input-based rate limiting 0x2 - Only output-based rate limiting 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. When REQ message does not contain this element the PDP assumes the PEP has no marking capabilities. +-------------+-------------+-------------+--------------------+ | 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 Tagging supported 0x1 - Only IP Precedence Tagging 0x2 - Only DSCP based Tagging Elfassy, Dutt [Page 8] COPS extensions for RSVP+ support June 1999 4.2. RSVP+ specific information in COPS REQ messages It is required [RSVP+] that the PEP adds information in the REQ message. An available placeholder to communicate further information in the REQ Message (refer to [COPS] section 3.1 for REQ message definition) is a Named Client Specific Information Object (ClientSI Named) which may be concatenated to the ClientSI Signaled which carries the RSVP massage objects. The Named ClientSI object will carry POLICY DATA object [POL-EXT] originated by the PEP. This object will include RSVP+ information the PEP may wish to communicate to the PDP. This POLICY DATA object includes several policy elements. Section 4.1.2. and 4.1.3. describes two policy elements (Capabilities) that MAY populate this object. This section describes another two. 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_COMBO | +------+------+-------------+-------------+-------------+ | IN 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 IN_ROLE_COMBO policy element, as registered with IANA. IN Role Combination: Role Combination string. Role Combination is a display string as defined in [PIB]. Elfassy, Dutt [Page 9] COPS extensions for RSVP+ support June 1999 IN_ROLE_COMBO 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 defalut 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_COMBO | +------+------+-------------+-------------+-------------+ | 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_COMBO policy element, as registered with IANA. OUT Role Combination: Role Combination string. OUT_ROLE_COMBO 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 10] COPS extensions for RSVP+ support June 1999 4.3. Originating Resv This section describes the extensions needed to instruct the PEP to originate Resv message. These extensions will populate COPS DEC message sent for Path IN context REQ message. 4.3.1. Originate Resv Instruction Instructing the PEP to return a Resv is therefore done as follows: First, let's define the term 'Decision Context Group'. COPS DEC message definition allows for several appearances of the following group of objects - Context object followed by several Decision objects (of different C-Types). We define this group as - Decision Context Group or Context Group. Although the [COPS] spec does not explicitly specify, it is quite clear that the DEC message shall include at least one Context Group for each CONTEXT in a "bundled" REQ message (refer to [COPS-RSVP], section 3.6. - Using multiple Context Flags in a single query). We extend the use of multiple Context Groups to the following Case: 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]. However, 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, shall be interpreted by the PEP as an instruction to install Resv state and originate Resv upstream (According to the decision objects content). The interface though which the PEP shall originate the Resv message is the same one indicated in the suitable In Interface COPS object (in the REQ message). Note that installation of Resv state on the PEP prior to handling a "real" incoming Resv message is a new behavior RSVP+ requires from RSVP capable router. This Resv state could be updated or changed when a suitable 'real' Resv arrives upstream. (note that according to [RSVP+], Resv is not always expected because RSVP+ deals with situations where the receiver is not necessarily RSVP aware. Refer to [RSVP+] for more) Section (TBD) describes how shall the PDP update or change the reviously installed Resv state when a real Resv arrives from downstream. Elfassy, Dutt [Page 11] COPS extensions for RSVP+ support June 1999 When Path IN context is "bundled" in the same REQ message with other contexts, the following rule apply: The DEC message sent for this REQ MAY include a single Resv OUT Decision Context Group and the PEP MUST take it as an extension to the Path IN Decision Context Group. Note, that the PDP will not send this context group to RSVP client that does not support Qualitative service. 4.3.2. Policy Information to be included in the returned Resv. The decision message described in the previous section will include all the information to be sent back to the Sender inside the Resv. The placeholder for this information is the Replacement Decision object under the Resv OUT context group added to the DEC message. Among the objects that will probably populate the Replacement Decision object we may find Policy Data Object(s), DCLASS object (that will include the DSCP with which to color the flow), Rspec object (used to communicate limiting parameters). Usage Example: (Modified example from "COPS usage for RSVP" IETF draft). 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. Let's demonstrate the support of Case B in [RSVP+]: H1 ----> R1 | | H1 <-----+ PEP (router) +-----------------+ | | R1 ------------+if1 if2+------------ S1 | | +-----------------+ Figure 1: Unicast Example: a single PEP view The PEP router has two interfaces (if1, if2). Sender S1 sends to receiver R1. Elfassy, Dutt [Page 12] COPS extensions for RSVP+ support June 1999 A. A Path message arrives from S1: Sub-case 1: The REQ message is not bundled. First a REQ message with Path In context is sent: PEP --> PDP REQ := PDP --> PEP DEC := PEP --> PDP RPT := Then a REQ message for the out Path context is sent: PEP --> PDP REQ := PDP --> PEP DEC := PEP --> PDP RPT := Sub-case 2: The REQ message is bundled. PEP --> PDP REQ := Elfassy, Dutt [Page 13] COPS extensions for RSVP+ support June 1999 PDP --> PEP DEC := The decision message instructs the PEP to accept the Path message in, then return Resv and don't forward the Path outward. (Which is case B in [RSVP+]). 4.4. Path forward policy. This section describes the extensions needed for DEC message sent for Path OUT context REQ message. The PDP may instruct the PEP to forward the path in one of the following ways: o With or without Router Alert Option. o Change the RSVP protocol number to regular RSVP protocol number (46) or to the new one (Yet TBD). The PDP will use a policy element to indicate the wanted Path forward Policy. This policy element will be encapsulated in RSVP Policy Data Object, which itself is encapsulated in COPS Stateless Decision Object. This Stateless Decision Object will be part of the Path Out context Group. 4.4.1 DECISION-FLAGS Policy Element +-------------+-------------+-------------+-------------+ | Length = 8 | P-Type = DECISION-FLAGS | +------+------+-------------+-------------+-------------+ | PathOutFlags| /// reserved for future use /// | +------+------+-------------+-------------+-------------+ Length: 16 bits The overall length of the policy element, in octets. Equals 8. Elfassy, Dutt [Page 14] COPS extensions for RSVP+ support June 1999 P-Type: 16 bits DECISION-FLAGS policy element, as registered with IANA. PathOutFlags: 0x1 - Forward Path by stripping RA option If this flag is set the PDP shall forward the path Without the Router Alert option. 0x2 - Forward Path by changing protocol number If this flag is unset the PDP shall forward the path message with RSVP protocol number 46, else with protocol number (TBD). The rest of this field is reserved for future use and shall set to Zero. Usage example: Implementing Case C in [RSVP+]: Asking the PEP to (1) Color the flow with DSCP = 60, (2) Remove the Route Alert Option. H1 ----> R1 --------------------------------------------------> H2 | | H1 <---- R1 < --------------------------------------------------+ PEP --> PDP REQ := PDP --> PEP DEC := /* For IN Path Context admit it and color flow */ PEP --> PDP RPT := Elfassy, Dutt [Page 15] COPS extensions for RSVP+ support June 1999 5. 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 legacy client and send decisions which match the existing standard [COPS-RSVP]. If a PEP supporting RSVP+ 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. 6. Security Considerations This Section is TBD 7. 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 [RSVP+] Gai S., Dutt D., Elfassy N., Barnet Y., RSVP+: An Extension To RSVP, , June 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. Elfassy, Dutt [Page 16] COPS extensions for RSVP+ support June 1999 [PIB] M. Fine, K. McCloghrie et. al, "An Initial Policy Information Base For COPS-PR Clients and Servers", February 1999. [DCLASS] Bernet, Y., "Usage and Format of the DCLASS Object With RSVP Signaling," , June 1999. [QualSvc] Tim Moore, Yoram Bernet, Andrew Smith, "Specification of the Qualitative Service Type," , February 1999 7. 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. 8. 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 Dinesh Dutt Cisco Systems, Inc. 170 Tasman Dr. San Jose, CA 95134-1706 Phone: (408) 527-0955 email: ddutt@cisco.com Elfassy, Dutt [Page 17] COPS extensions for RSVP+ support June 1999 9. 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 18]