idnits 2.17.1 draft-ietf-rap-signaled-priority-00.txt: -(207): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(218): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(349): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 10 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines 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 29 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RSVP], [COPS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (November 18, 1998) is 9290 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Unexpected draft version: The latest known version of draft-ietf-rsvp-spec is -15, but you're referring to -16. -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS' == Outdated reference: A later version (-06) exists of draft-ietf-rap-rsvp-ext-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'Fwk' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Shai Herzog 3 Expiration: Apr. 1999 IPHighway 4 File: draft-ietf-rap-signaled-priority-00.txt 6 Preemption Priority Policy Element 8 November 18, 1998 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, and 14 its Working Groups. Note that other groups may also distribute working 15 documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six months. 18 Internet Drafts may be updated, replaced, or obsoleted by other 19 documents at any time. It is not appropriate to use Internet Drafts as 20 reference material or to cite them other than as a "working draft" or 21 "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or 26 munnari.oz.au. 28 A revised version of this draft document will be submitted to the RFC 29 editor as a Proposed Standard for the Internet Community. Discussion 30 and suggestions for improvement are requested. This document will 31 expire at the expiration date listed above. Distribution of this draft 32 is unlimited. 34 Abstract 36 This document describes a preemption priority policy element for use by 37 policy based admission protocols (such as [RSVP] and [COPS]). 39 Preemption priority defines a relative importance (rank) within the set 40 of flows competing to be admitted into the network. Rather than 41 admitting flows by order of arrival (First Come First Admitted) network 42 nodes may consider priorities to preempt some previously admitted low 43 priority flows in order to make room for a newer, high-priority flow. 45 Table of Contents 47 Abstract...............................................................1 48 Table of Contents......................................................2 49 1.Introduction.........................................................3 50 2.Scope and Applicability..............................................3 51 3.Policy Element Format:...............................................4 52 4.Priority Merging Issues..............................................5 53 5.Priority Merging Strategies..........................................6 54 5.1.Take priority of highest QoS.......................................6 55 5.2.Take highest priority..............................................7 56 5.3.Force error on heterogeneous merge.................................7 57 6.Error Processing.....................................................7 58 7.Security Considerations..............................................8 59 8.Example..............................................................8 60 8.1.Computing Merged Priority..........................................8 61 8.2.Translation (Compression) of Priority Elements.....................9 62 9.References...........................................................9 63 10. Author Information.................................................9 64 1. Introduction 66 Traditional Capacity based Admission Control (CAC) indiscriminately 67 flows until capacity is exhausted. Policy based Admission Control (PAC) 68 on the other hand attempts to minimize the significance of order of 69 arrival and use policy based criteria instead. 71 One of the more popular policy criteria is the rank of importance of a 72 flow relative to the others competing for admition into/through a 73 network node. Preemption Priority takes effect only when a set of flows 74 attempting admission through a node represents overbooking of resources 75 such that based on CAC some would have to be rejected. Preemption 76 priority criteria help the node select the most important flows 77 (highest priority) for admission, while rejecting the low priority 78 ones. 80 Network nodes which support preemption should consider priorities to 81 preempt some previously admitted low priority flows in order to make 82 room for a newer, high-priority flow. 84 This document describe the format and applicability of the Preemption 85 Priority represented as a policy element in [RSVP-EXT]. 87 2. Scope and Applicability 89 The Framework document for Policy-based Admission Control [Fwk] 90 describes the various components that participate in policy decision 91 making (i.e., PDP, PEP and LPD). The emphasis of PREEMPTION_PRI 92 elements is to be simple and get processed quick enough such that they 93 could be implemented internally within a node�s LDP (Local Decision 94 Point). 96 Certain base assumptions are made in the usage model for PREEMPTION_PRI 97 elements: 99 - They are created by PDPs 101 In a model where PDPs control the periphery (boarder routers), PDPs 102 reduce their entire set of relevant policy rules into a single 103 priority criteria. This priority as expressed in the PREEMPTION_PRI 104 element can then be communicated to in-cloud core nodes, which have 105 LPDs but no controlling PDP. 107 - They are processed by LDPs 109 PREEMPTION_PRI elements are interpreted and are forwarded locally 110 within in-cloud core nodes (in their LDP modules). Policy ignorant 111 nodes (PINs) may interpret these objects, and forward them as is, or 112 they can perform local merging and forward an equivalent merged 113 PREEPMTION_PRI policy element. In both cases, whether for 114 interpretation only or for merging, LDPs must follow the merging 115 strategy as specified in the policy element itself. 117 - They are enforced by PEPs 119 PREEMPTION_PRI elements interact with a node�s traffic control 120 module (and capacity admission control) to enforce priorities, and 121 to perform preemption of previously admitted flows if the need 122 arises. 124 3. Policy Element Format: 126 The format of Policy Data objects is defined in [RSVP-EXT]. A single 127 Policy Data object may contain one or more policy elements, each 128 representing a different (and perhaps orthogonal) policy. 129 The format of Preemption Priority policy element is as follows: 131 +-------------+-------------+-------------+-------------+ 132 | Length (12) | P-Type = PREEMPTION_PRI | 133 +------+------+-------------+-------------+-------------+ 134 | Flags | M. Strategy | Error Code | Reserved(0) | 135 +------+------+-------------+-------------+-------------+ 136 | Preemption Priority | Defending Priority | 137 +------+------+-------------+-------------+-------------+ 139 Length: 16 bits 141 Always 12. The overall length of the policy element, in bytes. 143 P-Type: 16 bits 145 PREEMPTION_PRI Preemption Priority policy element, as registered 146 with IANA. 148 Flags: 8 bits 150 Reserved (always 0). 152 Merge Strategy: 8 bit 154 1 Take priority of highest QoS: recommended 155 2 Take highest priority: aggressive 156 3 Error (fail) on heterogeneous merge 158 Reserved: 8 bits 160 Error code: 8 bits 161 0 No error. Value used for all regular PP elements. 162 1 Preemption This previously admitted flow was preempted 163 2 Heterogeneous This PP element encountered heterogeneous merge 165 Reserved: 8 bits 167 Always 0. 169 Preemption Priority: 16 bit (0..2^16) 171 The priority of the new flow compared with the defending priority of 172 previously admitted flows. Higher values represent higher Priority. 174 Defending Priority: 16 bits 176 Once a flow was admitted, the preemption priority becomes 177 irrelevant. Instead, its defending priority is used to compare with 178 the preemption priority of new flows. 180 For any specific flow, its preemption priority must always be less 181 or equal to the defending priority. A wide gap between preemption 182 and defending priority provides leeway for added stability: moderate 183 preemption priority makes it harder for a flow to preempt others, 184 but once it succeeded, the higher defending priority makes it easier 185 for the flow to escape preemption itself. This mechanism provides 186 some order dependency, although it is not absolute, as is the case 187 for CAC. 189 4. Priority Merging Issues 191 Consider the case where two reservations merge: 193 F1: QoS=High, Priority=Low 194 F2: QoS=Low, Priority=High 196 F1+F2= F3: QoS=High, Priority=??? 198 Quite clearly, the merged reservation F3 should have QoS=Hi, but what 199 Priority should it assume? Several negative side-effects have been 200 identified that can affect such a merger: 202 Free-Riders: 204 If F3 assumes Priority=High, the result is that F1 managed to get a 205 free ride for his high QoS, assuming high priority that was only 206 intended to the low QoS F2. If one associates costs as a function of 207 QoS and priority, F1 receives an �expensive� priority without having to 208 �pay� for it. 210 Denial of Service: 212 If F3 assumes Priority=Low, the merged flow could be preempted or fail 213 even though F2 presented high priority. 215 Denial of service is also a mirror image of the free-rider problem; 216 given competition for resources among the flows, if one flow receives 217 undeserving high priority it should be able to preempt another 218 deserving flow (hence one free-rider turns out to be another�s denial 219 of service). 221 Instability: 223 The combination of preemption priority, killer reservation and blockade 224 state [RSVP] may increase the instability of admitted flows where a 225 reservation may be preempted, reinstated, and preempted again 226 periodically. 228 5. Priority Merging Strategies 230 In merging situations LDPs receive multiple preemption elements for a 231 merged flow and must compute the priority of the merged flow according 232 to the following rules: 234 a. Preemption priority and defending priority are computed separately, 235 irrespective of each other. 237 b. All priority elements are examined according to their merging 238 strategy to decide whether they should participate in the merged 239 result (as specified bellow). 241 c. Take the highest priority of all those who participate. 243 d. A node may wish to reduce the number of PP elements it forwards by 244 translating multiple PP elements into their equivalent one. In this 245 case, it can only combine participating PP elements of the same 246 merging strategy into one (by taking the highest priority amongst 247 them). This effectively compress the number of forwarded PP elements 248 at most to the number of different merging strategies, regardless of 249 the number of receivers (See the example in Section 8.2). 251 The remainder of this section describes the different merging 252 strategies the can be specified in the PREEMTION_PRI element. 254 5.1. Take priority of highest QoS 256 The PP element would participate in the merged reservation only if it 257 belongs to a flow that contributed to the merged QoS level (i.e., that 258 its QoS requirement does not constitute a subset another reservation.) 259 A simple way to determine whether a flow contributed to the merged QoS 260 result is to compute the merged QoS with and without it and to compare 261 the results (although this is clearly not the most efficient method). 263 The thinking behind this approach is that the highest QoS flow is the 264 one dominating the merged reservation and as such, its priority should 265 dominate it as well. This approach is the most amiable to the 266 prevention of priority distortions such as free-riders and denial of 267 service. 269 This is a recommended merging strategy. 271 5.2. Take highest priority 273 All PP elements participate in the merged reservation. 275 This strategy allows all receivers to participate and contribute to the 276 preemption priority even if they don�t contribute to the merged 277 reservation. It is therefor highly subject to free-riders and its 278 mirror image, denial of service. 280 This is not a recommended method, but may be simpler to implement. 282 5.3. Force error on heterogeneous merge 284 A PP element with this strategy cannot participate in a merged 285 reservation if any other flow in the merged reservation has a QoS level 286 that is substantially different from its own. The determination of what 287 is �substantially different� QoS level is up to the local node. 289 The thinking behind this approach is that most cases encounter 290 homogenous receivers that use similar QoS levels. Furthermore, it 291 assumes the use of PREEMPTION_PRI in the heterogeneous case is too 292 complicated to deal with and should not be permitted. 294 This strategy lends itself to denial of service, when a single receiver 295 specifying a non-compatible QoS level may cause denial for all other 296 receivers of the merged reservation. 298 6. Error Processing 300 A PREEMPTION_PRI error object is sent back toward the appropriate 301 receivers when an error involving PP elements occur. 303 Preemption 305 When a previously admitted flow is preempted, a copy of the PREEMPTING 306 flow�s PP element is sent downstream to the receiver (with the 307 preemption error set). This allows receivers (or PDPs) to construct a 308 higher priority PP element that may cause the flow to be re-instated. 310 Heterogeneity 311 When a flow F1 with Heterogeneous Error merging strategy set in its PP 312 element encounters heterogeneity the PP element is sent back toward 313 receivers with the appropriate error code set. 315 7. Security Considerations 317 The integrity of PREEMPTION_PRI is guaranteed, as any other policy 318 element, by the encapsulation into a Policy Data object [RSVP-EXT]. 320 Further security mechanism are not warranted, especially considering 321 that preemption priority aims to provide simple and quick guidance to 322 routers within a trusted zone or at least single zone (no zone 323 boundaries are crossed). 325 8. Example 327 The following examples describe the computation of merged priority 328 elements as well as the translation (compression) of PP elements. 330 8.1. Computing Merged Priority 332 r1 333 / QoS=Hi (Pr=3, St=Highest QoS) 334 / 335 s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP) 336 \ \ 337 \ \ QoS=Low (Pr=7, St=Highest QoS) 338 r4 r3 340 QoS=Low (Pr=9, St=Error) 342 Example 1: merging Preemption Priority elements 344 Example one describes a multicast scenario with one sender and four 345 receivers each with each own PP element definition. 347 r1, r2 and r3 merge in B. The resulting priority is 4. 349 Reason: The PP of r3 doesn�t participate (since r3 is not contributing 350 to the merged QoS) and the priority is the highest of the PP from r1 351 and r2. 353 r1, r2, r3 and r4 merge in A. The resulting priority is again 4: r4 354 doesn�t participate because its own QoS=Low is incompatible with the 355 other (r1) QoS=High. An error PP should be sent back to r4 telling it 356 that its PP element encountered heterogeneity. 358 8.2. Translation (Compression) of Priority Elements 360 Given this set of participating PP elements, the following compression 361 can take place at the merging node: 363 From: 364 (Pr=3, St=Highest QoS) 365 (Pr=7, St=Highest QoS) 366 (Pr=4, St=Highest PP) 367 (Pr=9, St=Highest PP) 368 (Pr=6, St=Highest PP) 369 To: 370 (Pr=7, St=Highest QoS) 371 (Pr=9, St=Highest PP) 373 9. References 375 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 376 Functional Specification." Internet-Draft, draft-ietf-rsvp- 377 spec-16.txt, June 1997. 379 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 380 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 381 Internet-Draft , Aug. 1998. 383 [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", Internet- 384 Draft, draft-ietf-rap-rsvp-ext-00.txt, Apr. 1998. 386 [Fwk] R. Yavatkar, D. Pendarakis, R. Guerin. "A Framework for Policy 387 Based Admission Control", Internet-Draft , November, 1997. 390 10. Author Information 392 Shai Herzog, IPHighway 393 Parker Plaza, Suite 1500 394 400 Kelby St. 395 Fort-Lee, NJ 07024 396 (201) 585-0800 397 herzog@iphighway.com