[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

                RSVP Extensions for Emergency Services      March 2006



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

                                                           Ken Carlberg
                                                                   G11


   draft-lefaucheur-emergency-rsvp-01.txt
   Expires: March 2006                                    February 2006


                  RSVP Extensions 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 network congestion (typically, during a crisis).
   When supported over the Internet Protocol suite, this may be achieved
   through an admission control solution which supports admission
   priority capabilities and possibly session preemption capabilities


Le Faucheur, et al.                                           [Page 1]


                RSVP Extensions for Emergency Services      March 2006


   (depending on policies and deployed implementations). Admission
   priority involves setting aside some resources (e.g. bandwidth) out
   of the engineered capacity limits for the emergency services only, or
   alternatively involves allowing the emergency sessions to seize
   additional resources beyond the engineered capacity limits applied to
   normal calls.

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


Copyright Notice
      Copyright (C) The Internet Society (2006)


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), which is an umbrella term
   identifying those networks and specific services used to support
   emergency communications. An underlying goal of these documents is to
   present requirements that elevate the probability of session
   establishment from an authorized user in times of network congestion
   (presumably because of a crisis condition). To that end, some of
   these types of services require that the network be capable of
   preempting sessions; others do not involve preemption but instead
   rely on another network mechanism which we refer throughout this
   document as "admission priority", in order to obtain a high
   probability of session completion for those. Admission priority
   involves setting aside some resources (e.g. bandwidth) out of the
   engineered capacity limits for the emergency services only, or
   alternatively involves allowing the emergency related sessions to
   seize additional resources beyond the engineered capacity limits
   applied to normal calls.

   Note: Below, this document references several examples of IP
   telephony and its use of "calls", which is one form of the term
   "sessions" (Video over IP and Instant Messaging being other examples
   that rely on session establishment).  For the sake of simplicity, we
   shall use the widely known term "call" for the remainder of this
   document.



Le Faucheur, et al.                                           [Page 2]


                RSVP Extensions for Emergency Services      March 2006


   [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 emergency services.

   This document specifies RSVP extensions, which can be used to enforce
   the "admission priority" required by an RSVP capable ETS network. In
   particular this document specifies two new RSVP Policy Elements
   allowing the admission priority to be conveyed inside RSVP signaling
   messages so that RSVP nodes can enforce selective bandwidth admission
   control decision based on the call admission priority. This document
   also provides three examples of a bandwidth allocation model which
   can be used by RSVP-routers to enforce such admission priority on
   every link.

1.1. Changes from previous versions

1.1.1.  Changes from -00 to -01

   The most significant changes are:

      o adding a second RSVP Policy Element that contains the
      application-level resource priority requirements (for example as
      communicated in the SIP Resource-Priority Header) for scenarios
      where priority calls transits through multiple administrative
      domains.

      o adding description of a third bandwidth allocation model
      example: the Priority Bypass Model

      o adding discussion on policies for mapping the various bandwidth
      allocation model over the engineered capacity limits.


2.  Overview of RSVP extensions and Operations

   Let us consider the case where a call requiring ETS type service is
   to be established, and more specifically that the preference to be


Le Faucheur, et al.                                           [Page 3]


                RSVP Extensions for Emergency Services      March 2006


   granted to this call is in terms of "admission priority"  (as opposed
   to preference granted through preemption of existing calls). By
   "admission priority" we mean allowing that priority call to seize
   resources from the engineered capacity that have been set-aside and
   not made available to normal calls, or alternatively by allowing that
   call to seize additional resources beyond the engineered capacity
   limits applied to normal 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 application-level priority requirements of emergency
   calls. Again considering the case where the session control protocol
   is SIP, the SIP user agents can be made aware of the resource
   priority requirements in the case of an emergency call using the
   Resource-Priority Header mechanism specified in [SIP-PRIORITY].

   Where, as per our considered case, the application-level priority
   requirement of the emergency call involves admission priority, the
   devices involved in the upper-layer session establishment simply need
   to:

      (1)  map the application-level 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.

      (2)  Copy the application-level resource priority requirements
           (e.g. as communicated in SIP Resource-Priority Header)
           inside the new RSVP Application-Level Resource-Priority
           Header Policy Element defined in this document. Conveying
           the application-level resource priority requirements inside
           the RSVP message allows this application level requirement
           to be remapped into a different RSVP "admission priority" at
           every administrative domain boundary based on the policy
           applicable in that domain.

           For example, the first domain may honor the resource
           priority requirement and map it into a high RSVP admission
           control priority while the second domain may decide to not
           honor that resource priority requirement and map it into the


Le Faucheur, et al.                                           [Page 4]


                RSVP Extensions for Emergency Services      March 2006


           default (lowest) RSVP admission control priority. As another
           example, we can consider the case where the resource
           priority header enumerates several namespaces, as explicitly
           allowed by [SIP-PRIORITY], for support of scenarios where
           calls traverse multiple administrative domains using
           different namespace. In that case, the relevant namespace
           can be used at the domain boundary to map into an RSVP
           Admission priority. It is not expected that the RSVP
           Application-Level Resource-Priority Header Policy Element
           would be taken into account at RSVP-hops within a given
           administrative domain. It is expected to be used at
           administrative domain boundaries only in order to set/reset
           the RSVP Admission Priority Policy Element.

           Note: The existence of pre-established inter-domain policy
           agreements or Service Level Agreements may preclude the need
           to take real-time action on step (2) at domain boundaries.
           Also, step (2) may be applied to boundaries between various
           signaling protocols, such as those advanced by the NSIS
           working group.


   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

   The RSVP Admission Priority policy element defined in this document
   allows admission bandwidth to be allocated selectively to 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.


Le Faucheur, et al.                                           [Page 5]


                RSVP Extensions for Emergency Services      March 2006


   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.
   Sections 2.1.1 and 2.1.2 respectively illustrate how MAM and RDM can
   indeed be used for support of admission priority. Section 2.1.3
   illustrates how a simple "priority bypass" model can also be used for
   support of admission priority.

   For simplicity, operations with only a single "priority" level
   (beyond non-priority) are 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 made available to priority traffic (even if the non-
   priority traffic is not using all of the bandwidth available for it).


                -----------------------
           ^  ^  ^  |              |  ^
           .  .  .  |              |  .
    Total  .  .  .  |              |  .   Bandwidth
          (1)(2)(3) |              |  .   Available
    Engi-  .  .  .  |              |  .   for non-priority use
   neered  .or.or.  |              |  .
           .  .  .  |              |  .
   Capacity.  .  .  |              |  .
           v  .  .  |              |  v
              .  .  |--------------| ---
              v  .  |              |  ^
                 .  |              |  .   Bandwidth available for
                 v  |              |  v   priority use
                -------------------------

           Chart 1. MAM Bandwidth Allocation

   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.


Le Faucheur, et al.                                           [Page 6]


                RSVP Extensions for Emergency Services      March 2006


   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 fully 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.

   As illustrated in Chart 1, an operator may map the MAM model onto the
   Engineered Capacity limits according to different policies. At one
   extreme, where the proportion of priority traffic is reliably known
   to be fairly small at all times and where there may be some safety
   margin factored in the engineered capacity limits, the operator may
   decide to configure the bandwidth available for non-priority use to
   the full engineered capacity limits; effectively allowing the
   priority traffic to ride within the safety margin of this engineered
   capacity. This policy can be seen as an economically attractive
   approach as all of the engineered capacity is made available to non-
   priority calls. This policy illustrated as (1) in Chart 1. As an
   example, if the engineered capacity limit on a given link is X, the
   operator may configure the bandwidth available to non-priority
   traffic to X, and the bandwidth available to priority traffic to 5%
   of X.

   At the other extreme, where the proportion of priority traffic may be
   significant at times and the engineered capacity limits are very
   tight, the operator may decide to configure the bandwidth available
   to non-priority traffic and the bandwidth available to priority
   traffic such that their sum is equal to the engineered capacity
   limits. This guarantees that the total load across non-priority and
   priority traffic is always below the engineered capacity and, in turn,
   guarantees there will never be any QoS degradation. However, this
   policy is less attractive economically as it prevents non-priority
   calls from using the full engineered capacity, even when there is no
   or little priority load, which is the majority of time. This policy
   illustrated as (3) in Chart 1. As an example, if the engineered
   capacity limit on a given link is X, the operator may configure the
   bandwidth available to non-priority traffic to 95% of X, and the
   bandwidth available to priority traffic to 5% of X.

   Of course, an operator may also strike a balance anywhere in between
   these two approaches. This policy illustrated as (2) in Chart 1.

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

                -----------------------
           ^  ^  ^  |              |  ^


Le Faucheur, et al.                                           [Page 7]


                RSVP Extensions for Emergency Services      March 2006


           .  .  .  |              |  .
    Total  .  .  .  |              |  .   Bandwidth
           .  .  .  |              |  .   Available
    Engi-  .  .  .  |              |  .   for non-priority use
   neered  .or.or.  |xxxxxxxxxxxxxx|  .
           .  .  .  |xxxxxxxxxxxxxx|  .
   Capacity.  .  .  |xxxxxxxxxxxxxx|  .
           v  .  .  |xxxxxxxxxxxxxx|  v
              .  .  |--------------| ---
              v  .  |              |  ^
                 .  |              |  .   Bandwidth available 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.

                -----------------------
           ^  ^  ^  |              |  ^
           .  .  .  |              |  .
    Total  .  .  .  |              |  .   Bandwidth
           .  .  .  |              |  .   Available
    Engi-  .  .  .  |              |  .   for non-priority use
   neered  .or.or.  |xxxxxxxxxxxxxx|  .
           .  .  .  |xxxxxxxxxxxxxx|  .
   Capacity.  .  .  |xxxxxxxxxxxxxx|  .
           v  .  .  |xxxxxxxxxxxxxx|  v
              .  .  |--------------| ---
              v  .  |              |  ^
                 .  |              |  .   Bandwidth available 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


Le Faucheur, et al.                                           [Page 8]


                RSVP Extensions for Emergency Services      March 2006


    Engi-  .  .  .  |xxxxxxxxxxxxxx|  .   for non-priority use
   neered  .or.or.  |xxxxxxxxxxxxxx|  .
           .  .  .  |xxxxxxxxxxxxxx|  .
   Capacity.  .  .  |xxxxxxxxxxxxxx|  .
           v  .  .  |xxxxxxxxxxxxxx|  v
              .  .  |--------------| ---
              v  .  |              |  ^
                 .  |              |  .   Bandwidth available 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 (or to occur
   extremely rarely) because of proper allocation of bandwidth to
   priority traffic, Chart 5 shows for completeness the case where the
   priority traffic equates or exceeds the bandwidth reserved for such
   priority traffic.

   In that case additional priority sessions could not be accepted. Note
   that this does not mean that such calls are dropped altogether: they
   may be handled by mechanisms which are beyond the scope of this
   particular document (such as establishment through preemption of
   existing non-priority sessions, or such as queueing of new priority
   session requests until capacity becomes available again for priority
   traffic).

                -----------------------
           ^  ^  ^  |xxxxxxxxxxxxxx|  ^
           .  .  .  |xxxxxxxxxxxxxx|  .
    Total  .  .  .  |xxxxxxxxxxxxxx|  .   Bandwidth
           .  .  .  |xxxxxxxxxxxxxx|  .   Available
    Engi-  .  .  .  |xxxxxxxxxxxxxx|  .   for non-priority use
   neered  .or.or.  |xxxxxxxxxxxxxx|  .
           .  .  .  |xxxxxxxxxxxxxx|  .
   Capacity.  .  .  |              |  .
           v  .  .  |              |  v
              .  .  |--------------| ---
              v  .  |oooooooooooooo|  ^
                 .  |oooooooooooooo|  .   Bandwidth available 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



Le Faucheur, et al.                                           [Page 9]


                RSVP Extensions for Emergency Services      March 2006


   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.

   As with the MAM model, an operator may map the RDM model onto the
   Engineered Capacity limits according to different policies. The
   operator may decide to configure the bandwidth available for non-
   priority use to the full engineered capacity limits; As an example,
   if the engineered capacity limit on a given link is X, the operator
   may configure the bandwidth available to non-priority traffic to X,
   and the bandwidth available to non-priority and priority traffic to
   105% of X.

   Alternatively, the operator may decide to configure the bandwidth
   available to non-priority and priority traffic to the engineered
   capacity limits; As an example, if the engineered capacity limit on a
   given link is X, the operator may configure the bandwidth available
   to non-priority traffic to 95% of X, and the bandwidth available to
   non-priority and priority traffic to X.

   Finally, the operator may decide to strike a balance in between. The
   considerations presented for these policies in the previous section
   in the MAM context are equally applicable to RDM.

   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
               ---------------------------------------

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




Le Faucheur, et al.                                          [Page 10]


                RSVP Extensions for Emergency Services      March 2006


   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
               ---------------------------------------

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





Le Faucheur, et al.                                          [Page 11]


                RSVP Extensions for Emergency Services      March 2006


   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 such as queueing of new priority
   session requests until capacity becomes available again for priority
   traffic). This is not expected to occur (or to occur extremely
   rarely) 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 9. Full non-priority load & Full Aggregate load


2.1.3.
       Illustration of Admission Priority with Priority Bypass Model

   This section illustrates operations of admission priority when a
   simple Priority Bypass Model is used for bandwidth allocation across
   non-priority traffic and priority traffic. With the Priority Bypass
   Model, non-priority traffic is subject to resource based admission
   control while priority traffic simply bypasses the resource based
   admission control. In other words:
      - when a non-priority call arrives, this call is subject to
   bandwidth admission control and is accepted if the current total load
   (aggregate over non-priority and priority traffic) is below the
   engineered/allocated bandwidth.
      - when a priority call arrives, this call is admitted regardless
   of the current load.

   A property of this model is that a priority call is never rejected.


Le Faucheur, et al.                                          [Page 12]


                RSVP Extensions for Emergency Services      March 2006



   The rationale for this simple scheme is that, in practice in some
   networks:
      - the volume of priority calls is very low for the vast majority
        of time, so it may not be economical to completely set aside
        bandwidth for priority calls and preclude the utilization of
        this bandwidth by normal calls in normal situations
      - even in emergency periods where priority calls are more heavily
        used, those always still represent a fairly small proportion of
        the overall load which can be absorbed within the safety margin
        of the engineered capacity limits. Thus, even if they are
        admitted beyond the engineered bandwidth threshold, they are
        unlikely to result in noticeable QoS degradation.

   As with the MAM and RDM model, an operator may map the Priority
   Bypass model onto the Engineered Capacity limits according to
   different policies. The operator may decide to configure the
   bandwidth limit for admission of non-priority traffic to the full
   engineered capacity limits; As an example, if the engineered capacity
   limit on a given link is X, the operator may configure the bandwidth
   limit for non-priority traffic to X. Alternatively, the operator may
   decide to configure the bandwidth limit for non-priority traffic to
   below the engineered capacity limits (so that the sum of the non-
   priority and priority traffic stays below the engineered capacity);
   As an example, if the engineered capacity limit on a given link is X,
   the operator may configure the bandwidth limit for non-priority
   traffic to 95% of X. Finally, the operator may decide to strike a
   balance in between. The considerations presented for these policies
   in the previous sections in the MAM and RDM contexts are equally
   applicable to the Priority Bypass Model.

   Chart 10 shows illustrates the bandwidth allocation with the Priority
   Bypass Model.

                -----------------------
           ^     ^  |              |  ^
           .     .  |              |  .
    Total  .     .  |              |  .   Bandwidth Limit
          (1)   (2) |              |  .   (on non-priority + priority)
    Engi-  .     .  |              |  .   for admission
   neered  . or  .  |              |  .   of non-priority traffic
           .     .  |              |  .
   Capacity.     .  |              |  .
           v     .  |              |  v
                 .  |--------------| ---
                 .  |              |
                 v  |              |
                    |              |



Le Faucheur, et al.                                          [Page 13]


                RSVP Extensions for Emergency Services      March 2006


           Chart 10. Priority Bypass Model Bandwidth Allocation

   Chart 11 shows some of the non-priority capacity of this link being
   used. In this situation, both new non-priority and new priority calls
   would be accepted.

                -----------------------
           ^     ^  |xxxxxxxxxxxxxx|  ^
           .     .  |xxxxxxxxxxxxxx|  .
    Total  .     .  |xxxxxxxxxxxxxx|  .   Bandwidth Limit
          (1)   (2) |xxxxxxxxxxxxxx|  .   (on non-priority + priority)
    Engi-  .     .  |              |  .   for admission
   neered  . or  .  |              |  .   of non-priority traffic
           .     .  |              |  .
   Capacity.     .  |              |  .
           v     .  |              |  v
                 .  |--------------| ---
                 .  |              |
                 v  |              |
                    |              |

           Chart 11. Partial load of non-priority calls


   Chart 12 shows the same amount of non-priority load being used at
   this link, and a small amount of priority bandwidth being used. In
   this situation, both new non-priority and new priority calls would be
   accepted.

                -----------------------
           ^     ^  |xxxxxxxxxxxxxx|  ^
           .     .  |xxxxxxxxxxxxxx|  .
    Total  .     .  |xxxxxxxxxxxxxx|  .   Bandwidth Limit
          (1)   (2) |xxxxxxxxxxxxxx|  .   (on non-priority + priority)
    Engi-  .     .  |oooooooooooooo|  .   for admission
   neered  . or  .  |              |  .   of non-priority traffic
           .     .  |              |  .
   Capacity.     .  |              |  .
           v     .  |              |  v
                 .  |--------------| ---
                 .  |              |
                 v  |              |
                    |              |

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





Le Faucheur, et al.                                          [Page 14]


                RSVP Extensions for Emergency Services      March 2006


   Chart 13 shows the case where aggregate non-priority and priority
   load exceeds the bandwidth limit for admission of non-priority
   traffic. In this situation, any new non-priority call is rejected
   while any new priority call is admitted.

                -----------------------
           ^     ^  |xxxxxxxxxxxxxx|  ^
           .     .  |xxxxxxxxxxxxxx|  .
    Total  .     .  |xxxxxxxxxxxxxx|  .   Bandwidth Limit
          (1)   (2) |xxxxxxxxxxxxxx|  .   (on non-priority + priority)
    Engi-  .     .  |oooooooooooooo|  .   for admission
   neered  . or  .  |xxxooxxxooxxxo|  .   of non-priority traffic
           .     .  |xxoxxxxxxoxxxx|  .
   Capacity.     .  |oxxxooooxxxxoo|  .
           v     .  |xxoxxxooxxxxxx|  v
                 .  |--------------| ---
                 .  |oooooooooooooo|
                 v  |              |
                    |              |

           Chart 13. Full non-priority load


3.  New Policy Elements

3.1.  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.

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

   The format of Admission Priority policy element is as follows:

         +-------------+-------------+-------------+-------------+
         |     Length                | P-Type = ADMISSION_PRI    |
         +-------------+-------------+-------------+-------------+
         | Flags       | M. Strategy | Error Code  | Reserved    |
         +-------------+-------------+-------------+-------------+
         | Rvd    | Pri|            Reserved                     |
         +---------------------------+---------------------------+


Le Faucheur, et al.                                          [Page 15]


                RSVP Extensions for Emergency Services      March 2006




   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 (only applicable to multicast flows)
       1    Take priority of highest QoS: recommended
       2    Take highest priority: aggressive
       3    Force Error on heterogeneous merge

   Error code: 8 bits (only applicable to multicast flows)
       0  NO_ERROR        Value used for regular ADMISSION_PRI elements
       2  HETEROGENEOUS   This element encountered heterogeneous merge

   Reserved: 8 bits
       Always 0.

   Reserved: 5 bits
       Always 0.

   Pri. (Admission Priority): 3 bits (unsigned)
       The admission control priority of the flow, in terms of access
       to network bandwidth in order to provide higher probability of
       call completion to selected flows. Lower values represent higher
       Priority. 0 represents the highest priority. A reservation
       established without an Admission Priority policy element is
       equivalent to a reservation established with the lowest
       supported admission priority.

       Bandwidth allocation models such as those described in section
       2.1 are to be used by the RSVP router to achieve such increased
       probability of call completion. The admission priority value
       indicates the bandwidth constraint(s) of the bandwidth
       constraint model in use which is(are) applicable to admission of
       this RSVP reservation.

   Reserved: 16 bits
       Always 0.


   Note that the Admission Priority Policy Element does NOT indicate
   that this RSVP reservation is to preempt any call. If a priority


Le Faucheur, et al.                                          [Page 16]


                RSVP Extensions for Emergency Services      March 2006


   session justifies both admission priority and preemption priority,
   the corresponding RSVP reservation needs to carry both an Admission
   Priority Policy Element and a Preemption Priority Policy Element.

   It has been identified that some ETS emergency type sessions would
   need:
      - to benefit from elevated admission priority
      - to be able to preempt other ETS emergency type sessions (the
   ones with lower preemption priorities)
      - to not be able to preempt non-emergency sessions.
   One approach to address this requirement is to add a new Flag in the
   Preemption Priority Policy Element in order to reduce the scope of
   the RSVP preemption mechanism to emergency sessions. Feedback is
   sought on this requirement and potential solution. This will be
   addressed further in next revisions of this document.


3.1.1.
       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.

3.1.1.1   Admission Priority Merging Strategies

   In merging situations Local Decision Points (LDPs) may receive
   multiple admission priority 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.

3.1.1.2   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



Le Faucheur, et al.                                          [Page 17]


                RSVP Extensions for Emergency Services      March 2006


   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.

3.1.1.3   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.

3.1.1.4   Force error on heterogeneous merge

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

3.1.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.



Le Faucheur, et al.                                          [Page 18]


                RSVP Extensions for Emergency Services      March 2006


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


3.1.3.
      Merging 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

      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.


3.2.  Application-Level Resource Priority Policy Element

   This document defines another new Policy Element called the
   Application-Level Resource Priority Element.

   The format of Admission Priority policy element is as follows:

         +-------------+-------------+-------------+-------------+
         | Length                    | P-Type = APP_RESOURCE_PRI |
         +-------------+-------------+-------------+-------------+
         | Flags       | M. Strategy | Error Code  | Reserved    |
         +-------------+-------------+-------------+-------------+
         |       ARP Namespace       | ARP Priority| Reserved    |
         +---------------------------+---------------------------+


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

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

   Flags: 8 bits
       Reserved (always 0).



Le Faucheur, et al.                                          [Page 19]


                RSVP Extensions for Emergency Services      March 2006


   Merge Strategy: 8 bit (only applicable to multicast flows)
       TBD

   Error code: 8 bits (only applicable to multicast flows)
       TBD

   Reserved: 8 bits
       Always 0.

   ARP Namespace (Application-Level Resource Priority Namespace):
       16 bits (unsigned)
       Contains the namespace of the application-level resource
       priority. This is encoded as a numerical value which represents
       the position of the namespace in the "Resource-Priority
       Namespace" IANA registry, starting with 0. Creation of this
       registry has been requested to IANA in [SIP-PRIORITY].
       For example, as "dsn", "drsn", "q735", "ets" and "wps" are
       currently the first, second, third, fourth and fifth namespaces
       defined in the "Resource-Priority Namespace" registry, those are
       respectively encoded as value 0, 1, 2, 3 and 4.

   ARP Priority: (Application-Level Resource Priority Priority):
       8 bits (unsigned)
       Contains the priority value within the namespace of the
       application-level resource priority.
       This is encoded as a numerical value which represents the
       priority defined in the "Resource-Priority Namespace" IANA
       registry for the considered namespace, starting from 0 for the
       highest priority and increasing as priority decreases.
       For example, as "flash-override", "flash", "immediate",
       "priority" and "routine" are the priorities in decreasing order
       of priority registered for the "dsn" namespace, those are
       respectively encoded as value 0, 1, 2, 3 and 4.

   Reserved: 16 bits
       Always 0.


   Multiple instances of Application-Level Resource Priority Policy
   Elements may appear in a POLICY_DATA object or in different
   POLICY_DATA objects. This can be used to convey application-level
   resource priority requirements in multiple namespaces in a single
   RSVP message (in a similar manner to how multiple namespace
   priorities can be conveyed in the SIP Resource-Priority Header of
   [SIP-PRIORITY]). As discussed earlier, this is useful for calls which
   transit through multiple administrative domains.

3.2.1.
      Application-Level Resource Priority Merging Rules



Le Faucheur, et al.                                          [Page 20]


                RSVP Extensions for Emergency Services      March 2006


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

   This will be discussed in the next revision of this document.

   [Editor's note: One approach could be to ensure that the reunion of
   all the namespaces is included in the merge (ie if one receiver
   includes namespace1.prio1 and another one includes namespace2.prio2,
   the merged reservation will contain both namespace1.prio1 and
   namespace2.prio2. Feedback on that is sought]


4.  Security Considerations

   The integrity of ADMISSION_PRI and APP_RESOURCE_PRI is guaranteed, as
   any other policy element, by the encapsulation into a Policy Data
   object [RSVP-POLICY]. The two optional security mechanisms discussed
   in section 6 of [RSVP-POLICY] can be used to protect the
   ADMISSION_PRI and APP_RESOURCE_PRI policy elements.


5.  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 two P-Types from the Standard RSVP Policy
   Element range:
           - one P-Type to the Admission Priority Policy Element
           - one P-Type to the Application-Level Resource Priority
             Policy Element


6.  Acknowledgments

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


7.  Normative References

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


Le Faucheur, et al.                                          [Page 21]


                RSVP Extensions for Emergency Services      March 2006



   [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-04, 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.

   [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

   [SIP-PRIORITY] H. Schulzrinne & J. Polk. Communications Resource
   Priority for the Session Initiation Protocol (SIP), RFC4412, February
   2006.


8.  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.





Le Faucheur, et al.                                          [Page 22]


                RSVP Extensions for Emergency Services      March 2006


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


9.  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
   Richardson, Texas  75082
   USA
   Email: jmpolk@cisco.com

   Ken Carlberg
   G11
   123a Versailles Circle
   Towson, MD. 21204
   USA
   email: carlberg@g11.org.uk


10.  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.




Le Faucheur, et al.                                          [Page 23]


                RSVP Extensions for Emergency Services      March 2006


   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.


11.  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.


12.  Copyright Notice

   Copyright (C) The Internet Society (2006).  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 24]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/