RFC 3181

Signaled Preemption Priority Policy Element

📅 published October 2001, from ietf

RFC 3181: Signaled Preemption Priority Policy Element 🎀

okay bestie, let's get into this one 💖 it's giving policy + priority realness ✨

Title block tea ☕

  • RFC: 3181
  • Author: S. Herzog, PolicyConsulting.Com
  • Date: October 2001
  • Category: Standards Track
  • Obsoletes: RFC 2751 (this one replaces it 🫶)
  • Updates: nothing listed

Status of This Memo 📋

so this doc is a standards track protocol spec for the Internet community 🌐 and it's literally asking for discussion and suggestions 💬. for the standardization state and status of this protocol, check the current "Internet Official Protocol Standards" (STD 1) 📖. distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2001). All Rights Reserved. 💜

Abstract 🧚

this doc describes a preemption priority policy element for signaled policy based admission protocols (like the Resource ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS). 🔥

preemption priority is a relative importance (rank) inside the set of flows competing to get admitted into the network 👑. instead of admitting flows in order of arrival (First Come First Admitted), network nodes can use priorities to preempt some previously admitted low priority flows to make room for a newer, high-priority flow. literally the main character move 💅

this memo fixes an RSVP POLICY_DATA P-Type codepoint assignment error in RFC 2751 🙈.

Table of Contents 🗂️

1 Introduction .....................................................2
2 Scope and Applicability ..........................................3
3 Stateless Policy .................................................3
4 Policy Element Format ............................................4
5 Priority Merging Issues ..........................................5
5.1  Priority Merging Strategies ...................................6
5.1.1 Take priority of highest QoS .................................6
5.1.2 Take highest priority ........................................7
5.1.3 Force error on heterogeneous merge ...........................7
5.2  Modifying Priority Elements ...................................7
6 Error Processing .................................................8
7 IANA Considerations ..............................................8
8 Security Considerations ..........................................8
9 References .......................................................9
10  Author's Address ...............................................9
Appendix A: Example ...............................................10
A.1  Computing Merged Priority ....................................10
A.2  Translation (Compression) of Priority Elements ...............11
Full Copyright Statement ..........................................12

1. Introduction 💖

okay so this doc describes a preemption priority policy element for signaled policy based admission protocols (like [RSVP] and [COPS]) 🫧.

traditional Capacity based Admission Control (CAC) just admits new flows until capacity runs out (First Come First Admitted) 😩. Policy based Admission Control (PAC) is the glow-up 🌸: it tries to make order of arrival matter way less and uses policy based admission criteria instead.

one of the most popular policy criteria is how important a flow is compared to the other flows fighting for admission into a network node 👑. preemption priority only kicks in when a set of flows trying to get in overbooks resources, so that CAC would mean some have to get rejected 🙅‍♀️. the priority criteria help the node pick the most important flows (highest priority) to admit, and reject the low priority ones 💅.

network nodes that support preemption should consider priorities to preempt some previously admitted low-priority flows so there's room for a newer, high-priority flow ✨.

this document describes the format and applicability of the preemption priority, represented as a policy element in [RSVP-EXT] 🧚.

2. Scope and Applicability 🎀

the Framework document for policy-based admission control [RAP] explains the parts that take part in policy decisions (PDP, PEP and LDP) 🧩. the whole vibe of PREEMPTION_PRI elements is to be simple, stateless, and light-weight 🦋, so they can be implemented inside a node's LDP (Local Decision Point) without drama.

there are some base assumptions for the usage model of PREEMPTION_PRI elements 🫶:

  • They are created by PDPs

in a model where PDPs control PEPs at the edge of the policy domain (like border routers), PDPs squish a bunch of relevant policy rules into one single priority criterion 🍓. that priority, expressed in the PREEMPTION_PRI element, can then be sent to downstream PEPs in the same policy domain. those have LDPs but no controlling PDP.

  • They can be processed by LDPs

PREEMPTION_PRI elements get processed by the LDPs of nodes that don't have a controlling PDP 🌈. LDPs may interpret these objects, forward them as is, or do local merging to forward an equivalent merged PREEMPTION_PRI policy element. LDPs must follow the merging strategy that was encoded by PDPs in the PREEMPTION_PRI objects. (ngl, a PDP is a superset of an LDP, so it can act as an LDP too 👑.)

  • They are enforced by PEPs

PREEMPTION_PRI elements work with a node's traffic control module (and capacity admission control) to enforce priorities and preempt previously admitted flows when it's needed 💀.

3. Stateless Policy 🫶

Signaled Preemption Priority is stateless 🧠: it doesn't need past history or external info to be interpreted. so when it's carried in COPS messages for outsourcing policy decisions, these objects get included as COPS Stateless Policy Data Decision objects (see [COPS, COPS-RSVP]) 🎀.

4. Policy Element Format 🧩

the format of Policy Data objects is defined in [RSVP-EXT] 🧚. one Policy Data object can hold one or more policy elements, and each one represents a different (and maybe orthogonal) policy ✨.

the preemption priority policy element looks like this 👀:

   +-------------+-------------+-------------+-------------+
   | Length (12)               | P-Type = PREEMPTION_PRI   |
   +------+------+-------------+-------------+-------------+
   | Flags       | M. Strategy | Error Code  | Reserved(0) |
   +------+------+-------------+-------------+-------------+
   | Preemption Priority       | Defending Priority        |
   +------+------+-------------+-------------+-------------+

here's the breakdown, bestie 💅:

  • Length (16 bits): always 12, which is the overall length of the policy element in bytes 📏.
  • P-Type (16 bits): PREEMPTION_PRI = 1. this value is registered with IANA, see Section 7 📋.
  • Flags (8 bits): reserved, always 0 🔒.
  • Merge Strategy (8 bits): one of these 🫧:
   1    Take priority of highest QoS: recommended
   2    Take highest priority: aggressive
   3    Force Error on heterogeneous merge
  • Reserved (8 bits) and Error code (8 bits): the error code is one of these 🙈:
   0  NO_ERROR        Value used for regular PREEMPTION_PRI elements
   1  PREEMPTION      This previously admitted flow was preempted
   2  HETEROGENEOUS   This element encountered heterogeneous merge
  • Reserved (8 bits): always 0 🫶.
  • Preemption Priority (16 bits, unsigned): the priority of the new flow, compared with the defending priority of previously admitted flows. higher values mean higher Priority 👑.
  • Defending Priority (16 bits, unsigned): once a flow is admitted, its preemption priority stops mattering 🥲. instead, its defending priority is what gets compared with the preemption priority of new flows 🛡️.
for any specific flow, its preemption priority must always be less than or equal to its defending priority. this is the big balancing trick ⚖️: a wide gap between the two gives extra stability. a moderate preemption priority makes it harder for a flow to preempt others, but once it succeeds, the higher defending priority makes it easier for the flow to avoid being preempted itself. that's how the mechanism balances order dependency and priority 🌸.

part 1 of 2, so more is coming bestie 🧚💖

5.1.3. Force error on heterogeneous merge ⛔

okay bestie, so a PREEMPTION_PRI element only gets to join a merged reservation if every other flow in that reservation has the same QoS level (aka homogeneous flows) 💅 no mixing allowed 🙅‍♀️

the reasoning here is that mixed-QoS merges are rare and way too messy to handle, so it's better to just ban them outright 🧚

ngl this one can enable denial of service 😱 like, a single receiver asking for an incompatible QoS level could tank things for every other receiver on the merged reservation. not it 💀

Note: The determination of heterogeneous flows applies to QoS level only (FLOWSPEC values), and is a matter for local (LDP) definition. Other types of heterogeneous reservations (e.g., conflicting reservation styles) are handled by RSVP and are unrelated to this PREEMPTION_PRI element. 🦋

this is a strategy that's recommended when reservation homogeneity is coordinated and enforced across the entire multicast tree 🌸 it's more restrictive than Section 5.1.1, but it's way easier to implement, so it's giving simplicity 🫶

5.2. Modifying Priority Elements 🛠️

when POLICY_DATA objects are protected by integrity, LDPs should not attempt to modify them 🔒 they have to be forwarded as-is, otherwise their security envelope gets invalidated and that's a whole disaster 😭

in every other case, LDPs may modify and merge incoming PREEMPTION_PRI elements to shrink their size and number, following this rule:

Merging is performed for each merging strategy separately. 💜

there's no known algorithm to merge PREEMPTION_PRI elements from different merging strategies without losing valuable information that may affect OTHER nodes 💀 so we keep them separate, periodt.

  • for each merging strategy, the highest QoS of all participating PREEMPTION_PRI elements is taken and placed into an outgoing PREEMPTION_PRI element of that same merging strategy ✨
  • this compresses the forwarded PREEMPTION_PRI elements down to at most the number of different merging strategies, no matter how many receivers there are 👑 (see the example in Appendix A.2)

6. Error Processing 🚨

a PREEMPTION_PRI error object gets sent back toward the appropriate receivers whenever something goes wrong with a PREEMPTION_PRI element 💌

PREEMPTION

when a previously admitted flow gets preempted, a copy of the preempting flow's PREEMPTION_PRI element is sent back toward the PDP that originated the preempted PREEMPTION_PRI object 🌈 that PDP knows both the preempting and the preempted priorities, so it can build a higher priority PREEMPTION_PRI element to try to bring the preempted flow back 🔥

Heterogeneity

when a flow F1 with the Heterogeneous Error merging strategy set in its PREEMPTION_PRI element runs into heterogeneity, the PREEMPTION_PRI element gets sent back toward receivers with the Heterogeneity error code set 🙈

7. IANA Considerations 📋

following the policies outlined in [IANA-CONSIDERATIONS], Standard RSVP Policy Elements (P-type values) are assigned by IETF Consensus action as described in [RSVP-EXT] 🧾

P-Type PREEMPTION_PRI is assigned the value 1 🍓

8. Security Considerations 🔐

the integrity of PREEMPTION_PRI is guaranteed, just like any other policy element, by being encapsulated into a Policy Data object [RSVP-EXT] 🛡️

further security mechanisms are not warranted 🙅‍♀️ especially since preemption priority is meant to give simple and quick guidance to routers within a trusted zone, or at least a single zone (no zone boundaries get crossed) ✨ it's a closed-circle situation, iykyk 💅

9. References 📚

  • [RFC2751] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000. 🦋
  • [RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. 💜
  • [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000. 🌸
  • [RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000. ⭐
  • [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. 🎀
  • [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Specification", RFC 2205, September 1997. 🧚
  • [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 🫶

10. Author's Address 🏡

Shai Herzog
PolicyConsulting.Com
200 Clove Rd.
New Rochelle, NY 10801

EMail: herzog@policyconsulting.com

Appendix A. Example 🎀

the following examples show how merged priority elements get computed, plus how PREEMPTION_PRI elements get translated (compressed) 🧠✨

A.1. Computing Merged Priority

                             r1
                            /   QoS=Hi (Pr=3, St=Highest QoS)
                           /
         s1-----A---------B--------r2  QoS=Low (Pr=4, St=Highest PP)
                 \        \
                  \        \   QoS=Low  (Pr=7, St=Highest QoS)
                   r4        r3

           QoS=Low (Pr=9, St=Error)

Example 1: Merging preemption priority elements

example one is a multicast scenario with one sender and four receivers, and each one has its own PREEMPTION_PRI element definition 🌈

r1, r2 and r3 merge in B. the resulting priority is 4 🍒

reason: r3's PREEMPTION_PRI doesn't participate (since r3 isn't contributing to the merged QoS), so the priority is the highest of the PREEMPTION_PRI from r1 and r2 💅

r1, r2, r3 and r4 merge in A. the resulting priority is again 4 ✨ r4 doesn't participate because its own QoS=Low is incompatible with r1's QoS=High 🙅‍♀️ an error PREEMPTION_PRI should be sent back to r4, telling it that its PREEMPTION_PRI element ran into heterogeneity 🚨

A.2. Translation (Compression) of Priority Elements

given this set of participating PREEMPTION_PRI elements, the merging node can do the following compression 🦋

From:
         (Pr=3, St=Highest QoS)
         (Pr=7, St=Highest QoS)
         (Pr=4, St=Highest PP)
         (Pr=9, St=Highest PP)
         (Pr=6, St=Highest PP)
To:
         (Pr=7, St=Highest QoS)
         (Pr=9, St=Highest PP)

five elements down to two, bestie 🌈👑

Copyright (C) The Internet Society (2001). All Rights Reserved.

this document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. however, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards (in which case the procedures for copyrights defined in the Internet Standards process must be followed), or as required to translate it into languages other than English 🌸

the limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns 💖

this document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🫶

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from