rfc2751.txt

RFC 的详细文档！


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: [phone]
   EMail: [e-mail]
















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]