idnits 2.17.1 draft-ietf-rap-signaled-priority-v2-00.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 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. ** There are 4 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 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.) -- The document date (July 2000) is 8687 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 140, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'RAP') ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft S. Herzog 3 Expiration: January 2001 IPHighway 4 File: draft-ietf-rap-signaled-priority-v2-00.txt July 2000 5 Replaces: RFC 2751 7 Signaled Preemption Priority Policy Element 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 groups 16 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 Distribution of this memo is unlimited. 31 Copyright Notice 33 Copyright (C) The Internet Society (2000). All Rights Reserved. 35 Abstract 37 This document describes a preemption priority policy element for use 38 by signaled policy based admission protocols (such as [RSVP] and 39 [COPS]). 41 Preemption priority defines a relative importance (rank) within the 42 set of flows competing to be admitted into the network. Rather than 43 admitting flows by order of arrival (First Come First Admitted) 44 network nodes may consider priorities to preempt some previously 45 admitted low priority flows in order to make room for a newer, high- 46 priority flow. 48 This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment 49 error in RFC 2751. 51 Table of Contents 53 1 Introduction .....................................................2 54 2 Scope and Applicability ..........................................3 55 3 Stateless Policy .................................................3 56 4 Policy Element Format ............................................4 57 5 Priority Merging Issues ..........................................5 58 5.1 Priority Merging Strategies ...................................6 59 5.1.1 Take priority of highest QoS .................................6 60 5.1.2 Take highest priority ........................................7 61 5.1.3 Force error on heterogeneous merge ...........................7 62 5.2 Modifying Priority Elements ...................................7 63 6 Error Processing .................................................8 64 7 IANA Considerations ..............................................8 65 8 Security Considerations ..........................................8 66 9 References .......................................................9 67 10 Author Information .............................................9 68 Appendix A: Example ...............................................10 69 A.1 Computing Merged Priority ....................................10 70 A.2 Translation (Compression) of Priority Elements ...............11 71 Full Copyright Statement ..........................................12 73 1 Introduction 75 Traditional Capacity based Admission Control (CAC) indiscriminately 76 admits new flows until capacity is exhausted (First Come First 77 Admitted). Policy based Admission Control (PAC) on the other hand 78 attempts to minimize the significance of order of arrival and use 79 policy based admission criteria instead. 81 One of the more popular policy criteria is the rank of importance of 82 a flow relative to the others competing for admission into a network 83 node. Preemption Priority takes effect only when a set of flows 84 attempting admission through a node represents overbooking of 85 resources such that based on CAC some would have to be rejected. 86 Preemption priority criteria help the node select the most important 87 flows (highest priority) for admission, while rejecting the low 88 priority ones. 90 Network nodes which support preemption should consider priorities to 91 preempt some previously admitted low-priority flows in order to make 92 room for a newer, high-priority flow. 94 This document describes the format and applicability of the 95 preemption priority represented as a policy element in [RSVP-EXT]. 97 2 Scope and Applicability 99 The Framework document for policy-based admission control [RAP] 100 describes the various components that participate in policy decision 101 making (i.e., PDP, PEP and LDP). The emphasis of PREEMPTION_PRI 102 elements is to be simple, stateless, and light-weight such that they 103 could be implemented internally within a node's LDP (Local Decision 104 Point). 106 Certain base assumptions are made in the usage model for 107 PREEMPTION_PRI elements: 109 - They are created by PDPs 111 In a model where PDPs control PEPs at the periphery of the policy 112 domain (e.g., in border routers), PDPs reduce sets of relevant 113 policy rules into a single priority criterion. This priority as 114 expressed in the PREEMPTION_PRI element can then be communicated 115 to downstream PEPs of the same policy domain, which have LDPs but 116 no controlling PDP. 118 - They can be processed by LDPs 120 PREEMPTION_PRI elements are processed by LDPs of nodes that do not 121 have a controlling PDP. LDPs may interpret these objects, forward 122 them as is, or perform local merging to forward an equivalent 123 merged PREEMPTION_PRI policy element. LDPs must follow the merging 124 strategy that was encoded by PDPs in the PREEMPTION_PRI objects. 125 (Clearly, a PDP, being a superset of LDP, may act as an LDP as 126 well). 128 - They are enforced by PEPs 130 PREEMPTION_PRI elements interact with a node's traffic control 131 module (and capacity admission control) to enforce priorities, and 132 preempt previously admitted flows when the need arises. 134 3 Stateless Policy 136 Signaled Preemption Priority is stateless (does not require past 137 history or external information to be interpreted). Therefore, when 138 carried in COPS messages for the outsourcing of policy decisions, 139 these objects are included as COPS Stateless Policy Data Decision 140 objects (see [COSP, COPS-RSVP]). 142 4 Policy Element Format 144 The format of Policy Data objects is defined in [RSVP-EXT]. A single 145 Policy Data object may contain one or more policy elements, each 146 representing a different (and perhaps orthogonal) policy. 148 The format of preemption priority policy element is as follows: 150 +-------------+-------------+-------------+-------------+ 151 | Length (12) | P-Type = PREEMPTION_PRI | 152 +------+------+-------------+-------------+-------------+ 153 | Flags | M. Strategy | Error Code | Reserved(0) | 154 +------+------+-------------+-------------+-------------+ 155 | Preemption Priority | Defending Priority | 156 +------+------+-------------+-------------+-------------+ 158 Length: 16 bits 159 Always 12. The overall length of the policy element, in bytes. 161 P-Type: 16 bits 162 PREEMPTION_PRI = 1 164 This value is registered with IANA, see Section 7. 166 Flags: 8 bits 167 Reserved (always 0). 169 Merge Strategy: 8 bit 170 1 Take priority of highest QoS: recommended 171 2 Take highest priority: aggressive 172 3 Force Error on heterogeneous merge 174 Reserved: 8 bits 175 Error code: 8 bits 176 0 NO_ERROR Value used for regular PREEMPTION_PRI elements 177 1 PREEMPTION This previously admitted flow was preempted 178 2 HETEROGENEOUS This element encountered heterogeneous merge 180 Reserved: 8 bits 181 Always 0. 183 Preemption Priority: 16 bit (unsigned) 184 The priority of the new flow compared with the defending priority 185 of previously admitted flows. Higher values represent higher 186 Priority. 188 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 191 with 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, but 197 once it succeeded, the higher defending priority makes it easier for 198 the flow to avoid preemption itself. This provides a mechanism for 199 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 211 should it assume? Several negative side-effects have been identified 212 that may 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 224 fail 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 228 high priority it may be able to preempt another deserving flow (hence 229 one free-rider turns out to be another's denial of service). 231 Instability: 233 The combination of preemption priority, killer reservation and 234 blockade state [RSVP] may increase the instability of admitted flows 235 where a 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 262 reservation only if it belongs to a flow that contributed to the 263 merged QoS level (i.e., that its QoS requirement does not constitute 264 a subset another reservation.) A simple way to determine whether a 265 flow contributed to the merged QoS result is to compute the merged 266 QoS with and without it and to compare the results (although this is 267 clearly not the most efficient method). 269 The reasoning for this approach is that the highest QoS flow is the 270 one 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 283 service. 285 This is not a recommended method, but may be simpler to implement. 287 5.1.3 Force error on heterogeneous merge 289 A PREEMPTION_PRI element may participate in a merged reservation only 290 if all other flows in the merged reservation have the same QoS level 291 (homogeneous flows). 293 The reasoning for this approach assumes that the heterogeneous case 294 is relatively rare and too complicated to deal with, thus it better 295 be prohibited. 297 This strategy lends itself to denial of service, when a single 298 receiver specifying a non-compatible QoS level may cause denial of 299 service for all other receivers of the merged reservation. 301 Note: The determination of heterogeneous flows applies to QoS level 302 only (FLOWSPEC values), and is a matter for local (LDP) definition. 303 Other types of heterogeneous reservations (e.g. conflicting 304 reservation styles) are handled by RSVP and are unrelated to this 305 PREEMPTION_PRI element. 307 This is a recommended merging strategy when reservation homogeneity 308 is coordinated and enforced for the entire multicast tree. It is more 309 restrictive than Section 5.1.1, but is easier to implement. 311 5.2 Modifying Priority Elements 313 When POLICY_DATA objects are protected by integrity, LDPs should not 314 attempt to modify them. They must be forwarded as-is or else their 315 security envelope would be invalidated. In other cases, LDPs may 316 modify and merge incoming PREEMPTION_PRI elements to reduce their 317 size and number according to the following rule: 319 Merging is performed for each merging strategy separately. 321 There is no known algorithm to merge PREEMPTION_PRI element of 322 different merging strategies without loosing valuable information 323 that may affect OTHER nodes. 325 - For each merging strategy, the highest QoS of all participating 326 PREEMPTION_PRI elements is taken and is placed in an outgoing 327 PREEMPTION_PRI element of this merging strategy. 329 - This approach effectively compresses the number of forwarded 330 PREEMPTION_PRI elements to at most to the number of different 331 merging strategies, regardless of the number of receivers (See the 332 example in Appendix A.2). 334 6 Error Processing 336 A PREEMPTION_PRI error object is sent back toward the appropriate 337 receivers when an error involving PREEMPTION_PRI elements occur. 339 PREEMPTION 341 When a previously admitted flow is preempted, a copy of the 342 preempting flow's PREEMPTION_PRI element is sent back toward the PDP 343 that originated the preempted PREEMPTION_PRI object. This PDP, having 344 information on both the preempting and the preempted priorities may 345 construct a higher priority PREEMPTION_PRI element in an effort to 346 re-instate the preempted flow. 348 Heterogeneity 350 When a flow F1 with Heterogeneous Error merging strategy set in its 351 PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI 352 element is sent back toward receivers with the Heterogeneity error 353 code set. 355 7 IANA Considerations 357 Following the policies outlined in [IANA-CONSIDERATIONS], Standard 358 RSVP Policy Elements (P-type values) are assigned by IETF Consensus 359 action as described in [RSVP-EXT]. 361 P-Type PREEMPTION_PRI is assigned the value 3. 363 8 Security Considerations 365 The integrity of PREEMPTION_PRI is guaranteed, as any other policy 366 element, by the encapsulation into a Policy Data object [RSVP-EXT]. 368 Further security mechanisms are not warranted, especially considering 369 that preemption priority aims to provide simple and quick guidance to 370 routers within a trusted zone or at least a single zone (no zone 371 boundaries are crossed). 373 9 References 375 [RSVP-EXT] Herzog, S., "RSVP Extensions for Policy 376 Control", RFC 2750, January 2000. 378 [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., 379 Raja, R. and A. Sastry, "COPS usage for RSVP", 380 RFC 2749, January 2000. 382 [RAP] Yavatkar, R., et al., "A Framework for Policy 383 Based Admission Control", RFC 2753, January 384 2000. 386 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., 387 Raja, R. and A. Sastry, "The COPS (Common Open 388 Policy Service) Protocol", RFC 2748, January 389 2000. 391 [RSVP] Braden, R., ed., et al., "Resource ReSerVation 392 Protocol (RSVP) - Functional Specification", 393 RFC 2205, September 1997. 395 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 396 Writing an IANA Considerations Section in 397 RFCs", BCP 26, RFC 2434, October 1998. 399 10 Author Information 401 Shai Herzog 402 IPHighway, Inc. 403 55 New York Avenue 404 Framingham, MA 01701 406 Phone: (508) 620-1141 407 EMail: herzog@iphighway.com 409 Appendix A: Example 411 The following examples describe the computation of merged priority 412 elements as well as the translation (compression) of PREEMPTION_PRI 413 elements. 415 A.1 Computing Merged Priority 417 r1 418 / QoS=Hi (Pr=3, St=Highest QoS) 419 / 420 s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP) 421 \ \ 422 \ \ QoS=Low (Pr=7, St=Highest QoS) 423 r4 r3 425 QoS=Low (Pr=9, St=Error) 427 Example 1: Merging preemption priority elements 429 Example one describes a multicast scenario with one sender and four 430 receivers each with each own PREEMPTION_PRI element definition. 432 r1, r2 and r3 merge in B. The resulting priority is 4. 434 Reason: The PREEMPTION_PRI of r3 doesn't participate (since r3 is not 435 contributing to the merged QoS) and the priority is the highest of 436 the PREEMPTION_PRI from r1 and r2. 438 r1, r2, r3 and r4 merge in A. The resulting priority is again 4: r4 439 doesn't participate because its own QoS=Low is incompatible with the 440 other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to 441 r4 telling it that its PREEMPTION_PRI element encountered 442 heterogeneity. 444 A.2 Translation (Compression) of Priority Elements 446 Given this set of participating PREEMPTION_PRI elements, the 447 following compression can take place at the merging node: 449 From: 450 (Pr=3, St=Highest QoS) 451 (Pr=7, St=Highest QoS) 452 (Pr=4, St=Highest PP) 453 (Pr=9, St=Highest PP) 454 (Pr=6, St=Highest PP) 455 To: 456 (Pr=7, St=Highest QoS) 457 (Pr=9, St=Highest PP) 459 Full Copyright Statement 461 Copyright (C) The Internet Society (2000). All Rights Reserved. 463 This document and translations of it may be copied and furnished to 464 others, and derivative works that comment on or otherwise explain it 465 or assist in its implementation may be prepared, copied, published 466 and distributed, in whole or in part, without restriction of any 467 kind, provided that the above copyright notice and this paragraph are 468 included on all such copies and derivative works. However, this 469 document itself may not be modified in any way, such as by removing 470 the copyright notice or references to the Internet Society or other 471 Internet organizations, except as needed for the purpose of 472 developing Internet standards in which case the procedures for 473 copyrights defined in the Internet Standards process must be 474 followed, or as required to translate it into languages other than 475 English. 477 The limited permissions granted above are perpetual and will not be 478 revoked by the Internet Society or its successors or assigns. 480 This document and the information contained herein is provided on an 481 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 482 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 483 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 484 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 485 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 487 Acknowledgement 489 Funding for the RFC Editor function is currently provided by the 490 Internet Society.