Admission Priority Policy Element      October 2005



   Internet Draft                                  Francois Le Faucheur
                                                             James Polk
                                                    Cisco Systems, Inc.


   draft-lefaucheur-emergency-rsvp-00.txt
   Expires: March 2006                                     October 2005


      RSVP Admission Priority Policy Element for Emergency Services



Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and  may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
       http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
       http://www.ietf.org/shadow.html.




Abstract

   An Emergency Telecommunications Service (ETS) requires the ability to
   provide an elevated probability of call completion to an authorized
   user in times of crisis. When supported over the Internet Protocol
   suite, this may be achieved through an admission control solution
   which supports call preemption capabilities as well as admission
   priority capabilities, whereby some resources (e.g. bandwidth) are
   reserved for emergency services only.



Le Faucheur, et al.                                          [Page 1]


                  Admission Priority Policy Element      October 2005


   This document specifies RSVP extensions necessary for supporting such
   admission priority capabilities.


Copyright Notice
      Copyright (C) The Internet Society. (2005)


Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


1.  Introduction

   [EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency
   Telecommunications Service (ETS). The key requirement is to guarantee
   superior probability of call completion from an authorized user in
   times of crisis. To that end, some of these types of services require
   that the network be capable of preempting calls; others do not
   involve preemption but instead rely on another network mechanism
   which we refer throughout this document as "admission priority"
   whereby some resources (e.g. bandwidth) is set aside for the
   emergency services only, in order to obtain a high probability of
   call completion for those.

   [EMERG-IMP] describes the call and admission control procedures (at
   initial call set up, as well as after call establishment through
   maintenance of a continuing call model of the status of all calls)
   which allow support of an Emergency Telecommunications Service.
   [EMERG-IMP] also describes how these call and admission control
   procedures can be realized using the Resource reSerVation Protocol
   [RSVP] along with its associated protocol suite and extensions,
   including those for policy based admission control ([FW-POLICY],
   [RSVP-POLICY]), for user authentication and authorization ([RSVP-ID])
   and for integrity and authentication of RSVP messages ([RSVP-CRYPTO-
   1], [RSVP-CRYPTO-2]).

   Furthermore, [EMERG-IMP] describes how the RSVP Signaled Preemption
   Priority Policy Element specified in [RSVP-PREEMP] can be used to
   enforce the call preemption needed by some services of the ETS.

   This document specifies RSVP extensions which can be used to enforce
   the "admission priority" required by other services of the ETS.

1.1. Changes from previous versions



Le Faucheur, et al.                                          [Page 2]


                  Admission Priority Policy Element      October 2005


      This is the initial version of the document


2.  Overview of RSVP extensions and Operations

   Let us consider the case where a call requiring Internet Emergency
   Preference Service is to be established, and more specifically that
   the preference to be granted to this call is in terms of admission
   priority (i.e. by allowing that call to seize resources that have
   been set-aside and not made available to normal calls) and that the
   preference to be granted to this new call does not involve preempting
   existing calls.

   As described in [EMERG-IMP], the session establishment can be
   conditioned to resource-based and policy-based admission control
   achieved via RSVP signaling. In the case where the session control
   protocol is SIP, the use of RSVP-based admission control by SIP is
   specified in [SIP-RESOURCE].

   Devices involved in the session establishment are expected to be
   aware of the priority requirements of emergency calls. Again, in the
   case where the session control protocol is SIP, the SIP user agents
   can be aware of the resource priority requirements in the case of an
   emergency call using mechanisms specified in [SIP-PRIORITY].

   Where, as per our considered case, the priority requirement of the
   emergency call involves admission priority, the devices involved in
   the session establishment simply need to map the priority
   requirements of the emergency call into an RSVP "admission priority"
   level and convey this information in the relevant RSVP messages used
   for admission control. The admission priority is encoded inside the
   new Admission Priority Policy Element defined in this document. This
   way, the RSVP-based admission control can take this information into
   account at every RSVP-enabled network hop.

   Note that this operates in a very similar manner to the case where
   the priority requirement of the emergency call involves preemption
   priority. In that case, the devices involved in the session
   establishment map the emergency call requirement into an RSVP
   "preemption priority" level (or more accurately into both a setup
   preemption level and a defending preemption priority level) and
   convey this information in the relevant RSVP messages used for
   admission control. This preemption priority information is encoded
   inside the Preemption Priority Policy Element of [RSVP-PREEMP] and
   thus, can be taken into account at every RSVP-enabled network hop.

2.1.  Operations of Admission Priority




Le Faucheur, et al.                                          [Page 3]


                  Admission Priority Policy Element      October 2005


   The RSVP admission priority defined in this document allows admission
   bandwidth to be allocated for use by an authorized priority service.
   Multiple models of bandwidth allocation MAY be used to that end.
   However, the bandwidth allocation model MUST ensure that it is
   possible to limit admission of non-priority traffic [Respectively,
   lower priority traffic] to a maximum bandwidth which can be
   configured below the link capacity (or below the bandwidth granted by
   the scheduler to the relevant Diffserv PHB) thereby ensuring that
   some capacity is effectively set aside for admission of priority
   traffic [Respectively, higher priority traffic].

   A number of bandwidth allocation models have been defined in the IETF
   for allocation of bandwidth across different classes of traffic
   trunks in the context of Diffserv-aware MPLS Traffic Engineering.
   Those include the Maximum Allocation Model (MAM) defined in [DSTE-
   MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These
   same models MAY however be applied for allocation of bandwidth across
   different levels of admission priority as defined in this document.
   This section illustrates how MAM and RDM can indeed be used for
   support of admission priority. For simplicity, operations with only a
   single "priority" level (beyond non-priority) is illustrated here;
   However, the reader will appreciate that operations with multiple
   priority levels can easily be supported with these models.

   In all the charts below:
      x represents a non-priority session
      o represents a priority session


2.1.1.
      Illustration of Admission Priority with Maximum Allocation Model

   This section illustrates operations of admission priority when a
   Maximum Allocation Model is used for bandwidth allocation across non-
   priority traffic and priority traffic. A property of the Maximum
   Allocation Model is that priority traffic can not use more than the
   bandwidth reserved for priority traffic (even if the non-priority
   traffic is not using all of the bandwidth available for it).

              -----------------------
               ^  |              |  ^
               .  |              |  .
      Total    .  |              |  .   Bandwidth
               .  |              |  .   Available
      Avail    .  |              |  .   for non-priority use
               .  |              |  .
      BW       .  |              |  .
               .  |              |  .
               .  |              |  v
               .  |--------------| ---


Le Faucheur, et al.                                          [Page 4]


                  Admission Priority Policy Element      October 2005


               .  |              |  ^
               .  |              |  .   Bandwidth reserved for
               v  |              |  v   priority use
             -------------------------

           Chart 1. Overall Link Capacity

   Chart 1 shows a link within a routed network conforming to this
   document.  On this link are two amounts of bandwidth available to two
   types of traffic: non-priority and priority.  The aggregate of the
   two amounts equals the total link capacity (or the total capacity
   granted to the corresponding Diffserv Per Hop Behavior).
   If the non-priority traffic load reaches the maximum bandwidth
   available for non-priority, no additional non-priority sessions can
   be accepted even if the bandwidth reserved for priority traffic is
   not currently utilized.

   With the Maximum Allocation Model, in the case where the priority
   load reaches the maximum bandwidth reserved for priority calls, no
   additional priority sessions can be accepted.

   Chart 2 shows some of the non-priority capacity of this link being
   used.

               ----------------------
               ^  |              |  ^
               .  |              |  .
      Total    .  |              |  .   Bandwidth
               .  |              |  .   Available
      Avail    .  |xxxxxxxxxxxxxx|  .   for non-priority use
               .  |xxxxxxxxxxxxxx|  .
      BW       .  |xxxxxxxxxxxxxx|  .
               .  |xxxxxxxxxxxxxx|  .
               .  |xxxxxxxxxxxxxx|  v
               .  |--------------| ---
               .  |              |  ^
               .  |              |  .   Bandwidth reserved for
               v  |              |  v_  priority use
                ----------------------

           Chart 2. Partial load of non-priority calls


   Chart 3 shows the same amount of non-priority load being used at this
   link, and a small amount of priority bandwidth being used.

               ----------------------
               ^  |              |  ^
               .  |              |  .


Le Faucheur, et al.                                          [Page 5]


                  Admission Priority Policy Element      October 2005


      Total    .  |              |  .   Bandwidth
               .  |              |  .   Available
      Avail    .  |xxxxxxxxxxxxxx|  .   for non-priority use
               .  |xxxxxxxxxxxxxx|  .
      BW       .  |xxxxxxxxxxxxxx|  .
               .  |xxxxxxxxxxxxxx|  .
               .  |xxxxxxxxxxxxxx|  v
               .  |--------------| ---
               .  |              |  ^
               .  |              |  .   Bandwidth reserved for
               v  |oooooooooooooo|  v   priority use
               ----------------------

           Chart 3. Partial load of non-priority calls
                    & partial load of priority calls


   Chart 4 shows the case where non-priority load equates or exceeds the
   maximum bandwidth available to non-priority traffic. Note that
   additional non-priority sessions would be rejected even if the
   bandwidth reserved for priority sessions is not fully utilized.

                ----------------------
               ^  |xxxxxxxxxxxxxx|  ^
               .  |xxxxxxxxxxxxxx|  .
      Total    .  |xxxxxxxxxxxxxx|  .   Bandwidth
               .  |xxxxxxxxxxxxxx|  .   Available
      Avail    .  |xxxxxxxxxxxxxx|  .   for non-priority use
               .  |xxxxxxxxxxxxxx|  .
      BW       .  |xxxxxxxxxxxxxx|  .
               .  |xxxxxxxxxxxxxx|  .
               .  |xxxxxxxxxxxxxx|  v
               .  |--------------| ---
               .  |              |  ^
               .  |              |  .   Bandwidth reserved for
               v  |oooooooooooooo|  v   priority use
               ----------------------

           Chart 4. Full non-priority load
                    & partial load of priority calls


   Although this is not expected to occur in practice because of proper
   allocation of bandwidth to priority traffic, for completeness Chart 5
   shows the case where there priority traffic equates or exceeds the
   bandwidth reserved for such priority traffic.
   In that case additional priority sessions could not be accepted. They
   may be handled by mechanisms which are beyond the scope of this
   particular document (such as established through preemption of


Le Faucheur, et al.                                          [Page 6]


                  Admission Priority Policy Element      October 2005


   existing non-priority sessions, or new priority session requests
   could be queues until capacity becomes available again for priority
   traffic).

               ----------------------
               ^  |xxxxxxxxxxxxxx|  ^
               .  |xxxxxxxxxxxxxx|  .
      Total    .  |xxxxxxxxxxxxxx|  .   Bandwidth
               .  |xxxxxxxxxxxxxx|  .   Available
      Avail    .  |xxxxxxxxxxxxxx|  .   for non-priority use
               .  |xxxxxxxxxxxxxx|  .
      BW       .  |xxxxxxxxxxxxxx|  .
               .  |              |  .
               .  |              |  v
               .  |--------------| ---
               .  |oooooooooooooo|  ^
               .  |oooooooooooooo|  .   Bandwidth reserved for
               v  |oooooooooooooo|  v   priority use
               ----------------------

           Chart 5. Partial non-priority load & Full priority load


2.1.2.
      Illustration of Admission Priority with Russian Dolls Model

   This section illustrates operations of admission priority when a
   Russian Dolls Model is used for bandwidth allocation across non-
   priority traffic and priority traffic. A property of the Russian
   Dolls Model is that priority traffic can use the bandwidth which is
   not currently used by non-priority traffic.

   Chart 6 shows the case where only some of the bandwidth available to
   non-priority traffic is being used and a small amount of priority
   traffic is in place. In that situation both new non-priority sessions
   and new priority sessions would be accepted.

               --------------------------------------
               |xxxxxxxxxxxxxx|  .                 ^
               |xxxxxxxxxxxxxx|  . Bandwidth       .
               |xxxxxxxxxxxxxx|  . Available for   .
               |xxxxxxxxxxxxxx|  . non-priority    .
               |xxxxxxxxxxxxxx|  . use             .
               |xxxxxxxxxxxxxx|  .                 . Bandwidth
               |              |  .                 . available for
               |              |  v                 . non-priority
               |--------------| ---                . and priority
               |              |                    . use
               |              |                    .
               |oooooooooooooo|                    v


Le Faucheur, et al.                                          [Page 7]


                  Admission Priority Policy Element      October 2005


               ---------------------------------------

           Chart 6. Partial non-priority load & Partial Aggregate load


   Chart 7 shows the case where all of the bandwidth available to non-
   priority traffic is being used and a small amount of priority traffic
   is in place. In that situation new priority sessions would be
   accepted but new non-priority sessions would be rejected.

               --------------------------------------
               |xxxxxxxxxxxxxx|  .                 ^
               |xxxxxxxxxxxxxx|  . Bandwidth       .
               |xxxxxxxxxxxxxx|  . Available for   .
               |xxxxxxxxxxxxxx|  . non-priority    .
               |xxxxxxxxxxxxxx|  . use             .
               |xxxxxxxxxxxxxx|  .                 . Bandwidth
               |xxxxxxxxxxxxxx|  .                 . available for
               |xxxxxxxxxxxxxx|  v                 . non-priority
               |--------------| ---                . and priority
               |              |                    . use
               |              |                    .
               |oooooooooooooo|                    v
               ---------------------------------------

           Chart 7. Full non-priority load & Partial Aggregate load


   Chart 8 shows the case where only some of the bandwidth available to
   non-priority traffic is being used and a heavy load of priority
   traffic is in place. In that situation both new non-priority sessions
   and new priority sessions would be accepted.
   Note that, as illustrated in Chart 7, priority calls use some of the
   bandwidth currently not used by non-priority traffic.

               --------------------------------------
               |xxxxxxxxxxxxxx|  .                 ^
               |xxxxxxxxxxxxxx|  . Bandwidth       .
               |xxxxxxxxxxxxxx|  . Available for   .
               |xxxxxxxxxxxxxx|  . non-priority    .
               |xxxxxxxxxxxxxx|  . use             .
               |              |  .                 . Bandwidth
               |              |  .                 . available for
               |oooooooooooooo|  v                 . non-priority
               |--------------| ---                . and priority
               |oooooooooooooo|                    . use
               |oooooooooooooo|                    .
               |oooooooooooooo|                    v
               ---------------------------------------


Le Faucheur, et al.                                          [Page 8]


                  Admission Priority Policy Element      October 2005



           Chart 8. Partial non-priority load & Heavy Aggregate load


   Chart 9 shows the case where all of the bandwidth available to non-
   priority traffic is being used and all of the remaining available
   bandwidth is used by priority traffic. In that situation new non-
   priority sessions would be rejected. In that situation new priority
   sessions could not be accepted right away. Those priority sessions
   may be handled by mechanisms which are beyond the scope of this
   particular document (such as established through preemption of
   existing non-priority sessions, or new priority session requests
   could be queues until capacity becomes available again for priority
   traffic). This is not expected to occur in practice because of proper
   allocation of bandwidth to priority traffic (or more precisely
   because of proper sizing of the difference in bandwidth allocated to
   non-priority traffic and bandwidth allocated to non-priority &
   priority traffic).

               --------------------------------------
               |xxxxxxxxxxxxxx|  .                 ^
               |xxxxxxxxxxxxxx|  . Bandwidth       .
               |xxxxxxxxxxxxxx|  . Available for   .
               |xxxxxxxxxxxxxx|  . non-priority    .
               |xxxxxxxxxxxxxx|  . use             .
               |xxxxxxxxxxxxxx|  .                 . Bandwidth
               |xxxxxxxxxxxxxx|  .                 . available for
               |xxxxxxxxxxxxxx|  v                 . non-priority
               |--------------| ---                . and priority
               |oooooooooooooo|                    . use
               |oooooooooooooo|                    .
               |oooooooooooooo|                    v
               ---------------------------------------

           Chart 8. Full non-priority load & Full Aggregate load


3.  Admission Priority Policy Element

   [RSVP-POLICY] defines extensions for supporting generic policy based
   admission control in RSVP. These extensions include the standard
   format of POLICY_DATA objects and a description of RSVP handling of
   policy events.

   The POLICY_DATA object contains one or more of Policy Elements, each
   representing a different (and perhaps orthogonal) policy. As an
   example [RSVP-PREEMP] specifies the Preemption Priority Policy
   Element.



Le Faucheur, et al.                                          [Page 9]


                  Admission Priority Policy Element      October 2005


   This document defines a new Policy Element called the Admission
   Priority Policy Element.

   The format of Admission Priority policy element is as follows:

         +-------------+-------------+-------------+-------------+
         | Length (12)               | P-Type = ADMISSION_PRI    |
         +-------------+-------------+-------------+-------------+
         | Flags       | M. Strategy | Error Code  | Reserved(0) |
         +-------------+-------------+-------------+-------------+
         | Admission  Priority       | Reserved (0)              |
         +---------------------------+---------------------------+


   Length: 16 bits
      Always 12. The overall length of the policy element, in bytes.

   P-Type: 16 bits
       ADMISSION_PRI  = To be allocated by IANA
      (see "IANA Considerations" section)

   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

   Error code: 8 bits
       0  NO_ERROR        Value used for regular ADMISSION_PRI elements
       2  HETEROGENEOUS   This element encountered heterogeneous merge

   Reserved: 8 bits
       Always 0.

   Admission Priority: 16 bit (unsigned)
       The admission control priority of the flow, in terms of access
       to resources set aside in order to provide higher probability of
       call completion to selected flows. Higher values represent
       higher Priority. A reservation established without an Admission
       Priority policy element is equivalent to a reservation
       established with an Admission Priority policy element whose
       Admission Priority value is 0.

   Reserved: 16 bits
       Always 0.




Le Faucheur, et al.                                         [Page 10]


                  Admission Priority Policy Element      October 2005


4.  Admission Priority Merging Rules

   This session discusses alternatives for dealing with RSVP admission
   priority in case of merging of reservations. As merging is only
   applicable to multicast, this section also only applies to multicast
   sessions.

4.1.  Admission Priority Merging Strategies

   In merging situations Local Decision Points (LDPs) may receive
   multiple preemption elements and must compute the admission priority
   of the merged flow according to the following rules:

       a. Participating admission priority elements are selected.
   All admission priority elements are examined according to their
   merging strategy to decide whether they should participate in the
   merged result (as specified below).

       b. The highest admission priority of all participating admission
   priority elements is computed.

   The remainder of this section describes the different merging
   strategies the can be specified in the ADMISSION_PRI element.

4.1.1.
      Take priority of highest QoS

   The ADMISSION_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 of
   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.

4.1.2.
      Take highest priority

   All ADMISSION_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.

4.1.3.
      Force error on heterogeneous merge

   A ADMISSION_PRI element may participate in a merged reservation only


Le Faucheur, et al.                                         [Page 11]


                  Admission Priority Policy Element      October 2005


   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
   ADMISSION_PRI element.

4.2.  Modifying Admission 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 ADMISSION _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 ADMISSION_PRI element of
   different merging strategies without losing valuable information that
   may affect OTHER nodes.

      -  For each merging strategy, the highest QoS of all participating
         ADMISSION _PRI elements is taken and is placed in an outgoing
         ADMISSION _PRI element of this merging strategy.

      -  This approach effectively compresses the number of forwarded
         ADMISSION _PRI elements to at most to the number of different
         merging strategies, regardless of the number of receivers.


5.  Error Processing

   An Error Code is sent back (inside the Admission Priority Policy
   Element) toward the appropriate receivers when an error involving
   ADMISSION_PRI elements occur.

      Heterogeneity




Le Faucheur, et al.                                         [Page 12]


                  Admission Priority Policy Element      October 2005


      When a flow F1 with "Force Error on heterogeneous merge" merging
      strategy set in its ADMISSION_PRI element encounters
      heterogeneity, the ADMISSION_PRI element is sent back toward
      receivers with the Heterogeneity error code set.


6.  Security Considerations

   The integrity of ADMISSION_PRI is guaranteed, as any other policy
   element, by the encapsulation into a Policy Data object [RSVP-POLICY].


7.  IANA Considerations

   As specified in [POLICY-RSVP], Standard RSVP Policy Elements (P-type
   values) are to be assigned by IANA as per "IETF Consensus" following
   the policies outlined in [IANA-CONSIDERATIONS].

   IANA needs to allocate a P-Type from the Standard RSVP Policy Element
   range to the Admission Priority Policy Element.


8.  Acknowledgments

   We would like to thank An Nguyen for his encouragement to address
   this topic and comments. Also, this document borrows heavily from
   some of the work of S. Herzog on Preemption Priority Policy Element
   [RSVP-PREEMP].


9.  Normative References

   [EMERG-RQTS]  Carlberg, K. and R. Atkinson, "General Requirements for
   Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.

   [EMERG-TEL]  Carlberg, K. and R. Atkinson, "IP Telephony Requirements
   for Emergency Telecommunication Service (ETS)", RFC 3690, February
   2004.

   [EMERG-IMP] F. Baker & J. Polk, Implementing an Emergency
   Telecommunications Service for Real Time Services in the Internet
   Protocol Suite, draft-ietf-tsvwg-mlpp-that-works-02, Work in Progress

   [RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol
   (RSVP)- Functional Specification", RFC 2205, September 1997.

   [FW-POLICY]  Yavatkar, R., Pendarakis, D., and R. Guerin, "A
   Framework for Policy-based Admission Control", RFC 2753, January 2000.



Le Faucheur, et al.                                         [Page 13]


                  Admission Priority Policy Element      October 2005


   [RSVP-POLICY]  Herzog, S., "RSVP Extensions for Policy Control", RFC
   2750, January 2000.

   [RSVP-PREEMP]  Herzog, S., "Signaled Preemption Priority Policy
   Element", RFC 3181, October 2001.

   [DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth
   Constraints Model for Diffserv-aware MPLS Traffic Engineering",
   RFC 4125, June 2005.

   [DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints
   Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June
   2005


10.  Informative References

   [RSVP-ID]  Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
   Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182,
   October 2001.

   [RSVP-CRYPTO-1]  Baker, F., Lindell, B., and M. Talwar, "RSVP
   Cryptographic Authentication", RFC 2747, January 2000.

   [RSVP-CRYPTO-2]  Braden, R. and L. Zhang, "RSVP Cryptographic
   Authentication -- Updated Message Type Value", RFC 3097, April 2001.

   [SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg,
   "Integration of Resource Management and Session Initiation Protocol
   (SIP)", RFC 3312, October 2002.

   [SIP-PRIORITY] H. Schulzrinne & J. Polk. Communications Resource
   Priority for the Session Initiation Protocol (SIP), draft-ietf-sip-
   resource-priority-10, work in progress


11.  Authors Address:

   Francois Le Faucheur
   Cisco Systems, Inc.
   Village d'Entreprise Green Side - Batiment T3
   400, Avenue de Roumanille
   06410 Biot Sophia-Antipolis
   France
   Email: flefauch@cisco.com

   James Polk
   Cisco Systems, Inc.
   2200 East President George Bush Turnpike


Le Faucheur, et al.                                         [Page 14]


                  Admission Priority Policy Element      October 2005


   Richardson, Texas  75082
   USA
   Email: jmpolk@cisco.com


12.  IPR Statements

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.
   Please address the information to the IETF at ietf-ipr@ietf.org.


13.  Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


14.  Copyright Notice

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.





Le Faucheur, et al.                                         [Page 15]