idnits 2.17.1 draft-ietf-rap-signaled-priority-01.txt: -(218): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(366): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(414): 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-26) 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 9 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 2 longer pages, the longest (page 10) being 60 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 23 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: ---------------------------------------------------------------------------- == Line 240 has weird spacing: '...emption eleme...' -- 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 (January 22, 1999) is 9226 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) == Missing Reference: 'COSP' is mentioned on line 132, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-rap-rsvp-ext-02 == Outdated reference: A later version (-05) exists of draft-ietf-rap-cops-rsvp-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'RAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Shai Herzog 3 Expiration: July 1999 IPHighway 4 File: draft-ietf-rap-signaled-priority-01.txt 6 Signaled Preemption Priority Policy Element 8 January 22, 1999 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 signaled 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.Stateless Policy.....................................................4 52 4.Policy Element Format................................................4 53 5.Priority Merging Issues..............................................6 54 5.1.Priority Merging Strategies........................................7 55 5.1.1.Take priority of highest QoS.....................................7 56 5.1.2.Take highest priority............................................7 57 5.1.3.Force error on heterogeneous merge...............................8 58 5.2.Modifying Priority Elements........................................8 59 6.Error Processing.....................................................9 60 7.Security Considerations..............................................9 61 8.References..........................................................10 62 9.Author Information..................................................10 63 A.Appendix: Example...................................................11 64 A.1.Computing Merged Priority.........................................11 65 A.2.Translation (Compression) of Priority Elements....................11 66 1. Introduction 68 Traditional Capacity based Admission Control (CAC) indiscriminately 69 admits new flows until capacity is exhausted (First Come First 70 Admitted). Policy based Admission Control (PAC) on the other hand 71 attempts to minimize the significance of order of arrival and use 72 policy based admission criteria instead. 74 One of the more popular policy criteria is the rank of importance of a 75 flow relative to the others competing for admission into a network 76 node. Preemption Priority takes effect only when a set of flows 77 attempting admission through a node represents overbooking of resources 78 such that based on CAC some would have to be rejected. Preemption 79 priority criteria help the node select the most important flows 80 (highest priority) for admission, while rejecting the low priority 81 ones. 83 Network nodes which support preemption should consider priorities to 84 preempt some previously admitted low-priority flows in order to make 85 room for a newer, high-priority flow. 87 This document describes the format and applicability of the preemption 88 priority represented as a policy element in [RSVP-EXT]. 90 2. Scope and Applicability 92 The Framework document for policy-based admission control [RAP] 93 describes the various components that participate in policy decision 94 making (i.e., PDP, PEP and LPD). The emphasis of PREEMPTION_PRI 95 elements is to be simple, stateless, and light-weight such that they 96 could be implemented internally within a node�s LDP (Local Decision 97 Point). 99 Certain base assumptions are made in the usage model for PREEMPTION_PRI 100 elements: 102 - They are created by PDPs 104 In a model where PDPs control PEPs at the periphery of the policy 105 domain (e.g., in border routers), PDPs reduce sets of relevant 106 policy rules into a single priority criterion. This priority as 107 expressed in the PREEMPTION_PRI element can then be communicated to 108 downstream PEPs of the same policy domain, which have LPDs but no 109 controlling PDP. 111 - They can be processed by LDPs 113 PREEMPTION_PRI elements are processed by LDPs of nodes that do not 114 have a controlling PDP. LDPs may interpret these objects, forward 115 them as is, or perform local merging to forward an equivalent merged 116 PREEMPTION_PRI policy element. LDPs must follow the merging strategy 117 that was encoded by PDPs in the PREEMPTION_PRI objects. (Clearly, a 118 PDP, being a superset of LDP, may act as an LDP as well). 120 - They are enforced by PEPs 122 PREEMPTION_PRI elements interact with a node�s traffic control 123 module (and capacity admission control) to enforce priorities, and 124 preempt previously admitted flows when the need arises. 126 3. Stateless Policy 128 Signaled Preemption Priority is stateless (does not require past 129 history or external information to be interpreted). Therefore, when 130 carried in COPS messages for the outsourcing of policy decisions, these 131 objects are included as COPS Stateless Policy Data Decision objects 132 (see [COSP, COPS-RSVP]). 134 4. Policy Element Format 136 The format of Policy Data objects is defined in [RSVP-EXT]. A single 137 Policy Data object may contain one or more policy elements, each 138 representing a different (and perhaps orthogonal) policy. 140 The format of preemption priority policy element is as follows: 142 +-------------+-------------+-------------+-------------+ 143 | Length (12) | P-Type = PREEMPTION_PRI | 144 +------+------+-------------+-------------+-------------+ 145 | Flags | M. Strategy | Error Code | Reserved(0) | 146 +------+------+-------------+-------------+-------------+ 147 | Preemption Priority | Defending Priority | 148 +------+------+-------------+-------------+-------------+ 150 Length: 16 bits 152 Always 12. The overall length of the policy element, in bytes. 154 P-Type: 16 bits 156 PREEMPTION_PRI = 1 157 The preemption priority policy element number was assigned by IANA 158 as defined in [RSVP-EXT]. 160 Flags: 8 bits 162 Reserved (always 0). 164 Merge Strategy: 8 bit 166 1 Take priority of highest QoS: recommended 167 2 Take highest priority: aggressive 168 3 Force Error on heterogeneous merge 170 Reserved: 8 bits 172 Error code: 8 bits 174 0 NO_ERROR Value used for regular PREEMPTION_PRI elements 175 1 PREEMPTION This previously admitted flow was preempted 176 2 HETEROGENEOUS This element encountered heterogeneous merge 178 Reserved: 8 bits 180 Always 0. 182 Preemption Priority: 16 bit (unsigned) 184 The priority of the new flow compared with the defending priority of 185 previously admitted flows. Higher values represent higher Priority. 187 Defending Priority: 16 bits (unsigned) 189 Once a flow was admitted, the preemption priority becomes 190 irrelevant. Instead, its defending priority is used to compare with 191 the preemption priority of new flows. 193 For any specific flow, its preemption priority must always be less 194 than or equal to the defending priority. A wide gap between 195 preemption and defending priority provides added stability: moderate 196 preemption priority makes it harder for a flow to preempt others, 197 but once it succeeded, the higher defending priority makes it easier 198 for the flow to avoid preemption itself. This provides a mechanism 199 for balancing between order dependency and priority. 201 5. Priority Merging Issues 203 Consider the case where two RSVP reservations merge: 205 F1: QoS=High, Priority=Low 206 F2: QoS=Low, Priority=High 208 F1+F2= F3: QoS=High, Priority=??? 210 The merged reservation F3 should have QoS=Hi, but what Priority should 211 it assume? Several negative side-effects have been identified that may 212 affect such a merger: 214 Free-Riders: 216 If F3 assumes Priority=High, then F1 got a free ride, assuming high 217 priority that was only intended to the low QoS F2. If one associates 218 costs as a function of QoS and priority, F1 receives an �expensive� 219 priority without having to �pay� for it. 221 Denial of Service: 223 If F3 assumes Priority=Low, the merged flow could be preempted or fail 224 even though F2 presented high priority. 226 Denial of service is virtually the inverse of the free-rider problem. 227 When flows compete for resources, if one flow receives undeserving high 228 priority it may be able to preempt another deserving flow (hence one 229 free-rider turns out to be another�s denial of service). 231 Instability: 233 The combination of preemption priority, killer reservation and blockade 234 state [RSVP] may increase the instability of admitted flows where a 235 reservation may be preempted, reinstated, and preempted again 236 periodically. 238 5.1. Priority Merging Strategies 240 In merging situations LDPs may receive multiple preemption elements 241 and must compute the priority of the merged flow according to the 242 following rules: 244 a. Preemption priority and defending priority are merged and computed 245 separately, irrespective of each other. 247 b. Participating priority elements are selected. 249 All priority elements are examined according to their merging 250 strategy to decide whether they should participate in the merged 251 result (as specified bellow). 253 c. The highest priority of all participating priority elements is 254 computed. 256 The remainder of this section describes the different merging 257 strategies the can be specified in the PREEMPTION_PRI element. 259 5.1.1. Take priority of highest QoS 261 The PREEMPTION_PRI element would participate in the merged reservation 262 only if it belongs to a flow that contributed to the merged QoS level 263 (i.e., that its QoS requirement does not constitute a subset another 264 reservation.) 265 A simple way to determine whether a flow contributed to the merged QoS 266 result is to compute the merged QoS with and without it and to compare 267 the results (although this is clearly not the most efficient method). 269 The reasoning for this approach is that the highest QoS flow is the one 270 dominating the merged reservation and as such its priority should 271 dominate it as well. This approach is the most amiable to the 272 prevention of priority distortions such as free-riders and denial of 273 service. 275 This is a recommended merging strategy. 277 5.1.2. Take highest priority 279 All PREEMPTION_PRI elements participate in the merged reservation. 281 This strategy disassociates priority and QoS level, and therefore is 282 highly subject to free-riders and its inverse image, denial of service. 284 This is not a recommended method, but may be simpler to implement. 286 5.1.3. Force error on heterogeneous merge 288 A PREEMPTION_PRI element may participate in a merged reservation only 289 if all other flows in the merged reservation have the same QoS level 290 (heterogeneous flows). 292 The reasoning for this approach assumes that the heterogeneous case is 293 relatively rare and too complicated to deal with, thus it better be 294 prohibited. 296 This strategy lends itself to denial of service, when a single receiver 297 specifying a non-compatible QoS level may cause denial of service for 298 all other receivers of the merged reservation. 300 Note: The determination of heterogeneous flows applies to QoS level 301 only (FLOWSPEC values), and is a matter for local (LDP) definition. 302 Other types of heterogeneous reservations (e.g. conflicting reservation 303 styles) are handled by RSVP and are unrelated to this PREEMPTION_PRI 304 element. 306 5.2. Modifying Priority Elements 308 When POLICY_DATA objects are protected by integrity, LDPs should not 309 attempt to modify them. They must be forwarded as-is or else their 310 security envelope would be invalidated. In other cases, LDPs may modify 311 and merge incoming PREEMPTION_PRI elements to reduce their size and 312 number according to the following rule: 314 - Merging is performed for each merging strategy separately. 316 There is no known algorithm to merge PREEMPTION_PRI element of 317 different merging strategies without loosing valuable information 318 that may affect OTHER nodes. 320 - For each merging strategy, the highest QoS of all participating 321 PREEMPTION_PRI elements is taken and is placed in an outgoing 322 PREEMPTION_PRI element of this merging strategy. 324 This approach effectively compresses the number of forwarded 325 PREEMPTION_PRI elements to at most to the number of different merging 326 strategies, regardless of the number of receivers (See the example in 327 Appendix A.2). 329 6. Error Processing 331 A PREEMPTION_PRI error object is sent back toward the appropriate 332 receivers when an error involving PREEMPTION_PRI elements occur. 334 PREEMPTION 336 When a previously admitted flow is preempted, a copy of the preempting 337 flow�s PREEMPTION_PRI element is sent back toward the PDP that 338 originated the preempted PREEMPTION_PRI object. This PDP, having 339 information on both the preempting and the preempted priorities may 340 construct a higher priority PREEMPTION_PRI element in an effort to re- 341 instate the preempted flow. 343 Heterogeneity 345 When a flow F1 with Heterogeneous Error merging strategy set in its 346 PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI 347 element is sent back toward receivers with the Heterogeneity error code 348 set. 350 7. Security Considerations 352 The integrity of PREEMPTION_PRI is guaranteed, as any other policy 353 element, by the encapsulation into a Policy Data object [RSVP-EXT]. 355 Further security mechanisms are not warranted, especially considering 356 that preemption priority aims to provide simple and quick guidance to 357 routers within a trusted zone or at least a single zone (no zone 358 boundaries are crossed). 360 8. References 362 [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", Internet- 363 Draft, draft-ietf-rap-rsvp-ext-02.txt, Jan. 1999. 365 [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 366 Sastry, A., �COPS usage for RSVP� Internet-Draft, draft-ietf- 367 rap-cops-rsvp-02.txt, Jan 1999. 369 [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission 370 Control",IETF , Jan., 1999. 372 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 373 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 374 IETF , Jan. 1999. 376 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 377 Functional Specification.", IETF RFC 2205, Proposed Standard, 378 Sep. 1997. 380 9. Author Information 382 Shai Herzog, IPHighway 383 Parker Plaza, Suite 1500 384 400 Kelby St. 385 Fort-Lee, NJ 07024 386 (201) 585-0800 387 herzog@iphighway.com 389 A. Appendix: Example 391 The following examples describe the computation of merged priority 392 elements as well as the translation (compression) of PREEMPTION_PRI 393 elements. 395 A.1. Computing Merged Priority 397 r1 398 / QoS=Hi (Pr=3, St=Highest QoS) 399 / 400 s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP) 401 \ \ 402 \ \ QoS=Low (Pr=7, St=Highest QoS) 403 r4 r3 405 QoS=Low (Pr=9, St=Error) 407 Example 1: Merging preemption priority elements 409 Example one describes a multicast scenario with one sender and four 410 receivers each with each own PREEMPTION_PRI element definition. 412 r1, r2 and r3 merge in B. The resulting priority is 4. 414 Reason: The PREEMPTION_PRI of r3 doesn�t participate (since r3 is not 415 contributing to the merged QoS) and the priority is the highest of the 416 PREEMPTION_PRI from r1 and r2. 418 r1, r2, r3 and r4 merge in A. The resulting priority is again 4: r4 419 doesn�t participate because its own QoS=Low is incompatible with the 420 other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to r4 421 telling it that its PREEMPTION_PRI element encountered heterogeneity. 423 A.2. Translation (Compression) of Priority Elements 425 Given this set of participating PREEMPTION_PRI elements, the following 426 compression can take place at the merging node: 428 From: 429 (Pr=3, St=Highest QoS) 430 (Pr=7, St=Highest QoS) 431 (Pr=4, St=Highest PP) 432 (Pr=9, St=Highest PP) 433 (Pr=6, St=Highest PP) 434 To: 435 (Pr=7, St=Highest QoS) 436 (Pr=9, St=Highest PP)