Signaled Preemption Priority Policy Element
How a preemption priority travels in an RSVP or COPS message, and what happens when two flows are merged.
Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, DOI 10.17487/RFC3181, October 2001, <https://www.rfc-editor.org/info/rfc3181>.
@misc{rfc3181,
series = {Request for Comments},
number = 3181,
howpublished = {RFC 3181},
publisher = {RFC Editor},
doi = {10.17487/RFC3181},
url = {https://www.rfc-editor.org/info/rfc3181},
author = {S. Herzog},
title = {{Signaled Preemption Priority Policy Element}},
pagetotal = 12,
year = 2001,
month = oct,
} RFC text
Contents
Network Working Group S. Herzog
Request for Comments: 3181 PolicyConsulting.Com
Obsoletes: 2751 October 2001
Category: Standards Track
Signaled Preemption Priority Policy Element
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes a preemption priority policy element for use
by signaled policy based admission protocols (such as the Resource
ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS).
Preemption priority defines a relative importance (rank) within the
set of flows competing to be admitted into the network. Rather than
admitting flows by order of arrival (First Come First Admitted)
network nodes may consider priorities to preempt some previously
admitted low priority flows in order to make room for a newer, high-
priority flow.
This memo corrects 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
This document describes a preemption priority policy element for use
by signaled policy based admission protocols (such as [RSVP] and
[COPS]).
Traditional Capacity based Admission Control (CAC) indiscriminately
admits new flows until capacity is exhausted (First Come First
Admitted). Policy based Admission Control (PAC) on the other hand
attempts to minimize the significance of order of arrival and use
policy based admission criteria instead.
One of the more popular policy criteria is the rank of importance of
a flow relative to the others competing for admission into a network
node. Preemption Priority takes effect only when a set of flows
attempting admission through a node represents overbooking of
resources such that based on CAC some would have to be rejected.
Preemption priority criteria help the node select the most important
flows (highest priority) for admission, while rejecting the low
priority ones.
Network nodes which support preemption should consider priorities to
preempt some previously admitted low-priority flows in order to make
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]
describes the various components that participate in policy decision
making (i.e., PDP, PEP and LDP). The emphasis of PREEMPTION_PRI
elements is to be simple, stateless, and light-weight such that they
could be implemented internally within a node's LDP (Local Decision
Point).
Certain base assumptions are made in the usage model for
PREEMPTION_PRI elements:
- They are created by PDPs
In a model where PDPs control PEPs at the periphery of the policy
domain (e.g., in border routers), PDPs reduce sets of relevant
policy rules into a single priority criterion. This priority as
expressed in the PREEMPTION_PRI element can then be communicated
to downstream PEPs of the same policy domain, which have LDPs but
no controlling PDP.
- They can be processed by LDPs
PREEMPTION_PRI elements are processed by LDPs of nodes that do not
have a controlling PDP. LDPs may interpret these objects, forward
them as is, or perform 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. (Clearly, a PDP, being a superset of LDP, may act as an
LDP as well).
- They are enforced by PEPs
PREEMPTION_PRI elements interact with a node's traffic control
module (and capacity admission control) to enforce priorities, and
preempt previously admitted flows when the need arises.
3 Stateless Policy
Signaled Preemption Priority is stateless (does not require past
history or external information to be interpreted). Therefore, when
carried in COPS messages for the outsourcing of policy decisions,
these objects are 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]. A single
Policy Data object may contain one or more policy elements, each
representing a different (and perhaps orthogonal) policy.
The format of preemption priority policy element is as follows:
+-------------+-------------+-------------+-------------+
| Length (12) | P-Type = PREEMPTION_PRI |
+------+------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved(0) |
+------+------+-------------+-------------+-------------+
| Preemption Priority | Defending Priority |
+------+------+-------------+-------------+-------------+
Length: 16 bits
Always 12. 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 bit
1 Take priority of highest QoS: recommended
2 Take highest priority: aggressive
3 Force Error on heterogeneous merge
Reserved: 8 bits
Error code: 8 bits
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 bit (unsigned)
The priority of the new flow compared with the defending priority
of previously admitted flows. Higher values represent higher
Priority.
Defending Priority: 16 bits (unsigned)
Once a flow was admitted, the preemption priority becomes
irrelevant. Instead, its defending priority is used to compare
with the preemption priority of new flows.
For any specific flow, its preemption priority must always be less
than or equal to the defending priority. A wide gap between
preemption and defending priority provides added stability: moderate
preemption priority makes it harder for a flow to preempt others, but
once it succeeded, the higher defending priority makes it easier for
the flow to avoid preemption itself. This provides a mechanism for
balancing between order dependency and priority.
5 Priority Merging Issues
Consider the case where two RSVP reservations merge:
F1: QoS=High, Priority=Low
F2: QoS=Low, Priority=High
F1+F2= F3: QoS=High, Priority=???
The merged reservation F3 should have QoS=Hi, but what Priority
should it assume? Several negative side-effects have been identified
that may affect such a merger:
Free-Riders:
If F3 assumes Priority=High, then F1 got a free ride, assuming high
priority that was only intended to the low QoS F2. If one associates
costs as a function of QoS and priority, F1 receives an "expensive"
priority without having to "pay" for it.
Denial of Service:
If F3 assumes Priority=Low, the merged flow could be preempted or
fail even though F2 presented high priority.
Denial of service is virtually the inverse of the free-rider problem.
When flows compete for resources, if one flow receives undeserving
high priority it may be able to preempt another deserving flow (hence
one free-rider turns out to be another's denial of service).
Instability:
The combination of preemption priority, killer reservation and
blockade state [RSVP] may increase the instability of admitted flows
where a reservation may be preempted, reinstated, and preempted again
periodically.
5.1 Priority Merging Strategies
In merging situations LDPs may receive multiple preemption elements
and must compute the priority of the merged flow according to the
following rules:
a. Preemption priority and defending priority are merged and computed
separately, irrespective of each other.
b. Participating priority elements are selected.
All priority elements are examined according to their merging
strategy to decide whether they should participate in the merged
result (as specified bellow).
c. The highest priority of all participating priority elements is
computed.
The remainder of this section describes the different merging
strategies the can be specified in the PREEMPTION_PRI element.
5.1.1 Take priority of highest QoS
The PREEMPTION_PRI element would participate in the merged
reservation only if it belongs to a flow that contributed to the
merged QoS level (i.e., that its QoS requirement does not constitute
a subset another reservation.) A simple way to determine whether a
flow contributed to the merged QoS result is to compute the merged
QoS with and without it and to compare the results (although this is
clearly not the most efficient method).
The reasoning for this approach is that the highest QoS flow is the
one dominating the merged reservation and as such its priority should
dominate it as well. This approach is the most amiable to the
prevention of priority distortions such as free-riders and denial of
service.
This is a recommended merging strategy.
5.1.2 Take highest priority
All PREEMPTION_PRI elements participate in the merged reservation.
This strategy disassociates priority and QoS level, and therefore is
highly subject to free-riders and its inverse image, denial of
service.
This is not a recommended method, but may be simpler to implement.
5.1.3 Force error on heterogeneous merge
A PREEMPTION_PRI element may participate in a merged reservation only
if all other flows in the merged reservation have the same QoS level
(homogeneous flows).
The reasoning for this approach assumes that the heterogeneous case
is relatively rare and too complicated to deal with, thus it better
be prohibited.
This strategy lends itself to denial of service, when a single
receiver specifying a non-compatible QoS level may cause denial of
service for all other receivers of the merged reservation.
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 recommended merging strategy when reservation homogeneity
is coordinated and enforced for the entire multicast tree. It is
more restrictive than Section 5.1.1, but is easier to implement.
5.2 Modifying Priority Elements
When POLICY_DATA objects are protected by integrity, LDPs should not
attempt to modify them. They must be forwarded as-is or else their
security envelope would be invalidated. In other cases, LDPs may
modify and merge incoming PREEMPTION_PRI elements to reduce their
size and number according to the following rule:
Merging is performed for each merging strategy separately.
There is no known algorithm to merge PREEMPTION_PRI element of
different merging strategies without loosing valuable information
that may affect OTHER nodes.
- For each merging strategy, the highest QoS of all participating
PREEMPTION_PRI elements is taken and is placed in an outgoing
PREEMPTION_PRI element of this merging strategy.
- This approach effectively compresses the number of forwarded
PREEMPTION_PRI elements to at most to the number of different
merging strategies, regardless of the number of receivers (See the
example in Appendix A.2).
6 Error Processing
A PREEMPTION_PRI error object is sent back toward the appropriate
receivers when an error involving PREEMPTION_PRI elements occur.
PREEMPTION
When a previously admitted flow is preempted, a copy of the
preempting flow's PREEMPTION_PRI element is sent back toward the PDP
that originated the preempted PREEMPTION_PRI object. This PDP,
having information on both the preempting and the preempted
priorities may construct a higher priority PREEMPTION_PRI element in
an effort to re-instate the preempted flow.
Heterogeneity
When a flow F1 with Heterogeneous Error merging strategy set in its
PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI
element is 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, as any other policy
element, by the encapsulation into a Policy Data object [RSVP-EXT].
Further security mechanisms are not warranted, especially considering
that preemption priority aims to provide simple and quick guidance to
routers within a trusted zone or at least a single zone (no zone
boundaries are crossed).
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 describe the computation of merged priority
elements as well as the translation (compression) of PREEMPTION_PRI
elements.
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 describes a multicast scenario with one sender and four
receivers each with each own PREEMPTION_PRI element definition.
r1, r2 and r3 merge in B. The resulting priority is 4.
Reason: The PREEMPTION_PRI of r3 doesn't participate (since r3 is not
contributing to the merged QoS) and 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 the
other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to
r4 telling it that its PREEMPTION_PRI element encountered
heterogeneity.
A.2 Translation (Compression) of Priority Elements
Given this set of participating PREEMPTION_PRI elements, the
following compression can take place at the merging node:
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)
Full Copyright Statement
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.
ISO Plain Language
On this page
§1Introduction
This document describes a preemption priority policy element for use by signaled policy-based admission protocols such as RSVP and COPS.
Traditional capacity-based admission control indiscriminately admits new flows until capacity is exhausted, admitting the first that arrive. Policy-based admission control tries to reduce the significance of the order of arrival and uses policy-based admission criteria instead. One of the more popular policy criteria is the rank of importance of a flow relative to the others competing for admission into a network node.
Preemption priority takes effect only when the flows attempting admission through a node overbook the resources, so that capacity-based admission control would have to reject some of them. The priority criterion then helps the node select the most important flows, those with the highest priority, for admission, while rejecting the low priority ones. Network nodes that support preemption should consider preempting previously admitted low-priority flows to make room for a newer, high-priority flow.
Admission control is the decision about which new traffic a node accepts when it is already full. The usual rule is first come, first served, which says nothing about which traffic matters more. This document adds a number to each request that says how important it is, so the node can keep the important traffic and drop the rest.
§2Scope and Applicability
The framework document for policy-based admission control describes the components that take part in policy decision making: the PDP, the PEP and the LDP. The emphasis on PREEMPTION_PRI elements is that they be simple, stateless and light-weight, so that they could be implemented inside a node's local decision point.
Three assumptions shape how the elements are used. They are created by policy decision points. In a model where the PDP controls the PEPs at the edge of the policy domain, such as in border routers, the PDP reduces the relevant sets of policy rules to a single priority criterion, and that priority, expressed in the PREEMPTION_PRI element, is then communicated to the downstream PEPs of the same policy domain, which have local decision points but no controlling PDP.
They can be processed by local decision points. An LDP may interpret the objects, forward them as they are, or perform local merging to forward an equivalent merged element. LDPs must follow the merging strategy that the PDP encoded in the objects. A PDP, being a superset of an LDP, may act as an LDP as well.
They are enforced by policy enforcement points. The elements interact with the node's traffic control module, and with capacity admission control, to enforce the priorities and to preempt previously admitted flows when the need arises.
Three kinds of component are involved. A policy decision point works out how important a flow is and puts the number into the message. A local decision point in the middle of the network merges the numbers of the flows it combines, following the rule the decision point chose. A policy enforcement point is the router that admits or rejects the traffic and, when needed, preempts a lower priority flow that is already running.
§3Stateless Policy
Signaled preemption priority is stateless: it does not require past history or external information to be interpreted. When it is carried in COPS messages for the outsourcing of policy decisions, the objects are therefore included as COPS Stateless Policy Data Decision objects.
The priority number travels with the request and stands on its own. Nothing has to be remembered about earlier flows for it to be understood, which is what lets it be carried in a COPS message without any extra bookkeeping.
§4Policy Element Format
The format of Policy Data objects is defined in the RSVP extensions document, and a single Policy Data object may contain one or more policy elements, each representing a different and perhaps orthogonal policy. The preemption priority policy element is 12 octets long and carries a length, a policy type, some flags, a merging strategy, an error code, and the two priorities.
The length is 16 bits and is always 12, the length of the element in bytes. The P-Type is 16 bits and is 1 for PREEMPTION_PRI, a value registered with IANA. The flags field is 8 bits and is reserved, always zero. The merge strategy is 8 bits: 1 for taking the priority of the highest quality of service, which is recommended; 2 for taking the highest priority, which is described as aggressive; and 3 for forcing an error on a heterogeneous merge. The error code is 8 bits: 0 for NO_ERROR, the value used in a regular element; 1 for PREEMPTION, meaning a previously admitted flow was preempted; and 2 for HETEROGENEOUS, meaning the element met a heterogeneous merge. A final reserved octet is always zero.
The preemption priority is 16 bits and unsigned. It is the priority of the new flow compared with the defending priority of previously admitted flows, and higher values mean higher priority. The defending priority is also 16 bits and unsigned. Once a flow has been admitted, its preemption priority is irrelevant, and its defending priority is used to compare with the preemption priority of new flows. For any specific flow, the preemption priority must always be less than or equal to the defending priority. A wide gap between the two provides extra stability: a moderate preemption priority makes it harder for a flow to preempt others, but once it has succeeded, the higher defending priority makes it easier for the flow to avoid being preempted itself. That is the mechanism for balancing order dependency against priority.
The element is 12 bytes. It carries two 16-bit numbers. The first is used when a flow asks to be admitted, and the second once it has been admitted: the second is the priority the flow defends itself with. The flow may ask for less priority than it defends, and the gap between the two is what stops a flow from being knocked out as soon as it has knocked something else out.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
LENGTH | Length | 2 bytes | 12 | Always 12, the length of the element in bytes. |
P-TYPE | P-Type | 2 bytes | 1 | 1 for PREEMPTION_PRI. |
FLAGS | Flags | 1 byte | Reserved, always 0. | |
MERGE-STRATEGY | M. Strategy | 1 byte | 1 takes the priority of the highest QoS, 2 takes the highest priority, 3 forces an error on a heterogeneous merge. | |
ERROR-CODE | Error Code | 1 byte | 0 no error, 1 a flow was preempted, 2 a heterogeneous merge was met. | |
RESERVED | Reserved | 1 byte | Always 0. | |
PREEMPTION-PRIORITY | Preemption Priority | 2 bytes | The priority of the new flow, compared with the defending priority of admitted flows. Higher is more important. | |
DEFENDING-PRIORITY | Defending Priority | 2 bytes | The priority an admitted flow defends itself with. Never lower than the preemption priority of the same flow. |
- 1Merge strategy — Take priority of highest QoS. Recommended.
- 2Merge strategy — Take highest priority. Aggressive.
- 3Merge strategy — Force error on heterogeneous merge.
- 0Error code — NO_ERROR, the value used for a regular element.
- 1Error code — PREEMPTION: a previously admitted flow was preempted.
- 2Error code — HETEROGENEOUS: the element met a heterogeneous merge.
§5Priority Merging Issues
Consider two RSVP reservations that merge. F1 has a high quality of service and a low priority, and F2 has a low quality of service and a high priority. The merged reservation F3 should have the high quality of service, but what priority should it take? The document identifies three kinds of unwanted effect.
The free-rider problem arises if F3 takes the high priority: F1 then got a free ride, assuming a high priority that was only intended for the low quality of service F2. If cost is a function of quality of service and priority, F1 receives an expensive priority without having to pay for it. Denial of service is the inverse, and arises if F3 takes the low priority: the merged flow could be preempted or fail even though F2 presented a high priority. One free-rider turns out to be another's denial of service. Instability comes from the combination of preemption priority, the killer reservation and the blockade state, which may increase the instability of admitted flows, where a reservation is preempted, reinstated and preempted again periodically.
In a merging situation a local decision point may receive several preemption elements and must compute the priority of the merged flow. Preemption priority and defending priority are merged and computed separately, irrespective of each other. All the priority elements are examined according to their merging strategy to decide whether they should take part, and the highest priority of all the participating elements is the result.
Three strategies are defined. Take priority of highest QoS: the element takes part only if its flow contributed to the merged quality of service, that is, if its quality of service requirement is not a subset of another reservation. A simple way to tell is to compute the merged quality of service with and without it and compare. The reasoning is that the highest quality of service flow dominates the merged reservation, so its priority should dominate it too, and this approach is the most amenable to preventing priority distortions such as free-riders and denial of service. It is a recommended strategy.
Take highest priority: every element takes part. This disassociates priority from the quality of service level and is therefore highly subject to free-riders and to denial of service, the inverse image. It is not a recommended method, but it may be simpler to implement. Force error on heterogeneous merge: an element may take part only if all the other flows in the merged reservation have the same quality of service level. The reasoning is that the heterogeneous case is relatively rare and too complicated to deal with, so it is better prohibited, though this strategy lends itself to denial of service, when a single receiver specifying a non-compatible quality of service level may cause denial of service for all the other receivers. It is a recommended strategy when reservation homogeneity is coordinated and enforced for the whole multicast tree, and it is more restrictive than the first strategy but easier to implement. The determination of heterogeneous flows applies to the quality of service level only, that is, the FLOWSPEC values, and is a matter for local definition.
The document also says how elements may be modified on the way. When Policy Data objects are protected by integrity, LDPs should not modify them, and must forward them as they are or the security envelope would be invalidated. In other cases LDPs may modify and merge the incoming elements to reduce their size and number. Merging is performed for each merging strategy separately, because there is no known algorithm to merge elements of different strategies without losing information that may affect other nodes. For each strategy, the highest quality of service of all the participating elements is taken and placed in an outgoing element of that strategy, which compresses the number of forwarded elements to at most the number of different merging strategies, whatever the number of receivers.
When two requests are joined, the combined request has to end up with one priority, and either choice can be unfair. The document offers three rules. The recommended one keeps only the priorities of the requests that actually set the combined service level, so a high service level does not drag a high priority along with it. The simplest rule takes the highest priority of all the requests, and is open to both kinds of unfairness. The third refuses to merge requests whose service levels differ.
- Take priority of highest QoSOnly the elements of the flows that set the merged service level take part. Recommended.
- Take highest priorityEvery element takes part, whatever the service level. Simpler, but open to free-riders.
- Force error on heterogeneous mergeOnly elements whose flows all have the same service level take part; otherwise an error is reported.
- Free-riderThe merged flow takes the high priority of one leg, so that leg gets a priority it never paid for.
- Denial of serviceThe merged flow takes the low priority, so a flow that presented high priority can still be dropped.
- InstabilityA reservation is preempted, reinstated and preempted again, over and over.
§6Error Processing
A PREEMPTION_PRI error object is sent back toward the appropriate receivers when an error involving PREEMPTION_PRI elements occurs.
With the PREEMPTION error, a previously admitted flow has been preempted. A copy of the preempting flow's PREEMPTION_PRI element is sent back toward the PDP that originated the preempted object. That PDP has information on both the preempting and the preempted priorities, and may construct a higher priority element in an effort to re-instate the preempted flow.
With the Heterogeneity error, a flow that has the heterogeneous error merging strategy set in its element meets heterogeneity, and the element is sent back toward the receivers with the heterogeneity error code set.
Two things are reported back. When a running flow is knocked out, the decision point that asked for it is told, with the details of the flow that took its place, so that it can ask for a better priority and get the flow back. When a merge turns out to be of the kind a flow said it could not handle, that flow's element is sent back with the error code set.
§8Security Considerations
The integrity of PREEMPTION_PRI is guaranteed, as for any other policy element, by its encapsulation into a Policy Data object.
Further security mechanisms are not warranted, especially since preemption priority aims to give simple and quick guidance to routers within a trusted zone, or at least a single zone, and no zone boundaries are crossed.
The element inherits whatever protection the surrounding policy data object has, and the document asks for nothing more: the priority is meant to guide routers inside one trusted area, where an attacker has no business being.