idnits 2.17.1 draft-ietf-issll-dclass-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 3) being 69 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'INTDIFF' is defined on line 183, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'INTDIFF' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Y.Bernet, Microsoft 2 Internet Draft 3 Document: draft-ietf-issll-dclass-00.txt August, 1999 5 Usage and Format of the DCLASS Object With RSVP Signaling 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 24 Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Distribution of this memo is unlimited. 29 Copyright Notice 31 Copyright (C) The Internet Society (1998). All Rights Reserved. 33 1. Abstract 35 RSVP signaling may be used to enhance the manageability of 36 application traffic's QoS in a differentiated service (diff-serv) 37 network [intdiff]. In this model, certain network elements within or 38 at the edges of the diff-serv network may use RSVP messages to 39 effect admission control or to apply QoS policy. One mechanism by 40 which network elements may apply QoS policy is by causing a DCLASS 41 object to be returned to a sending host in an RSVP RESV message. The 42 DCLASS object indicates one or more diff-serv codepoints (DSCPs) 43 that the sender should include when submitting packets on the 44 admitted flow, to the diff-serv network. This draft describes the 45 usage and format of the DCLASS object. 47 3. Signaling Protocol 49 This section describes the mechanics of using RSVP signaling and the 50 DCLASS object for effecting admission control and applying QoS 51 policy within a diff-serv network. It assumes a standard RSVP sender 53 bernet expires February, 2000 1 54 draft-ietf-issll-dclass-00.txt August, 1999 56 and a diff-serv network somewhere in the path between sender and 57 receiver. At least one RSVP aware network element resides in the 58 diff-serv network. This network element may be a policy enforcement 59 point (PEP) associated with a PDP, or may simply act as an admission 60 control agent, admitting or denying resource requests based 61 exclusively on the availability of resources. The network element is 62 typically a router and will be considered to be so for the purpose 63 of this draft. 65 The sender composes a standard RSVP PATH message and sends it 66 towards the receiver on the remote end of the diff-serv network. The 67 PATH message traverses one or more network elements that are PEPs 68 and/or admission control agents for the diff-serv network. These 69 elements install appropriate state and forward the PATH message 70 towards the receiver. If admission control is successful downstream 71 of the diff-serv network, then a RESV message will arrive from the 72 direction of the receiver. As this message arrives at the PEPs 73 and/or admission control agents that are RSVP enabled, each of these 74 network elements must make a decision regarding the admissibility of 75 the signaled flow to the diff-serv network. 77 If the network element determines that the request represented by 78 the PATH and RESV messages is admissible to the diff-serv network, 79 it must decide which diff-serv service level (or behaviour 80 aggregate) is appropriate for the traffic represented in the RSVP 81 request. It then adds a DCLASS object containing one or more DSCPs 82 corresponding to the behaviour aggregate, to the RESV message. The 83 RESV message is then sent upstream towards the RSVP sender. 85 If the network element determines that the RSVP request is not 86 admissible to the diff-serv network, it sends a RESV error message 87 towards the receiver. No DCLASS is required. 89 Note that a network element may terminate RSVP signaling, in which 90 case it effectively provides admission control to all regions of the 91 network downstream (including the receiver). In this case, no actual 92 RESV message will arrive from the receiver. Instead, the network 93 element may act as a proxy, composing the RESV message on behalf of 94 the downstream nodes. 96 4. Format of the DCLASS Object 98 bernet expires February, 2000 2 99 draft-ietf-issll-dclass-00.txt August, 1999 101 The DCLASS object has the following format: 103 0 1 2 3 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Length (>= 8) | C-Num (225) | 1 | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Unused | 1st DSCP | | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Unused | 2nd DSCP | | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Unused | . . . . | | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 The first word contains the standard RSVP object header (the Class 124 Num for the DCLASS object is 225). The length field indicates the 125 total object length in bytes. The object header is followed by one 126 or more 32-bit words, each containing a DSCP in the six high-order 127 bits of the least significant byte. The length field in the object 128 header indicates the number of DSCPs included in the object. 130 The network may return multiple DSCPs in the DCLASS object in order 131 to enable the host to discriminate sub-flows within a behaviour 132 aggregate. For example, in the case of the AF PHB group [AF], the 133 network may return the DSCPs 001010, 001100, and 001110 134 corresponding to increasing levels of drop precedence within Class 1 135 of the AF PHB group. Note that this draft makes no statements 136 regarding the significance of the order of the returned DSCPs. 137 Further interpretation of DSCP sets is dependent on the specific 138 service requested by the host and is beyond the scope of this draft. 140 Note that the Class-Num for the DCLASS object is chosen from the 141 space of unknown class objects that should be ignored and forwarded 142 by nodes that do not recognize it. This is to assure maximal 143 backward compatibility. 145 5. Admission Control Functionality 147 From a black-box perspective, admission control and policy 148 functionality amounts to the decision whether to accept or reject a 149 request and the determination of the DSCPs that should be used for 150 the corresponding traffic. The specific details of admission control 151 are beyond the scope of this document. In general the admission 152 control decision is based both on resource availability and on 153 policies regarding the use of resources in the diff-serv network. 154 The admission control decision made by RSVP aware network elements 155 represents both considerations. 157 In order to decide whether the RSVP request is admissible in terms 158 of resource availability, one or more network elements within or at 159 the boundary of the diff-serv network must understand the impact 160 that admission would have on specific diff-serv resources, as well 162 bernet expires February, 2000 3 163 draft-ietf-issll-dclass-00.txt August, 1999 165 as the availability of these resources along the relevant data path 166 in the diff-serv network. 168 In order to decide whether the RSVP request is admissible in terms 169 of policy, the network element may use identity objects describing 170 users and/or applications that may be included in the request. The 171 router may act as a PEP/PDP and use data from a policy database or 172 directory to aid in this decision. 174 See Appendix A for a simple mechanism for configurable resource 175 based admission control. 177 8. Security Considerations 179 There are no security considerations beyond those of standard RSVP. 181 9. References 183 [INTDIFF], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 184 Speer, M., Braden, R., Davie, B., "Integrated Services Operation 185 over Diffserv Networks", Internet Draft, June 1999 187 [AF], Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "Assured 188 Forwarding PHB Group", RFC 2597, June 1999 190 10. Acknowledgments 192 Thanks to Fred Baker and Carol Iturralde for reviewing this draft. 193 Thanks to Ramesh Pabbati, Tim Moore, Bruce Davie and Kam Lee for 194 input. 196 11. Author's Addresses 198 Bernet, Yoram 199 Microsoft 200 One Microsoft Way, 201 Redmond, WA 98052 202 Phone: (425) 936-9568 203 Email: yoramb@microsoft.com 205 Appendix A - Simple Configurable Resource Based Admission Control 207 Routers may use quite sophisticated mechanisms in making the 208 admission control decision, including policy considerations, various 209 intra-domain signaling protocols, results of traffic monitoring and 210 so on. It is recommended that the following basic functionality be 211 provided to enable simple resource based admission control in the 212 absence of more sophisticated mechanisms. This functionality can be 213 used with configurable, standalone routers. It applies to standard 214 RSVP/Intserv requests. This minimal functionality assumes only a 215 single DSCP is included in the DCLASS object, but may readily be 216 extended to support multiple DSCPs. 218 bernet expires February, 2000 4 219 draft-ietf-issll-dclass-00.txt August, 1999 221 It must be possible to configure two tables in the router. These are 222 described below. 224 A.1 Service Type to DSCP Mapping 226 One table provides a mapping from the intserv service-type specified 227 in the RSVP request to a DSCP that can be used to obtain a 228 corresponding service in the diff-serv network. This table contains 229 a row for each intserv service type for which a mapping is 230 available. Each row has the following format: 232 Intserv service type : DSCP 234 The table would typically contain at least three rows; one for 235 Guaranteed service, one for Controlled Load service and one for 236 Best-Effort service. (The best-effort service will typically map to 237 DSCP 000000, but may be overridden). It should be possible to add 238 rows for as-yet-undefined service types. 240 This table allows the network administrator to statically configure 241 a DSCP that the router will return in the DCLASS object for an 242 admitted RSVP request. In general, more sophisticated and likely 243 more dynamic mechanisms may be used to determine the DSCP to be 244 returned in the DCLASS object. In this case, these mechanisms may 245 override the static table based mapping. 247 A.2 Quantitative Resource Availability 249 Standard intserv requests are quantitative in nature. They include 250 token bucket parameters describing the resources required by the 251 traffic for which admission is requested. The second table enables 252 the network administrator to statically configure quantitative 253 parameters to be used by the router when making an admission control 254 decision for quantitative service requests. Each row in this table 255 has the following form: 257 DSCP : Token bucket profile 259 The first column specifies those DSCPs for which quantitative 260 admission control is applied. The second column specifies the token 261 bucket parameters which represent the total resources available in 262 the diff-serv network to accommodate traffic in the service class 263 specified by the DSCP. 265 bernet expires February, 2000 5