GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2751

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:
  1. 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.
  1. 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).
  1. 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

  1. 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.
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2751.txt · Last modified: 2000/01/21 17:36 (external edit)