idnits 2.17.1 draft-ietf-issll-dclass-01.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 are 93 instances of too long lines in the document, the longest one being 5 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'INTDIFF' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DS') -- Possible downref: Non-RFC (?) normative reference: ref. 'RAP' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Y. Bernet, Microsoft 2 draft-ietf-issll-dclass-01.txt October, 1999 4 Format of the RSVP DCLASS Object 6 Status of this Memo 8 This document is an Internet-Draft and is in full conformance with all 9 provisions of Section 10 of RFC2026. 11 Internet-Drafts are working documents of the Internet Engineering Task 12 Force (IETF), its areas, and its working groups. Note that other groups 13 may also distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference material 18 or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 22 Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 24 Distribution of this memo is unlimited. 26 Copyright Notice 28 Copyright (C) The Internet Society (1998). All Rights Reserved. 30 1. Abstract 32 RSVP signaling may be used to request QoS services and enhance the 33 manageability of application traffic's QoS in a differentiated service 34 (diff-serv or DS) network. When using RSVP with DS networks it is 35 useful to be able to carry carry Differentiated Services Code Points 36 (DSCPs) in RSVP message objects. One example of this is the use of RSVP 37 to arrange for the marking of packets with a particular DSCP upstream 38 from the DS network's ingress point, at the sender or at a previous 39 network's egress router. 41 The DCLASS object is used to represent and carry DSCPs within RSVP 42 messages. This draft specifies the format of the DCLASS object and 43 briefly discusses its use. 45 2. Introduction 47 This section describes the mechanics of using RSVP [RSVP] signaling and 48 the DCLASS object for effecting admission control and applying QoS 49 policy within a Differentiated Service network [DS]. It assumes 50 standard RSVP senders and receivers, and a diff-serv network somewhere 51 in the path between sender and receiver. At least one RSVP aware 52 network element resides in the diff-serv network. This network element 53 may be a policy enforcement point (PEP) [RAP] or may simply act as an 55 Bernet Expires May, 2000 1 56 admission control agent for the network, admitting or denying resource 57 requests based on the availability of resources. In either case, this 58 network element interacts with RSVP messages arriving from outside the 59 DS network, accepting resource requests from RSVP-aware senders and 60 receivers, and conveying the DS network's admission control and resource 61 allocation decisions to the higher-level RSVP. The network element is 62 typically a router and will be considered to be so for the purpose of 63 this draft. This model is described fully in [INTDIFF]. 65 2.1 Use of the DCLASS Object to Carry Upstream Packet Marking Information 67 A principal usage of the DCLASS object is to carry DSCP information 68 between a DS network and upstream nodes that may wish to mark packets 69 with DSCP values. Briefly, the sender composes a standard RSVP PATH 70 message and sends it towards the receiver. At some point the PATH 71 message reaches the DS network. The PATH message traverses one or more 72 network elements that are PEPs and/or admission control agents for the 73 diff-serv network. These elements install appropriate state and forward 74 the PATH message towards the receiver. If admission control is 75 successful downstream of the diff-serv network, then a RESV message will 76 arrive from the direction of the receiver. As this message arrives at 77 the PEPs and/or admission control agents that are RSVP enabled, each of 78 these network elements must make a decision regarding the admissibility 79 of the signaled flow to the diff-serv network. 81 If the network element determines that the request represented by the 82 PATH and RESV messages is admissible to the diff-serv network, the 83 appropriate diff-serv service level (or behaviour aggregate) for the 84 traffic represented in the RSVP request is determined. Next, a decision 85 is made to mark arriving data packets for this traffic locally using MF 86 classification, or to request upstream marking of the packets with the 87 appropriate DSCP(s). This upstream marking could occur anywhere before 88 the DS network's ingress point. Two likely candidates are the 89 originating sender and the egress boundary router of some upstream (DS 90 or non-DS) network. The decision about where the RSVP request's packets 91 should be marked can be made by agreement or through a negotiation 92 protocol; the details are outside the scope of this document. 94 If the packets for this RSVP request are to be marked upstream, 95 information about the DSCP(s) to use must be conveyed from the RSVP- 96 aware network element to the upstream marking point. This information 97 is conveyed with the DCLASS object. To do this, the network element 98 adds a DCLASS object containing one or more DSCPs corresponding to the 99 behaviour aggregate, to the RESV message. The RESV message is then sent 100 upstream towards the RSVP sender. 102 If the network element determines that the RSVP request is not 103 admissible to the diff-serv network, it sends a RESV error message 104 towards the receiver. No DCLASS is required. 106 Bernet Expires May, 2000 2 107 2.1 Additional Uses of the DCLASS Object 109 The DCLASS object is intended to be a general tool for conveying DSCP 110 information in RSVP messages. This may be useful in a number of 111 situations. We give one further example here as motivation. 113 In this example, we assume that the decision about the appropriate 114 behavior aggregate for a RSVP-mediated traffic flow is made at the DS 115 network egress router (or a related Policy Decision Point) by observing 116 RSVP PATH and RESV messages and other necessary information. However, 117 the actual packet marking must be done at the ingress of the network. 118 The DCLASS object can be used to carry the needed marking information 119 between egress and ingress routers. 121 3. Format of the DCLASS Object 123 The DCLASS object has the following format: 125 0 | 1 | 2 | 3 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Length (>= 8) | C-Num (225) | 1 | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Unused | 1st DSCP | | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Unused | 2nd DSCP | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Unused | . . . . | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 The first word contains the standard RSVP object header (the Class Num 137 for the DCLASS object is 225). The length field indicates the total 138 object length in bytes. The object header is followed by one or more 139 32-bit words, each containing a DSCP in the six high-order bits of the 140 least significant byte. The length field in the object header indicates 141 the number of DSCPs included in the object. Specifically, the number of 142 DCLASS objects present is equal to (Length - 4) / 4. 144 The network may return multiple DSCPs in the DCLASS object in order to 145 enable the host to discriminate sub-flows within a behaviour aggregate. 146 For example, in the case of the AF PHB group [AF], the network may 147 return the DSCPs 001010, 001100, and 001110 corresponding to increasing 148 levels of drop precedence within Class 1 of the AF PHB group. Note that 149 this draft makes no statements regarding the significance of the order 150 of the returned DSCPs. Further interpretation of DSCP sets is dependent 151 on the specific service requested by the host and is beyond the scope of 152 this draft. 154 Note that the Class-Num for the DCLASS object is chosen from the space 155 of unknown class objects that should be ignored and forwarded by nodes 156 that do not recognize it. This is to assure maximal backward 157 compatibility. 159 Bernet Expires May, 2000 3 160 4. Admission Control Functionality 162 From a black-box perspective, admission control and policy functionality 163 amounts to the decision whether to accept or reject a request and the 164 determination of the DSCPs that should be used for the corresponding 165 traffic. The specific details of admission control are beyond the scope 166 of this document. In general the admission control decision is based 167 both on resource availability and on policies regarding the use of 168 resources in the diff-serv network. The admission control decision made 169 by RSVP aware network elements represents both considerations. 171 In order to decide whether the RSVP request is admissible in terms of 172 resource availability, one or more network elements within or at the 173 boundary of the diff-serv network must understand the impact that 174 admission would have on specific diff-serv resources, as well as the 175 availability of these resources along the relevant data path in the 176 diff-serv network. 178 In order to decide whether the RSVP request is admissible in terms of 179 policy, the network element may use identity objects describing users 180 and/or applications that may be included in the request. The router may 181 act as a PEP/PDP and use data from a policy database or directory to aid 182 in this decision. 184 See Appendix A for a simple mechanism for configurable resource based 185 admission control. 187 5. Security Considerations 189 The DCLASS object conveys information that can be used to request 190 enhanced QoS from a DS network, so inappropriate modification of the 191 object could allow traffic flows to obtain a higher or lower level of 192 QoS than appropriate. Particularly, modification of a DCLASS object by 193 a third party inserted between the DS network ingress node and the 194 upstream marker constitutes a possible denial of service attack. This 195 attack is subtle because it is possible to reduce the received QoS to an 196 unacceptably low level without completely cutting off data flow, making 197 the attack harder to detect. 199 The possibility of raising the received level of QoS by inappropriate 200 modification of the DCLASS object is less significant because it a 201 subclass of a larger class of attacks that must already be detected by 202 the system. Protection must already be in place to prevent a host 203 raising its received level of QoS by simply guessing "good" DSCP's and 204 marking packets accordingly. If this protection is at the boundary of 205 the DS network, it will detect inappropriate marking of arriving packets 206 caused by modified DCLASS objects as well. If, however, the protection 207 function as well as the marking function has been pushed upstream 208 (perhaps to a trusted third party or intermediate node), correct 209 transmission of the DCLASS object must be ensured to prevent a possible 210 theft of service attack. 212 Bernet Expires May, 2000 4 213 Simple observation of the DCLASS object in a RSVP message raises several 214 issues which may be seen as security concerns. Correlation of observed 215 DCLASS object values with RSVP requests or MF classification parameters 216 allows the observer to determine that different flows are receiving 217 different levels of QoS, which may be knowledge that should be protected 218 in some environments. Similarly, observation of the DCLASS object can 219 allow the observer to determine that a single flow's QoS has been 220 promoted or demoted, which may signal significant events in the life of 221 that flow's application or user. Finally, observation of the DCLASS 222 object may reveal information about the internal operations of a DS 223 network that could be useful to observers interested in 224 theft-of-services attacks. 226 6. References 228 [INTDIFF], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 229 Speer, M., Braden, R., Davie, B., Wroclawski, J., "Integrated Services 230 Operation over Diffserv Networks", Internet Draft, June 1999 232 [DS] An Architecture for Differentiated Services. S. Blake, D. Black, 233 M. Carlson, E. Davies, Z. Wang, W. Weiss, RFC 2475, December 1998. 235 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 236 Functional Specification.", IETF RFC 2205, Sep. 1997. 238 [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission 239 Control", IETF , Jan., 1999. 241 [AF], Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "Assured 242 Forwarding PHB Group", RFC 2597, June 1999 244 7. Acknowledgments 246 Thanks to Fred Baker and Carol Iturralde for reviewing this draft. 247 Thanks to Ramesh Pabbati, Tim Moore, Bruce Davie and Kam Lee for input. 249 8. Author's Address 251 Bernet, Yoram 252 Microsoft 253 One Microsoft Way, 254 Redmond, WA 98052 255 Phone: (425) 936-9568 256 Email: yoramb@microsoft.com 258 Appendix A - Simple Configurable Resource Based Admission Control 260 Routers may use quite sophisticated mechanisms in making the admission 261 control decision, including policy considerations, various intra- domain 262 signaling protocols, results of traffic monitoring and so on. It is 263 recommended that the following basic functionality be provided to enable 265 Bernet Expires May, 2000 5 266 simple resource based admission control in the absence of more 267 sophisticated mechanisms. This functionality can be used with 268 configurable, standalone routers. It applies to standard RSVP/Intserv 269 requests. This minimal functionality assumes only a single DSCP is 270 included in the DCLASS object, but may readily be extended to support 271 multiple DSCPs. 273 It must be possible to configure two tables in the router. These are 274 described below. 276 A.1 Service Type to DSCP Mapping 278 One table provides a mapping from the intserv service-type specified in 279 the RSVP request to a DSCP that can be used to obtain a corresponding 280 service in the diff-serv network. This table contains a row for each 281 intserv service type for which a mapping is available. Each row has the 282 following format: 284 Intserv service type : DSCP 286 The table would typically contain at least three rows; one for 287 Guaranteed service, one for Controlled Load service and one for Best- 288 Effort service. (The best-effort service will typically map to DSCP 289 000000, but may be overridden). It should be possible to add rows for 290 as-yet-undefined service types. 292 This table allows the network administrator to statically configure a 293 DSCP that the router will return in the DCLASS object for an admitted 294 RSVP request. In general, more sophisticated and likely more dynamic 295 mechanisms may be used to determine the DSCP to be returned in the 296 DCLASS object. Also, it is likely that a real mapping for some services 297 would use more than one DSCP, with the DSCP depending on the invocation 298 parameters of a specific service request. In this case, these 299 mechanisms may override or replace the static table based mapping 300 described here. 302 A.2 Quantitative Resource Availability 304 Standard intserv requests are quantitative in nature. They include 305 token bucket parameters describing the resources required by the traffic 306 for which admission is requested. The second table enables the network 307 administrator to statically configure quantitative parameters to be used 308 by the router when making an admission control decision for quantitative 309 service requests. Each row in this table has the following form: 311 DSCP : Token bucket profile 313 The first column specifies those DSCPs for which quantitative admission 314 control is applied. The second column specifies the token bucket 315 parameters which represent the total resources available in the 316 diff-serv network to accommodate traffic in the service class specified 317 by the DSCP. 319 Bernet Expires May, 2000 6