rfc2751.txt

RFC 的详细文档！

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]