idnits 2.17.1 draft-ietf-rap-signaled-priority-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 253 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 (February 26, 1999) is 9191 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 139, 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' ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Shai Herzog 3 Expiration: August 1999 IPHighway 4 File: draft-ietf-rap-signaled-priority-03.txt 6 Signaled Preemption Priority Policy Element 8 February 26, 1999 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes a preemption priority policy element for use 34 by signaled policy based admission protocols (such as [RSVP] and 35 [COPS]). 37 Preemption priority defines a relative importance (rank) within the 38 set of flows competing to be admitted into the network. Rather than 39 admitting flows by order of arrival (First Come First Admitted) 40 network nodes may consider priorities to preempt some previously 41 admitted low priority flows in order to make room for a newer, high- 42 priority flow. 44 Internet Draft Signaled Preemption Priority Policy 26-Feb-99 46 Table of Contents 48 Abstract.............................................................1 49 Table of Contents....................................................2 50 1 Introduction.......................................................3 51 2 Scope and Applicability............................................3 52 3 Stateless Policy...................................................4 53 4 Policy Element Format..............................................4 54 5 Priority Merging Issues............................................6 55 5.1 Priority Merging Strategies.....................................7 56 5.1.1 Take priority of highest QoS...................................7 57 5.1.2 Take highest priority..........................................7 58 5.1.3 Force error on heterogeneous merge.............................8 59 5.2 Modifying Priority Elements.....................................8 60 6 Error Processing...................................................9 61 7 IANA Considerations................................................9 62 8 Security Considerations............................................9 63 9 References........................................................10 64 10 Author Information..............................................10 65 Appendix A: Example.................................................11 66 A.1 Computing Merged Priority......................................11 67 A.2 Translation (Compression) of Priority Elements.................11 68 Internet Draft Signaled Preemption Priority Policy 26-Feb-99 70 1 Introduction 72 Traditional Capacity based Admission Control (CAC) indiscriminately 73 admits new flows until capacity is exhausted (First Come First 74 Admitted). Policy based Admission Control (PAC) on the other hand 75 attempts to minimize the significance of order of arrival and use 76 policy based admission criteria instead. 78 One of the more popular policy criteria is the rank of importance of 79 a flow relative to the others competing for admission into a network 80 node. Preemption Priority takes effect only when a set of flows 81 attempting admission through a node represents overbooking of 82 resources such that based on CAC some would have to be rejected. 83 Preemption priority criteria help the node select the most important 84 flows (highest priority) for admission, while rejecting the low 85 priority ones. 87 Network nodes which support preemption should consider priorities to 88 preempt some previously admitted low-priority flows in order to make 89 room for a newer, high-priority flow. 91 This document describes the format and applicability of the 92 preemption priority represented as a policy element in [RSVP-EXT]. 94 2 Scope and Applicability 96 The Framework document for policy-based admission control [RAP] 97 describes the various components that participate in policy decision 98 making (i.e., PDP, PEP and LDP). The emphasis of PREEMPTION_PRI 99 elements is to be simple, stateless, and light-weight such that they 100 could be implemented internally within a node's LDP (Local Decision 101 Point). 103 Certain base assumptions are made in the usage model for 104 PREEMPTION_PRI elements: 106 - They are created by PDPs 108 In a model where PDPs control PEPs at the periphery of the policy 109 domain (e.g., in border routers), PDPs reduce sets of relevant 110 policy rules into a single priority criterion. This priority as 111 expressed in the PREEMPTION_PRI element can then be communicated 112 to downstream PEPs of the same policy domain, which have LDPs but 113 no controlling PDP. 115 Internet Draft Signaled Preemption Priority Policy 26-Feb-99 117 - They can be processed by LDPs 119 PREEMPTION_PRI elements are processed by LDPs of nodes that do not 120 have a controlling PDP. LDPs may interpret these objects, forward 121 them as is, or perform local merging to forward an equivalent 122 merged PREEMPTION_PRI policy element. LDPs must follow the merging 123 strategy that was encoded by PDPs in the PREEMPTION_PRI objects. 124 (Clearly, a PDP, being a superset of LDP, may act as an LDP as 125 well). 127 - They are enforced by PEPs 129 PREEMPTION_PRI elements interact with a node's traffic control 130 module (and capacity admission control) to enforce priorities, and 131 preempt previously admitted flows when the need arises. 133 3 Stateless Policy 135 Signaled Preemption Priority is stateless (does not require past 136 history or external information to be interpreted). Therefore, when 137 carried in COPS messages for the outsourcing of policy decisions, 138 these objects are included as COPS Stateless Policy Data Decision 139 objects (see [COSP, COPS-RSVP]). 141 4 Policy Element Format 143 The format of Policy Data objects is defined in [RSVP-EXT]. A single 144 Policy Data object may contain one or more policy elements, each 145 representing a different (and perhaps orthogonal) policy. 147 The format of preemption priority policy element is as follows: 149 +-------------+-------------+-------------+-------------+ 150 | Length (12) | P-Type = PREEMPTION_PRI | 151 +------+------+-------------+-------------+-------------+ 152 | Flags | M. Strategy | Error Code | Reserved(0) | 153 +------+------+-------------+-------------+-------------+ 154 | Preemption Priority | Defending Priority | 155 +------+------+-------------+-------------+-------------+ 157 Internet Draft Signaled Preemption Priority Policy 26-Feb-99 159 Length: 16 bits 161 Always 12. The overall length of the policy element, in bytes. 163 P-Type: 16 bits 165 PREEMPTION_PRI = 1 167 Flags: 8 bits 169 Reserved (always 0). 171 Merge Strategy: 8 bit 173 1 Take priority of highest QoS: recommended 174 2 Take highest priority: aggressive 175 3 Force Error on heterogeneous merge 177 Reserved: 8 bits 179 Error code: 8 bits 181 0 NO_ERROR Value used for regular PREEMPTION_PRI elements 182 1 PREEMPTION This previously admitted flow was preempted 183 2 HETEROGENEOUS This element encountered heterogeneous merge 185 Reserved: 8 bits 187 Always 0. 189 Preemption Priority: 16 bit (unsigned) 191 The priority of the new flow compared with the defending priority 192 of previously admitted flows. Higher values represent higher 193 Priority. 195 Defending Priority: 16 bits (unsigned) 197 Once a flow was admitted, the preemption priority becomes 198 irrelevant. Instead, its defending priority is used to compare 199 with the preemption priority of new flows. 201 For any specific flow, its preemption priority must always be less 202 than or equal to the defending priority. A wide gap between 203 preemption and defending priority provides added stability: 204 moderate preemption priority makes it harder for a flow to preempt 205 others, but once it succeeded, the higher defending priority makes 206 it easier for the flow to avoid preemption itself. This provides a 207 mechanism for balancing between order dependency and priority. 209 Internet Draft Signaled Preemption Priority Policy 26-Feb-99 211 5 Priority Merging Issues 213 Consider the case where two RSVP reservations merge: 215 F1: QoS=High, Priority=Low 216 F2: QoS=Low, Priority=High 218 F1+F2= F3: QoS=High, Priority=??? 220 The merged reservation F3 should have QoS=Hi, but what Priority 221 should it assume? Several negative side-effects have been identified 222 that may affect such a merger: 224 Free-Riders: 226 If F3 assumes Priority=High, then F1 got a free ride, assuming high 227 priority that was only intended to the low QoS F2. If one associates 228 costs as a function of QoS and priority, F1 receives an "expensive" 229 priority without having to "pay" for it. 231 Denial of Service: 233 If F3 assumes Priority=Low, the merged flow could be preempted or 234 fail even though F2 presented high priority. 236 Denial of service is virtually the inverse of the free-rider 237 problem. When flows compete for resources, if one flow receives 238 undeserving high priority it may be able to preempt another 239 deserving flow (hence one free-rider turns out to be another's 240 denial of service). 242 Instability: 244 The combination of preemption priority, killer reservation and 245 blockade state [RSVP] may increase the instability of admitted flows 246 where a reservation may be preempted, reinstated, and preempted 247 again periodically. 249 Internet Draft Signaled Preemption Priority Policy 26-Feb-99 251 .1 Priority Merging Strategies 253 In merging situations LDPs may receive multiple preemption elements 254 and must compute the priority of the merged flow according to the 255 following rules: 257 a. Preemption priority and defending priority are merged and 258 computed separately, irrespective of each other. 260 b. Participating priority elements are selected. 262 All priority elements are examined according to their merging 263 strategy to decide whether they should participate in the merged 264 result (as specified bellow). 266 c. The highest priority of all participating priority elements is 267 computed. 269 The remainder of this section describes the different merging 270 strategies the can be specified in the PREEMPTION_PRI element. 272 1.1 Take priority of highest QoS 274 The PREEMPTION_PRI element would participate in the merged 275 reservation only if it belongs to a flow that contributed to the 276 merged QoS level (i.e., that its QoS requirement does not constitute 277 a subset another reservation.) 278 A simple way to determine whether a flow contributed to the merged 279 QoS result is to compute the merged QoS with and without it and to 280 compare the results (although this is clearly not the most efficient 281 method). 283 The reasoning for this approach is that the highest QoS flow is the 284 one dominating the merged reservation and as such its priority 285 should dominate it as well. This approach is the most amiable to the 286 prevention of priority distortions such as free-riders and denial of 287 service. 289 This is a recommended merging strategy. 291 1.2 Take highest priority 293 All PREEMPTION_PRI elements participate in the merged reservation. 295 This strategy disassociates priority and QoS level, and therefore is 296 highly subject to free-riders and its inverse image, denial of 297 service. 299 This is not a recommended method, but may be simpler to implement. 301 Internet Draft Signaled Preemption Priority Policy 26-Feb-99 303 1.3 Force error on heterogeneous merge 305 A PREEMPTION_PRI element may participate in a merged reservation 306 only if all other flows in the merged reservation have the same QoS 307 level (homogeneous flows). 309 The reasoning for this approach assumes that the heterogeneous case 310 is relatively rare and too complicated to deal with, thus it better 311 be prohibited. 313 This strategy lends itself to denial of service, when a single 314 receiver specifying a non-compatible QoS level may cause denial of 315 service for all other receivers of the merged reservation. 317 Note: The determination of heterogeneous flows applies to QoS level 318 only (FLOWSPEC values), and is a matter for local (LDP) definition. 319 Other types of heterogeneous reservations (e.g. conflicting 320 reservation styles) are handled by RSVP and are unrelated to this 321 PREEMPTION_PRI element. 323 This is a recommended merging strategy when reservation homogeneity 324 is coordinated and enforced for the entire multicast tree. It is 325 more restrictive than Section 5.1.1, but is easier to implement. 327 .2 Modifying Priority Elements 329 When POLICY_DATA objects are protected by integrity, LDPs should not 330 attempt to modify them. They must be forwarded as-is or else their 331 security envelope would be invalidated. In other cases, LDPs may 332 modify and merge incoming PREEMPTION_PRI elements to reduce their 333 size and number according to the following rule: 335 - Merging is performed for each merging strategy separately. 337 There is no known algorithm to merge PREEMPTION_PRI element of 338 different merging strategies without loosing valuable information 339 that may affect OTHER nodes. 341 - For each merging strategy, the highest QoS of all participating 342 PREEMPTION_PRI elements is taken and is placed in an outgoing 343 PREEMPTION_PRI element of this merging strategy. 345 This approach effectively compresses the number of forwarded 346 PREEMPTION_PRI elements to at most to the number of different 347 merging strategies, regardless of the number of receivers (See the 348 example in Appendix A.2). 350 Internet Draft Signaled Preemption Priority Policy 26-Feb-99 352 6 Error Processing 354 A PREEMPTION_PRI error object is sent back toward the appropriate 355 receivers when an error involving PREEMPTION_PRI elements occur. 357 PREEMPTION 359 When a previously admitted flow is preempted, a copy of the 360 preempting flow's PREEMPTION_PRI element is sent back toward the PDP 361 that originated the preempted PREEMPTION_PRI object. This PDP, 362 having information on both the preempting and the preempted 363 priorities may construct a higher priority PREEMPTION_PRI element in 364 an effort to re-instate the preempted flow. 366 Heterogeneity 368 When a flow F1 with Heterogeneous Error merging strategy set in its 369 PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI 370 element is sent back toward receivers with the Heterogeneity error 371 code set. 373 7 IANA Considerations 375 RSVP Policy Data object P-type values are assigned by IANA, as 376 described in [RSVP-EXT]. 378 The values for inclusion in the other protocol data fields defined 379 in this memo are assigned by IETF Consensus action, as defined in 380 [IANA-CONSIDERATIONS]." 382 8 Security Considerations 384 The integrity of PREEMPTION_PRI is guaranteed, as any other policy 385 element, by the encapsulation into a Policy Data object [RSVP-EXT]. 387 Further security mechanisms are not warranted, especially 388 considering that preemption priority aims to provide simple and 389 quick guidance to routers within a trusted zone or at least a single 390 zone (no zone boundaries are crossed). 392 Internet Draft Signaled Preemption Priority Policy 26-Feb-99 394 9 References 396 [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", 397 Internet-Draft, draft-ietf-rap-rsvp-ext-02.txt, Jan. 1999. 399 [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n 400 R., Sastry, A., "COPS usage for RSVP" Internet-Draft, draft- 401 ietf-rap-cops-rsvp-02.txt, Jan 1999. 403 [RAP] Yavatkar, R., et al., "A Framework for Policy Based 404 Admission Control",IETF , 405 Jan., 1999. 407 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 408 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 409 IETF , Jan. 1999. 411 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 412 Functional Specification.", IETF RFC 2205, Proposed Standard, 413 Sep. 1997. 415 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 416 Writing an IANA Considerations Section in RFCs", RFC 2434, 417 October 1998. 419 10 Author Information 421 Shai Herzog, IPHighway 422 Parker Plaza, Suite 1500 423 400 Kelby St. 424 Fort-Lee, NJ 07024 425 (201) 585-0800 426 herzog@iphighway.com 428 Internet Draft Signaled Preemption Priority Policy 26-Feb-99 430 Appendix A: Example 432 The following examples describe the computation of merged priority 433 elements as well as the translation (compression) of PREEMPTION_PRI 434 elements. 436 A.1 Computing Merged Priority 438 r1 439 / QoS=Hi (Pr=3, St=Highest QoS) 440 / 441 s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP) 442 \ \ 443 \ \ QoS=Low (Pr=7, St=Highest QoS) 444 r4 r3 446 QoS=Low (Pr=9, St=Error) 448 Example 1: Merging preemption priority elements 450 Example one describes a multicast scenario with one sender and four 451 receivers each with each own PREEMPTION_PRI element definition. 453 r1, r2 and r3 merge in B. The resulting priority is 4. 455 Reason: The PREEMPTION_PRI of r3 doesn't participate (since r3 is 456 not contributing to the merged QoS) and the priority is the highest 457 of the PREEMPTION_PRI from r1 and r2. 459 r1, r2, r3 and r4 merge in A. The resulting priority is again 4: r4 460 doesn't participate because its own QoS=Low is incompatible with the 461 other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to 462 r4 telling it that its PREEMPTION_PRI element encountered 463 heterogeneity. 465 A.2 Translation (Compression) of Priority Elements 467 Given this set of participating PREEMPTION_PRI elements, the 468 following compression can take place at the merging node: 470 From: 471 (Pr=3, St=Highest QoS) 472 (Pr=7, St=Highest QoS) 473 (Pr=4, St=Highest PP) 474 (Pr=9, St=Highest PP) 475 (Pr=6, St=Highest PP) 476 To: 477 (Pr=7, St=Highest QoS) 478 (Pr=9, St=Highest PP)