idnits 2.17.1 draft-ietf-rap-signaled-priority-04.txt: 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: ---------------------------------------------------------------------------- == 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 4) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8 Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7 IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 149 instances of too long lines in the document, the longest one being 7 characters 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 (September 24, 1999) is 8953 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 section? 'RSVP' on line 384 looks like a reference -- Missing reference section? 'COPS' on line 380 looks like a reference -- Missing reference section? 'RSVP-EXT' on line 370 looks like a reference -- Missing reference section? 'RAP' on line 377 looks like a reference -- Missing reference section? 'COSP' on line 128 looks like a reference -- Missing reference section? 'COPS-RSVP' on line 373 looks like a reference -- Missing reference section? 'IANA-CONSIDERATIONS' on line 388 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Shai Herzog 2 Expiration: March 2000 IPHighway 3 File: draft-ietf-rap-signaled-priority-04.txt 5 Signaled Preemption Priority Policy Element 7 September 24, 1999 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes a preemption priority policy element for use by 32 signaled policy based admission protocols (such as [RSVP] and [COPS]). 34 Preemption priority defines a relative importance (rank) within the set 35 of flows competing to be admitted into the network. Rather than 36 admitting flows by order of arrival (First Come First Admitted) network 37 nodes may consider priorities to preempt some previously admitted low 38 priority flows in order to make room for a newer, high-priority flow. 40 Table of Contents 42 Abstract..............................................................1 43 Table of Contents.....................................................2 44 1 Introduction .......................................................3 45 2 Scope and Applicability ............................................3 46 3 Stateless Policy ...................................................4 47 4 Policy Element Format ..............................................4 48 5 Priority Merging Issues ............................................6 49 5.1 Priority Merging Strategies .....................................7 50 5.1.1 Take priority of highest QoS ...................................7 51 5.1.2 Take highest priority ..........................................8 52 5.1.3 Force error on heterogeneous merge .............................8 53 5.2 Modifying Priority Elements .....................................9 54 6 Error Processing ...................................................9 55 7 IANA Considerations ...............................................10 56 8 Security Considerations ...........................................10 57 9 References ........................................................11 58 10 Author Information ..............................................11 59 Appendix A: Example .................................................12 60 A.1 Computing Merged Priority ......................................12 61 A.2 Translation (Compression) of Priority Elements .................13 62 1 Introduction 64 Traditional Capacity based Admission Control (CAC) indiscriminately 65 admits new flows until capacity is exhausted (First Come First 66 Admitted). Policy based Admission Control (PAC) on the other hand 67 attempts to minimize the significance of order of arrival and use 68 policy based admission criteria instead. 70 One of the more popular policy criteria is the rank of importance of a 71 flow relative to the others competing for admission into a network 72 node. Preemption Priority takes effect only when a set of flows 73 attempting admission through a node represents overbooking of resources 74 such that based on CAC some would have to be rejected. Preemption 75 priority criteria help the node select the most important flows 76 (highest priority) for admission, while rejecting the low priority 77 ones. 79 Network nodes which support preemption should consider priorities to 80 preempt some previously admitted low-priority flows in order to make 81 room for a newer, high-priority flow. 83 This document describes the format and applicability of the preemption 84 priority represented as a policy element in [RSVP-EXT]. 86 2 Scope and Applicability 88 The Framework document for policy-based admission control [RAP] 89 describes the various components that participate in policy decision 90 making (i.e., PDP, PEP and LDP). The emphasis of PREEMPTION_PRI 91 elements is to be simple, stateless, and light-weight such that they 92 could be implemented internally within a node's LDP (Local Decision 93 Point). 95 Certain base assumptions are made in the usage model for PREEMPTION_PRI 96 elements: 98 - They are created by PDPs 100 In a model where PDPs control PEPs at the periphery of the policy 101 domain (e.g., in border routers), PDPs reduce sets of relevant policy 102 rules into a single priority criterion. This priority as expressed in 103 the PREEMPTION_PRI element can then be communicated to downstream 104 PEPs of the same policy domain, which have LDPs but no controlling 105 PDP. 107 - They can be processed by LDPs 109 PREEMPTION_PRI elements are processed by LDPs of nodes that do not 110 have a controlling PDP. LDPs may interpret these objects, forward 111 them as is, or perform local merging to forward an equivalent merged 112 PREEMPTION_PRI policy element. LDPs must follow the merging strategy 113 that was encoded by PDPs in the PREEMPTION_PRI objects. (Clearly, a 114 PDP, being a superset of LDP, may act as an LDP as well). 116 - They are enforced by PEPs 118 PREEMPTION_PRI elements interact with a node's traffic control module 119 (and capacity admission control) to enforce priorities, and preempt 120 previously admitted flows when the need arises. 122 3 Stateless Policy 124 Signaled Preemption Priority is stateless (does not require past 125 history or external information to be interpreted). Therefore, when 126 carried in COPS messages for the outsourcing of policy decisions, these 127 objects are included as COPS Stateless Policy Data Decision objects 128 (see [COSP, COPS-RSVP]). 130 4 Policy Element Format 132 The format of Policy Data objects is defined in [RSVP-EXT]. A single 133 Policy Data object may contain one or more policy elements, each 134 representing a different (and perhaps orthogonal) policy. 136 The format of preemption priority policy element is as follows: 138 +-------------+-------------+-------------+-------------+ 139 | Length (12) | P-Type = PREEMPTION_PRI | 140 +------+------+-------------+-------------+-------------+ 141 | Flags | M. Strategy | Error Code | Reserved(0) | 142 +------+------+-------------+-------------+-------------+ 143 | Preemption Priority | Defending Priority | 144 +------+------+-------------+-------------+-------------+ 146 Length: 16 bits 148 Always 12. The overall length of the policy element, in bytes. 150 P-Type: 16 bits 152 PREEMPTION_PRI = 3 154 This value is registered with IANA, see Section 7. 156 Flags: 8 bits 158 Reserved (always 0). 160 Merge Strategy: 8 bit 162 1 Take priority of highest QoS: recommended 163 2 Take highest priority: aggressive 164 3 Force Error on heterogeneous merge 166 Reserved: 8 bits 168 Error code: 8 bits 170 0 NO_ERROR Value used for regular PREEMPTION_PRI elements 171 1 PREEMPTION This previously admitted flow was preempted 172 2 HETEROGENEOUS This element encountered heterogeneous merge 174 Reserved: 8 bits 176 Always 0. 178 Preemption Priority: 16 bit (unsigned) 180 The priority of the new flow compared with the defending priority of 181 previously admitted flows. Higher values represent higher Priority. 183 Defending Priority: 16 bits (unsigned) 185 Once a flow was admitted, the preemption priority becomes irrelevant. 186 Instead, its defending priority is used to compare with the 187 preemption priority of new flows. 189 For any specific flow, its preemption priority must always be less 190 than or equal to the defending priority. A wide gap between 191 preemption and defending priority provides added stability: moderate 192 preemption priority makes it harder for a flow to preempt others, but 193 once it succeeded, the higher defending priority makes it easier for 194 the flow to avoid preemption itself. This provides a mechanism for 195 balancing between order dependency and priority. 197 5 Priority Merging Issues 199 Consider the case where two RSVP reservations merge: 201 F1: QoS=High, Priority=Low 202 F2: QoS=Low, Priority=High 204 F1+F2= F3: QoS=High, Priority=??? 206 The merged reservation F3 should have QoS=Hi, but what Priority should 207 it assume? Several negative side-effects have been identified that may 208 affect such a merger: 210 Free-Riders: 212 If F3 assumes Priority=High, then F1 got a free ride, assuming high 213 priority that was only intended to the low QoS F2. If one associates 214 costs as a function of QoS and priority, F1 receives an "expensive" 215 priority without having to "pay" for it. 217 Denial of Service: 219 If F3 assumes Priority=Low, the merged flow could be preempted or fail 220 even though F2 presented high priority. 222 Denial of service is virtually the inverse of the free-rider problem. 223 When flows compete for resources, if one flow receives undeserving high 224 priority it may be able to preempt another deserving flow (hence one 225 free-rider turns out to be another's denial of service). 227 Instability: 229 The combination of preemption priority, killer reservation and blockade 230 state [RSVP] may increase the instability of admitted flows where a 231 reservation may be preempted, reinstated, and preempted again 232 periodically. 234 5.1 Priority Merging Strategies 236 In merging situations LDPs may receive multiple preemption elements and 237 must compute the priority of the merged flow according to the following 238 rules: 240 a. Preemption priority and defending priority are merged and computed 241 separately, irrespective of each other. 243 b. Participating priority elements are selected. 245 All priority elements are examined according to their merging 246 strategy to decide whether they should participate in the merged 247 result (as specified bellow). 249 c. The highest priority of all participating priority elements is 250 computed. 252 The remainder of this section describes the different merging 253 strategies the can be specified in the PREEMPTION_PRI element. 255 5.1.1 Take priority of highest QoS 257 The PREEMPTION_PRI element would participate in the merged reservation 258 only if it belongs to a flow that contributed to the merged QoS level 259 (i.e., that its QoS requirement does not constitute a subset another 260 reservation.) 261 A simple way to determine whether a flow contributed to the merged QoS 262 result is to compute the merged QoS with and without it and to compare 263 the results (although this is clearly not the most efficient method). 265 The reasoning for this approach is that the highest QoS flow is the one 266 dominating the merged reservation and as such its priority should 267 dominate it as well. This approach is the most amiable to the 268 prevention of priority distortions such as free-riders and denial of 269 service. 271 This is a recommended merging strategy. 273 5.1.2 Take highest priority 275 All PREEMPTION_PRI elements participate in the merged reservation. 277 This strategy disassociates priority and QoS level, and therefore is 278 highly subject to free-riders and its inverse image, denial of service. 280 This is not a recommended method, but may be simpler to implement. 282 5.1.3 Force error on heterogeneous merge 284 A PREEMPTION_PRI element may participate in a merged reservation only 285 if all other flows in the merged reservation have the same QoS level 286 (homogeneous flows). 288 The reasoning for this approach assumes that the heterogeneous case is 289 relatively rare and too complicated to deal with, thus it better be 290 prohibited. 292 This strategy lends itself to denial of service, when a single receiver 293 specifying a non-compatible QoS level may cause denial of service for 294 all other receivers of the merged reservation. 296 Note: The determination of heterogeneous flows applies to QoS level 297 only (FLOWSPEC values), and is a matter for local (LDP) definition. 298 Other types of heterogeneous reservations (e.g. conflicting reservation 299 styles) are handled by RSVP and are unrelated to this PREEMPTION_PRI 300 element. 302 This is a recommended merging strategy when reservation homogeneity is 303 coordinated and enforced for the entire multicast tree. It is more 304 restrictive than Section 5.1.1, but is easier to implement. 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 that 318 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 326 merging strategies, regardless of the number of receivers (See the 327 example in 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 IANA Considerations 352 Following the policies outlined in [IANA-CONSIDERATIONS], 353 Standard RSVP Policy Elements (P-type values) are assigned by IETF 354 Consensus action\t as described in [RSVP-EXT]. 356 P-Type PREEMPTION_PRI is assigned the value 3. 358 8 Security Considerations 360 The integrity of PREEMPTION_PRI is guaranteed, as any other policy 361 element, by the encapsulation into a Policy Data object [RSVP-EXT]. 363 Further security mechanisms are not warranted, especially considering 364 that preemption priority aims to provide simple and quick guidance to 365 routers within a trusted zone or at least a single zone (no zone 366 boundaries are crossed). 368 9 References 370 [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", Internet- 371 Draft, draft-ietf-rsvp-ext-02.txt, Jan. 1999. 373 [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., 374 Sastry, A., "COPS usage for RSVP" Internet-Draft, draft-ietf- 375 rap-cops-rsvp-02.txt, Jan 1999. 377 [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission 378 Control",IETF , Jan., 1999. 380 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 381 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 382 IETF , Jan. 1999. 384 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 385 Functional Specification.", IETF RFC 2205, Proposed Standard, 386 Sep. 1997. 388 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 389 Writing an IANA Considerations Section in RFCs", RFC 2434, 390 October 1998. 392 10 Author Information 394 Shai Herzog, IPHighway 395 Parker Plaza, 16 floor 396 400 Kelby St. 397 Fort-Lee, NJ 07024 398 (201) 585-0800 399 herzog@iphighway.com 401 Appendix A: Example 403 The following examples describe the computation of merged priority 404 elements as well as the translation (compression) of PREEMPTION_PRI 405 elements. 407 A.1 Computing Merged Priority 409 r1 410 / QoS=Hi (Pr=3, St=Highest QoS) 411 / 412 s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP) 413 \ \ 414 \ \ QoS=Low (Pr=7, St=Highest QoS) 415 r4 r3 417 QoS=Low (Pr=9, St=Error) 419 Example 1: Merging preemption priority elements 421 Example one describes a multicast scenario with one sender and four 422 receivers each with each own PREEMPTION_PRI element definition. 424 r1, r2 and r3 merge in B. The resulting priority is 4. 426 Reason: The PREEMPTION_PRI of r3 doesn't participate (since r3 is not 427 contributing to the merged QoS) and the priority is the highest of the 428 PREEMPTION_PRI from r1 and r2. 430 r1, r2, r3 and r4 merge in A. The resulting priority is again 4: r4 431 doesn't participate because its own QoS=Low is incompatible with the 432 other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to r4 433 telling it that its PREEMPTION_PRI element encountered heterogeneity. 435 A.2 Translation (Compression) of Priority Elements 437 Given this set of participating PREEMPTION_PRI elements, the following 438 compression can take place at the merging node: 440 From: 441 (Pr=3, St=Highest QoS) 442 (Pr=7, St=Highest QoS) 443 (Pr=4, St=Highest PP) 444 (Pr=9, St=Highest PP) 445 (Pr=6, St=Highest PP) 446 To: 447 (Pr=7, St=Highest QoS) 448 (Pr=9, St=Highest PP)