Internet DRAFT - draft-lefaucheur-emergency-rsvp
draft-lefaucheur-emergency-rsvp
RSVP Extensions for Emergency Services June 2006
Internet Draft Francois Le Faucheur
James Polk
Cisco Systems, Inc.
Ken Carlberg
G11
draft-lefaucheur-emergency-rsvp-02.txt
Expires: December 2006 June 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 session establishment to an
authorized user in times of network congestion (typically, during a
crisis). When supported over the Internet Protocol suite, this may be
facilitated through a network layer admission control solution, which
supports prioritized access to resources (e.g., bandwidth). These
resources may be explicitly set aside for emergency services, or they
may be shared with other sessions.
Le Faucheur, et al. [Page 1]
RSVP Extensions for Emergency Services June 2006
This document specifies RSVP extensions that can be used to support
such an admission priority capability at the network layer. Note that
these extensions represent one possible solution component in
satisfying ETS requirements. Other solution components, or other
solutions, are outside the scope of this document.
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].
Table of Contents
1. Introduction...................................................3
1.1. Related Work...............................................3
1.2. Terminology................................................4
1.3. Changes from previous versions.............................4
1.3.1. Changes from -01 to -02..................................4
1.3.2. Changes from -00 to -01..................................5
2. Overview of RSVP extensions and Operations.....................5
2.1. Operations of Admission Priority..........................7
3. New Policy Elements............................................8
3.1. Admission Priority Policy Element.........................8
3.1.1. Admission Priority Merging 10
3.2. Application-Level Resource Priority Policy Element.......10
3.2.1. Application-Level Resource Priority Modifying and
Merging Rules 11
4. Security Considerations.......................................12
5. IANA Considerations...........................................12
6. Acknowledgments...............................................12
7. Normative References..........................................12
8. Informative References........................................13
Appendix A: Examples of Bandwidth Allocation Model for Admission
Priority.........................................................14
A.1 Admission Priority with Maximum Allocation Model (MAM)......14
A.2 Admission Priority with Russian Dolls Model (RDM)...........18
A.3 Admission Priority with Priority Bypass Model (PBM).........20
Appendix B: Example Usages of RSVP Extensions....................23
Authors' Address.................................................25
Le Faucheur, et al. [Page 2]
RSVP Extensions for Emergency Services June 2006
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). In some extreme cases,
the requirement for this probability may reach 100%, but that is a
topic subject to policy and most likely local regulation (the latter
being outside the scope of this document).
Solutions to meet this requirement for elevated session establishment
probability may involve session layer capabilities prioritizing
access to resources controlled by the session control function. As an
example, entities involved in session control (such as SIP user
agents, when SIP is the session control protocol in use) can
influence their treatment of session establishment requests (such as
SIP requests). This may include the ability to "queue" call requests
when those can not be immediately honored (in some cases with the
notion of "bumping", or "displacement", of less important call
request from that queue). It may include additional mechanisms such
as exemption from certain network management controls, and alternate
routing.
Solutions to meet the requirement for elevated session establishment
probability may also take advantage of network layer admission
control mechanisms supporting admission priority. Admission priority
may involves setting aside some network resources (e.g. bandwidth)
out of the engineered capacity limits for the emergency services only,
or alternatively may involve 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.
1.1. Related Work
[EMERG-IMP] is patterned after [ITU.I.225] and describes an example
of one type of prioritized network layer admission control procedure
that may be used for emergency services operating over an IP network
infrastructure. It discusses initial call set up, as well as
operations after call establishment through maintenance of a
Le Faucheur, et al. [Page 3]
RSVP Extensions for Emergency Services June 2006
continuing call model of the status of all calls. [EMERG-IMP] also
describes how these network layer 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 that may be needed by some emergency
services.
In contrast to [EMERG-IMP], this document specifies new RSVP
extensions to increase the probability of call completion without
preemption. Engineered capacity techniques in the form of bandwidth
allocation models are used to satisfy 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. Appendix A of 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.2. Terminology
This document assumes the terminology defined in [FW-POLICY]. For
convenience, the definition of a few key terms is repeated here:
- Policy Decision Point (PDP): The point where policy decisions are
made.
- Local Policy Decision Point (LPDP): PDP local to the network
element
- Policy Enforcement Point (PEP): The point where the policy
decisions are actually enforced.
- Policy Ignorant Node (PIN): A network element that does not
explicitly support policy control using the mechanisms defined in
[FW-POLICY].
1.3. Changes from previous versions
1.3.1. Changes from -01 to -02
Le Faucheur, et al. [Page 4]
RSVP Extensions for Emergency Services June 2006
The most significant changes are:
o modified the Introduction to add additional clarity and to
place related work in a better context to the extensions proposed
in this draft
o Moved bandwidth allocation models to an appendix
o Allowed multiple Application-Level Resource Priority inside
ALRP Policy Element
o Added a 2nd appendix providing examples of RSVP extensions
usage
1.3.2. Changes from -00 to -01
The most significant changes were:
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
granted to this call is in terms of network layer "admission
priority" (as opposed to preference granted through preemption of
existing calls). By "admission priority" we mean allowing that
priority call to seize network layer 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 network layer
admission control achieved via RSVP signaling. In the case where the
Le Faucheur, et al. [Page 5]
RSVP Extensions for Emergency Services June 2006
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]. The
end-devices involved in the upper-layer session establishment simply
need to copy the application-level resource priority requirements
(e.g. as communicated in SIP Resource-Priority Header) inside the new
RSVP Application-Level Resource-Priority Policy Element defined in
this document.
Conveying the application-level resource priority requirements inside
the RSVP message allows this application level requirement to be
mapped/remapped into a different RSVP "admission priority" at every
administrative domain boundary based on the policy applicable in that
domain. In a typical model (see [FW-POLICY]) where PDPs control PEPs
at the periphery of the policy domain (e.g., in border routers), PDPs
would interpret the RSVP Application-Level Resource-Priority Policy
Element and map the requirement of the emergency session into an RSVP
"admission priority" level. Then, PDPs would convey this information
inside the new Admission Priority Policy Element defined in this
document. This way, the RSVP admission priority can be communicated
to downstream PEPs (ie RSVP Routers) of the same policy domain, which
have LPDPs but no controlling PDP. In turn, this means the necessary
RSVP Admission priority can be enforced at every RSVP hop, including
all the (many) hops which do not have any understanding of
Application-Level Resource-Priority semantics.
As an example of operation across multiple administrative domains, a
first domain might decide to provide network layer admission priority
to calls of a given Application Level Resource Priority and map it
into a high RSVP admission control priority inside the Admission
Priority Policy Element; while a second domain may decide to not
provide admission priority to calls of this same Application Level
Resource Priority and hence map it into a low RSVP admission control
priority.
As another example of operation across multiple administrative
domains, 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 each domain boundary to map into an
RSVP Admission priority for that domain. It is not expected that the
RSVP Application-Level Resource-Priority Header Policy Element would
Le Faucheur, et al. [Page 6]
RSVP Extensions for Emergency Services June 2006
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.
The existence of pre-established inter-domain policy agreements or
Service Level Agreements may avoid the need to take real-time action
at administrative domain boundaries for mapping/remapping of
admission priorities.
Mapping/remapping by PDPs may also be applied to boundaries between
various signaling protocols, such as those advanced by the NSIS
working group.
As can be observed, the framework described above for
mapping/remapping application level resource priority requirements
into an RSVP admission priority can also be used for
mapping/remapping application level resource priority requirements
into an RSVP preemption priority (when preemption is indeed needed).
In that case, when processing the RSVP Application-Level Resource-
Priority Policy Element, the PDPs at boundaries between
administrative domains (or between various QoS signaling protocols)
can map it into an RSVP "preemption priority" information. This
Preemption priority information comprises a setup preemption level
and a defending preemption priority level. This preemption priority
information can then be encoded inside the Preemption Priority Policy
Element of [RSVP-PREEMP] and thus, can be taken into account at every
RSVP-enabled network hop as discussed [EMERG-IMP]. Appendix B
provides examples of various hypothetical policies for emergency call
handling, some of them involving admission priority, some of them
involving both admission priority and preemption priority. Appendix B
also identifies how the Application-Level Resource Priority need to
be mapped into RSVP policy elements by the PDPs to realize these
policies.
2.1. Operations of Admission Priority
The RSVP Admission Priority policy element defined in this document
allows admission bandwidth to be allocated preferentially to an
authorized priority service. Multiple models of bandwidth allocation
MAY be used to that end.
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.
Le Faucheur, et al. [Page 7]
RSVP Extensions for Emergency Services June 2006
Appendix A provides an illustration of how these bandwidth allocation
models can be applied for such purposes and introduces an additional
bandwidth allocation model that we term the Priority Bypass Model
(PBM). It is important to note that the models described and
illustrated in Appendix A are only informative and do not represent a
recommended course of action.
3. New Policy Elements
The Framework document for policy-based admission control [FW-POLICY]
describes the various components that participate in policy decision
making (i.e., PDP, PEP and LPDP).
As described in section 2 of the present document, the Application-
Level Resource Priority Policy Element and the Admission Priority
Policy Element serve different roles in this framework:
- the Application-Level Resource Priority Policy Element conveys
application level information and is processed by PDPs
- the emphasis of Admission Priority Policy Element is to be
simple, stateless, and light-weight such that it can be
processed internally within a node's LPDP. It can then be
enforced internally within a node's PEP. It is set by PDPs
based on processing of the Application-Level Resource 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 two new Policy Elements called:
- the Admission Priority Policy Element
- the Application-Level Resource Priority Policy Element
3.1. Admission Priority Policy Element
The format of the Admission Priority policy element is as follows:
+-------------+-------------+-------------+-------------+
| Length | P-Type = ADMISSION_PRI |
+-------------+-------------+-------------+-------------+
Le Faucheur, et al. [Page 8]
RSVP Extensions for Emergency Services June 2006
| Flags | M. Strategy | Error Code | Reserved |
+-------------+-------------+-------------+-------------+
| Rvd | Pri| Reserved |
+---------------------------+---------------------------+
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: Reserved (MUST be set to zero on transmit and ignored on
receive)
Merge Strategy: 8 bit (only applicable to multicast flows)
1 Take priority of highest QoS
2 Take highest priority
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.
Bandwidth allocation models such as those described in Appendix
A are to be used by the RSVP router to achieve such increased
probability of call completion. The admission priority value
effectively indicates which bandwidth constraint(s) of the
bandwidth constraint model in use is(are) applicable to
admission of this RSVP reservation.
Reserved: 16 bits
Always 0.
Le Faucheur, et al. [Page 9]
RSVP Extensions for Emergency Services June 2006
Note that the Admission Priority Policy Element does NOT indicate
that this RSVP reservation is to preempt any other RSVP reservation.
If a priority 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. The Admission Priority and Preemption
Priority are handled by LPDPs and PEPs as orthogonal and independent
mechanisms.
3.1.1.
Admission Priority Merging
This section 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.
The rules for merging Admission Priority Policy Elements are the same
as those defined in [RSVP-PREEMP] for merging Preemption Priority
Policy Elements. In particular, the following merging strategies are
supported:
- Take priority of highest QoS
- Take highest priority
- Force Error on heterogeneous merge.
The only difference with [RSVP-PREEMP] is that this document does not
recommend any merge strategies for Admission Priority while [RSVP-
PREEMP] recommends the first of these merge strategies for Preemption
Priority.
Note that with the Admission Priority, "Take Highest Priority"
translates into "take the lowest numerical value", while with the
Preemption Priority it translates into "take the highest numerical
value".
3.2. Application-Level Resource Priority Policy Element
The format of the Application-Level Resource Priority policy element
is as follows:
+-------------+-------------+-------------+-------------+
| Length | P-Type = APP_RESOURCE_PRI |
+-------------+-------------+-------------+-------------+
// ALRP List //
+---------------------------+---------------------------+
Length: The length of the policy element (including the Length and P-
Type) is in number of octets (MUST be a multiple of 4) and
indicates the end of the ALRP list.
Le Faucheur, et al. [Page 10]
RSVP Extensions for Emergency Services June 2006
P-Type: 16 bits
APP_RESOURCE_PRI = To be allocated by IANA
(see "IANA Considerations" section)
ARLP:
+---------------------------+---------------------------+
| ALRP Namespace |ALRP Priority| Reserved |
+---------------------------+---------------------------+
ALRP 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.
ALRP 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.
3.2.1.
Application-Level Resource Priority Modifying and Merging Rules
When POLICY_DATA objects are protected by integrity, LPDPs should not
attempt to modify them. They MUST be forwarded as-is to ensure their
security envelope is not invalidated.
In case of multicast, when POLICY_DATA objects are not protected by
integrity, LPDPs MAY merge incoming Application-Level Resource
Le Faucheur, et al. [Page 11]
RSVP Extensions for Emergency Services June 2006
Priority elements to reduce their size and number. When they do merge
those, LPDPs MUST do so according to the following rule:
The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list
all the ALRPs appearing in the ALRP List of an incoming
APP_RESOURCE_PR element. A given ALRP MUST NOT appear more than
once. In other words, the outgoing ALRP List is the reunion of
the incoming ARLP Lists that are merged.
As merging is only applicable to Multicast, this rule only applies to
Multicast sessions.
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 12]
RSVP Extensions for Emergency Services June 2006
[EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
for Emergency Telecommunication Service (ETS)", RFC 3690, February
2004.
[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
[EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency
Telecommunications Service for Real Time Services in the Internet
Protocol Suite", RFC 4542, May 2006.
[ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU,
Recommendation, I.255.3, July, 1990.
[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 13]
RSVP Extensions for Emergency Services June 2006
[SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation Protocol
(SIP)", RFC 3312, October 2002.
Appendix A: Examples of Bandwidth Allocation Model for Admission
Priority
Sections A.1 and A.2 respectively illustrate how the Maximum
Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE-
RDM] can be used for support of admission priority. Section A.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
A.1 Admission Priority with Maximum Allocation Model (MAM)
This section illustrates operations of admission priority when a
Maximum Allocation Model (MAM) 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
-------------------------
Le Faucheur, et al. [Page 14]
RSVP Extensions for Emergency Services June 2006
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.
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.
Le Faucheur, et al. [Page 15]
RSVP Extensions for Emergency Services June 2006
Chart 2 shows some of the non-priority capacity of this link 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 | | 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.
Le Faucheur, et al. [Page 16]
RSVP Extensions for Emergency Services June 2006
-----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . Available
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
Chart 5 shows 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 queuing 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
Le Faucheur, et al. [Page 17]
RSVP Extensions for Emergency Services June 2006
A.2 Admission Priority with Russian Dolls Model (RDM)
This section illustrates operations of admission priority when a
Russian Dolls Model (RDM) 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
---------------------------------------
Le Faucheur, et al. [Page 18]
RSVP Extensions for Emergency Services June 2006
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 19]
RSVP Extensions for Emergency Services June 2006
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 such as queuing of new priority
session requests until capacity becomes available again for 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
A.3 Admission Priority with Priority Bypass Model (PBM)
This section illustrates operations of admission priority when a
simple Priority Bypass Model (PBM) 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 20]
RSVP Extensions for Emergency Services June 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 21]
RSVP Extensions for Emergency Services June 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 22]
RSVP Extensions for Emergency Services June 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
Appendix B: Example Usages of RSVP Extensions
This section provides examples of how RSVP extensions defined in this
document can be used (in conjunctions with other RSVP functionality
and SIP functionality) to enforce different hypothetical policies for
handling Emergency sessions in a given administrative domain. This
Appendix does not provide additional specification. It is only
included in this document for illustration purposes. The content of
this appendix may be moved into a future applicability statement
document.
We assume an environment where SIP is used for session control and
RSVP is used for resource reservation.
In a mild abuse of language, we refer here to "Call Queueing" as the
set of "session" layer capabilities that may be implemented by SIP
user agents to influence their treatment of SIP requests. This may
include the ability to "queue" call requests when those can not be
immediately honored (in some cases with the notion of "bumping", or
"displacement", of less important call request from that queue). It
may include additional mechanisms such as exemption from certain
network management controls, and alternate routing.
Le Faucheur, et al. [Page 23]
RSVP Extensions for Emergency Services June 2006
We only mention below the RSVP policy elements that are to be
enforced by PEPs. It is assumed that these policy elements are set at
administrative domain boundaries by PDPs. The Admission Priority and
Preemption Priority RSVP policy elements are set by PDPs as a result
of processing the Application Level Resource Priority Policy Element
(which is carried in RSVP messages).
If one wants to implement an emergency service purely based on Call
Queueing, one can achieve this by signaling emergency calls:
* using "Resource-Priority" Header in SIP
* not using Admission-Priority Policy Element in RSVP
* not using Preemption Policy Element in RSVP
If one wants to implement an emergency service based on Call
Queueing and on "prioritized access to network layer resources", one
can achieve this by signaling emergency calls:
* using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP
* not using Preemption Policy Element in RSVP
Emergency calls will not result in preemption of any session.
Different bandwidth allocation models can be used to offer different
"prioritized access to network resources". Just as examples, this
includes strict setting aside of capacity for emergency sessions as
well as simple bypass of admission limits for emergency sessions.
If one wants to implement an emergency service based on Call Queueing,
on "prioritized access to network layer resources", and ensures that
(say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but
non-emergency sessions are not affected by preemption, one can do
that by signaling emergency calls:
* using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP
* using Preemption Policy Element in RSVP with:
o setup (Emergency-1) > defending (Emergency-2)
o setup (Emergency-2) <= defending (Emergency-1)
o setup (Emergency-1) <= defending (Non-Emergency)
o setup (Emergency-2) <= defending (Non-Emergency)
If one wants to implement an emergency service based on Call Queueing,
on "prioritized access to network layer resources", and ensure that
"emergency" sessions can preempt regular sessions, one could do that
by signaling emergency calls:
* using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP
* using Preemption Policy Element in RSVP with:
o setup (Emergency) > defending (Non-Emergency)
o setup (Non-Emergency) <= defending (Emergency)
If one wants to implement an emergency service based on Call Queueing,
Le Faucheur, et al. [Page 24]
RSVP Extensions for Emergency Services June 2006
on "prioritized access to network layer resources", and ensure that
"emergency" sessions can partially preempt regular sessions (ie
reduce their reservation size), one could do that by signaling
emergency calls:
* using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP
* using Preemption in Policy Element RSVP with:
o setup (Emergency) > defending (Non-Emergency)
o setup (Non-Emergency) <= defending (Emergency)
* activate RFC4495 RSVP Bandwidth Reduction mechanisms
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
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
Le Faucheur, et al. [Page 25]
RSVP Extensions for Emergency Services June 2006
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.
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.
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 26]
