summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2751.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2751.txt')
-rw-r--r--doc/rfc/rfc2751.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc2751.txt b/doc/rfc/rfc2751.txt
new file mode 100644
index 0000000..b3329f7
--- /dev/null
+++ b/doc/rfc/rfc2751.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group S. Herzog
+Request for Comments: 2751 IPHighway
+Category: Standards Track January 2000
+
+
+ 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 (2000). All Rights Reserved.
+
+Abstract
+
+ This document describes a preemption priority policy element for use
+ by signaled policy based admission protocols (such as [RSVP] and
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herzog Standards Track [Page 1]
+
+RFC 2751 Signaled Preemption Priority Policy Element January 2000
+
+
+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 Information .............................................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
+
+ 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].
+
+
+
+
+
+
+Herzog Standards Track [Page 2]
+
+RFC 2751 Signaled Preemption Priority Policy Element January 2000
+
+
+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 [COSP, COPS-RSVP]).
+
+
+
+
+
+
+
+Herzog Standards Track [Page 3]
+
+RFC 2751 Signaled Preemption Priority Policy Element January 2000
+
+
+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 = 3
+
+ 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.
+
+
+
+
+
+
+Herzog Standards Track [Page 4]
+
+RFC 2751 Signaled Preemption Priority Policy Element January 2000
+
+
+ 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).
+
+
+
+
+
+
+
+
+Herzog Standards Track [Page 5]
+
+RFC 2751 Signaled Preemption Priority Policy Element January 2000
+
+
+ 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.
+
+
+
+
+
+
+Herzog Standards Track [Page 6]
+
+RFC 2751 Signaled Preemption Priority Policy Element January 2000
+
+
+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.
+
+
+
+
+Herzog Standards Track [Page 7]
+
+RFC 2751 Signaled Preemption Priority Policy Element January 2000
+
+
+ - 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 3.
+
+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).
+
+
+
+
+Herzog Standards Track [Page 8]
+
+RFC 2751 Signaled Preemption Priority Policy Element January 2000
+
+
+9 References
+
+ [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., et al., "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., ed., et al., "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 Information
+
+ Shai Herzog
+ IPHighway, Inc.
+ 55 New York Avenue
+ Framingham, MA 01701
+
+ Phone: (508) 620-1141
+ EMail: herzog@iphighway.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herzog Standards Track [Page 9]
+
+RFC 2751 Signaled Preemption Priority Policy Element January 2000
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herzog Standards Track [Page 10]
+
+RFC 2751 Signaled Preemption Priority Policy Element January 2000
+
+
+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)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herzog Standards Track [Page 11]
+
+RFC 2751 Signaled Preemption Priority Policy Element January 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herzog Standards Track [Page 12]
+