draft-ietf-tsvwg-emergency-rsvp-07.txt   draft-ietf-tsvwg-emergency-rsvp-08.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft J. Polk Internet-Draft J. Polk
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: October 13, 2008 K. Carlberg Expires: November 14, 2008 K. Carlberg
G11 G11
April 11, 2008 May 13, 2008
Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services
draft-ietf-tsvwg-emergency-rsvp-07.txt draft-ietf-tsvwg-emergency-rsvp-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 13, 2008. This Internet-Draft will expire on November 14, 2008.
Abstract Abstract
An Emergency Telecommunications Service (ETS) requires the ability to An Emergency Telecommunications Service (ETS) requires the ability to
provide an elevated probability of session establishment to an provide an elevated probability of session establishment to an
authorized user in times of network congestion (typically, during a authorized user in times of network congestion (typically, during a
crisis). When supported over the Internet Protocol suite, this may crisis). When supported over the Internet Protocol suite, this may
be facilitated through a network layer admission control solution, be facilitated through a network layer admission control solution,
which supports prioritized access to resources (e.g., bandwidth). which supports prioritized access to resources (e.g., bandwidth).
These resources may be explicitly set aside for emergency services, These resources may be explicitly set aside for emergency services,
skipping to change at page 2, line 36 skipping to change at page 2, line 36
3.2.1. Application-Level Resource Priority Modifying and 3.2.1. Application-Level Resource Priority Modifying and
Merging Rules . . . . . . . . . . . . . . . . . . . . 12 Merging Rules . . . . . . . . . . . . . . . . . . . . 12
3.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12 3.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.1. Use of RSVP Authentication between RSVP nighbors . . . . . 13 4.1. Use of RSVP Authentication between RSVP nighbors . . . . . 13
4.2. Use of INTEGRITY object within the POLICY_DATA object . . 13 4.2. Use of INTEGRITY object within the POLICY_DATA object . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Examples of Bandwidth Allocation Model for Appendix A. Examples of Bandwidth Allocation Model for
Admission Priority . . . . . . . . . . . . . . . . . 18 Admission Priority . . . . . . . . . . . . . . . . . 18
A.1. Admission Priority with Maximum Allocation Model (MAM) . . 18 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 19
A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 22 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 23
A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 25 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 26
Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 28 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33
1. Introduction 1. Introduction
[RFC3689] and [RFC3690] detail requirements for an Emergency [RFC3689] and [RFC3690] detail requirements for an Emergency
Telecommunications Service (ETS), which is an umbrella term Telecommunications Service (ETS), which is an umbrella term
identifying those networks and specific services used to support identifying those networks and specific services used to support
emergency communications. An underlying goal of these documents is emergency communications. An underlying goal of these documents is
to present requirements that elevate the probability of session to present requirements that elevate the probability of session
establishment from an authorized user in times of network congestion establishment from an authorized user in times of network congestion
(presumably because of a crisis condition). In some extreme cases, (presumably because of a crisis condition). In some extreme cases,
skipping to change at page 3, line 25 skipping to change at page 3, line 25
topic subject to policy and most likely local regulation (the latter topic subject to policy and most likely local regulation (the latter
being outside the scope of this document). being outside the scope of this document).
Solutions to meet this requirement for elevated session establishment Solutions to meet this requirement for elevated session establishment
probability may involve session layer capabilities prioritizing probability may involve session layer capabilities prioritizing
access to resources controlled by the session control function. As access to resources controlled by the session control function. As
an example, entities involved in session control (such as SIP user an example, entities involved in session control (such as SIP user
agents, when the Session Initiation Protocol (SIP) [RFC3261], is the agents, when the Session Initiation Protocol (SIP) [RFC3261], is the
session control protocol in use) can influence their treatment of session control protocol in use) can influence their treatment of
session establishment requests (such as SIP requests). This may session establishment requests (such as SIP requests). This may
include the ability to "queue" call requests when those can not be include the ability to "queue" session establishment requests when
immediately honored (in some cases with the notion of "bumping", or those can not be immediately honored (in some cases with the notion
"displacement", of less important call request from that queue). It of "bumping", or "displacement", of less important session
may include additional mechanisms such as exemption from certain establishment requests from that queue). It may include additional
network management controls, and alternate routing. mechanisms such as exemption from certain network management
controls, and alternate routing.
Solutions to meet the requirement for elevated session establishment Solutions to meet the requirement for elevated session establishment
probability may also take advantage of network layer admission probability may also take advantage of network layer admission
control mechanisms supporting admission priority. Networks usually control mechanisms supporting admission priority. Networks usually
have engineered capacity limits that characterize the maximum load have engineered capacity limits that characterize the maximum load
that can be handled (say, on any given link) for a class of traffic that can be handled (say, on any given link) for a class of traffic
while satisfying the quality of service requirements of that traffic while satisfying the quality of service requirements of that traffic
class. Admission priority may involve setting aside some network class. Admission priority may involve setting aside some network
resources (e.g. bandwidth) out of the engineered capacity limits for resources (e.g. bandwidth) out of the engineered capacity limits for
the emergency services only. Or alternatively, it may involve the emergency services only. Or alternatively, it may involve
allowing the emergency related sessions to seize additional resources allowing the emergency related sessions to seize additional resources
beyond the engineered capacity limits applied to normal calls. beyond the engineered capacity limits applied to normal sessions.
Note: Below, this document references several examples of IP IP telephony "calls" are one form of "sessions" that can benefit from
telephony and its use of "calls", which is one form of the term the elevated session establishment probability discussed in this
"sessions" (Video over IP and Instant Messaging being other examples document. Video over IP and Instant Messaging are other examples.
that rely on session establishment). For the sake of simplicity, we For the sake of generality, we use the term "session" throughout this
shall use the widely known term "call" for the remainder of this document to refer to any type of session.
document.
1.1. Related Technical Documents 1.1. Related Technical Documents
[RFC4542] is patterned after [ITU.I.225] and describes an example of [RFC4542] is patterned after [ITU.I.225] and describes an example of
one type of prioritized network layer admission control procedure one type of prioritized network layer admission control procedure
that may be used for emergency services operating over an IP network that may be used for emergency services operating over an IP network
infrastructure. It discusses initial call set up, as well as infrastructure. It discusses initial session set up, as well as
operations after call establishment through maintenance of a operations after session establishment through maintenance of a
continuing call model of the status of all calls. [RFC4542] also continuing call model of the status of all sessions. [RFC4542] also
describes how these network layer admission control procedures can be describes how these network layer admission control procedures can be
realized using the Resource reSerVation Protocol [RFC2205] along with realized using the Resource reSerVation Protocol [RFC2205] along with
its associated protocol suite and extensions, including those for its associated protocol suite and extensions, including those for
policy based admission control ([RFC2753], [RFC2750]), for user policy based admission control ([RFC2753], [RFC2750]), for user
authentication and authorization ([RFC3182]) and for integrity and authentication and authorization ([RFC3182]) and for integrity and
authentication of RSVP messages ([RFC2747], [RFC3097]). The Diameter authentication of RSVP messages ([RFC2747], [RFC3097]). The Diameter
QoS Application ([I-D.ietf-dime-diameter-qos]) allows network QoS Application ([I-D.ietf-dime-diameter-qos]) allows network
elements to interact with Diameter servers when allocating QoS elements to interact with Diameter servers when allocating QoS
resources in the network and thus, is also a possible method for resources in the network and thus, is also a possible method for
authentication and authorization of RSVP reservations in the context authentication and authorization of RSVP reservations in the context
of emergency services. of emergency services.
[RFC4542] describes how the RSVP Signaled Preemption Priority Policy [RFC4542] describes how the RSVP Signaled Preemption Priority Policy
Element specified in [RFC3181] can be used to enforce the call Element specified in [RFC3181] can be used to enforce the session
preemption that may be needed by some emergency services. In preemption that may be needed by some emergency services. In
contrast to [RFC4542], this document specifies new RSVP extensions to contrast to [RFC4542], this document specifies new RSVP extensions to
increase the probability of call completion without preemption. increase the probability of session establishment without preemption.
Engineered capacity techniques in the form of bandwidth allocation Engineered capacity techniques in the form of bandwidth allocation
models are used to satisfy the "admission priority" required by an models are used to satisfy the "admission priority" required by an
RSVP capable ETS network. In particular this document specifies two RSVP capable ETS network. In particular this document specifies two
new RSVP Policy Elements allowing the admission priority to be new RSVP Policy Elements allowing the admission priority to be
conveyed inside RSVP signaling messages so that RSVP nodes can conveyed inside RSVP signaling messages so that RSVP nodes can
enforce selective bandwidth admission control decision based on the enforce selective bandwidth admission control decision based on the
call admission priority. Appendix A of this document also provides session admission priority. Appendix A of this document also
examples of bandwidth allocation models which can be used by RSVP- provides examples of bandwidth allocation models which can be used by
routers to enforce such admission priority on every link. RSVP-routers to enforce such admission priority on every link.
1.2. Terminology 1.2. Terminology
This document assumes the terminology defined in [RFC2753]. For This document assumes the terminology defined in [RFC2753]. For
convenience, the definition of a few key terms is repeated here: convenience, the definition of a few key terms is repeated here:
o Policy Decision Point (PDP): The point where policy decisions are o Policy Decision Point (PDP): The point where policy decisions are
made. made.
o Local Policy Decision Point (LPDP): PDP local to the network o Local Policy Decision Point (LPDP): PDP local to the network
skipping to change at page 5, line 11 skipping to change at page 5, line 11
o Policy Enforcement Point (PEP): The point where the policy o Policy Enforcement Point (PEP): The point where the policy
decisions are actually enforced. decisions are actually enforced.
o Policy Ignorant Node (PIN): A network element that does not o Policy Ignorant Node (PIN): A network element that does not
explicitly support policy control using the mechanisms defined in explicitly support policy control using the mechanisms defined in
[RFC2753]. [RFC2753].
2. Overview of RSVP extensions and Operations 2. Overview of RSVP extensions and Operations
Let us consider the case where a call requiring ETS type service is Let us consider the case where a session requiring ETS type service
to be established, and more specifically that the preference to be is to be established, and more specifically that the preference to be
granted to this call is in terms of network layer "admission granted to this session is in terms of network layer "admission
priority" (as opposed to preference granted through preemption of priority" (as opposed to preference granted through preemption of
existing calls). By "admission priority" we mean allowing that existing sessions). By "admission priority" we mean allowing that
priority call to seize network layer resources from the engineered priority session to seize network layer resources from the engineered
capacity that have been set-aside and not made available to normal capacity that have been set-aside and not made available to normal
calls, or alternatively by allowing that call to seize additional sessions, or alternatively by allowing that session to seize
resources beyond the engineered capacity limits applied to normal additional resources beyond the engineered capacity limits applied to
calls. normal sessions.
As described in [RFC4542], the session establishment can be As described in [RFC4542], the session establishment can be
conditioned to resource-based and policy-based network layer conditioned to resource-based and policy-based network layer
admission control achieved via RSVP signaling. In the case where the admission control achieved via RSVP signaling. In the case where the
session control protocol is SIP, the use of RSVP-based admission session control protocol is SIP, the use of RSVP-based admission
control by SIP is specified in [RFC3312]. control by SIP is specified in [RFC3312].
Devices involved in the session establishment are expected to be Devices involved in the session establishment are expected to be
aware of the application-level priority requirements of emergency aware of the application-level priority requirements of emergency
calls. Again considering the case where the session control protocol sessions. Again considering the case where the session control
is SIP, the SIP user agents can be made aware of the resource protocol is SIP, the SIP user agents can be made aware of the
priority requirements in the case of an emergency call using the resource priority requirements in the case of an emergency session
Resource-Priority Header mechanism specified in [RFC4412]. The end- using the Resource-Priority Header mechanism specified in [RFC4412].
devices involved in the upper-layer session establishment simply need The end-devices involved in the upper-layer session establishment
to copy the application-level resource priority requirements (e.g. as simply need to copy the application-level resource priority
communicated in SIP Resource-Priority Header) inside the new RSVP requirements (e.g. as communicated in SIP Resource-Priority Header)
Application-Level Resource-Priority Policy Element defined in this inside the new RSVP Application-Level Resource-Priority Policy
document. Element defined in this document.
Conveying the application-level resource priority requirements inside Conveying the application-level resource priority requirements inside
the RSVP message allows this application level requirement to be the RSVP message allows this application level requirement to be
mapped/remapped into a different RSVP "admission priority" at every mapped/remapped into a different RSVP "admission priority" at every
administrative domain boundary based on the policy applicable in that administrative domain boundary based on the policy applicable in that
domain. In a typical model (see [RFC2753]) where PDPs control PEPs domain. In a typical model (see [RFC2753]) where PDPs control PEPs
at the periphery of the policy domain (e.g., in border routers), PDPs at the periphery of the policy domain (e.g., in border routers), PDPs
would interpret the RSVP Application-Level Resource-Priority Policy would interpret the RSVP Application-Level Resource-Priority Policy
Element and map the requirement of the emergency session into an RSVP Element and map the requirement of the emergency session into an RSVP
"admission priority" level. Then, PDPs would convey this information "admission priority" level. Then, PDPs would convey this information
inside the new Admission Priority Policy Element defined in this inside the new Admission Priority Policy Element defined in this
document. This way, the RSVP admission priority can be communicated document. This way, the RSVP admission priority can be communicated
to downstream PEPs (ie RSVP Routers) of the same policy domain, which to downstream PEPs (ie RSVP Routers) of the same policy domain, which
have LPDPs but no controlling PDP. In turn, this means the necessary have LPDPs but no controlling PDP. In turn, this means the necessary
RSVP Admission priority can be enforced at every RSVP hop, including RSVP Admission priority can be enforced at every RSVP hop, including
all the (many) hops which do not have any understanding of all the (many) hops which do not have any understanding of
Application-Level Resource-Priority semantics. Application-Level Resource-Priority semantics.
As an example of operation across multiple administrative domains, a As an example of operation across multiple administrative domains, a
first domain might decide to provide network layer admission priority first domain might decide to provide network layer admission priority
to calls of a given Application Level Resource Priority and map it to sessions of a given Application Level Resource Priority and map it
into a high RSVP admission control priority inside the Admission into a high RSVP admission control priority inside the Admission
Priority Policy Element; while a second domain may decide to not Priority Policy Element; while a second domain may decide to not
provide admission priority to calls of this same Application Level provide admission priority to sessions of this same Application Level
Resource Priority and hence map it into a low RSVP admission control Resource Priority and hence map it into a low RSVP admission control
priority. priority.
As another example of operation across multiple administrative As another example of operation across multiple administrative
domains, we can consider the case where the resource priority header domains, we can consider the case where the resource priority header
enumerates several namespaces, as explicitly allowed by [RFC4412], enumerates several namespaces, as explicitly allowed by [RFC4412],
for support of scenarios where calls traverse multiple administrative for support of scenarios where sessions traverse multiple
domains using different namespace. In that case, the relevant administrative domains using different namespace. In that case, the
namespace can be used at each domain boundary to map into an RSVP relevant namespace can be used at each domain boundary to map into an
Admission priority for that domain. It is not expected that the RSVP RSVP Admission priority for that domain. It is not expected that the
Application-Level Resource-Priority Header Policy Element would be RSVP Application-Level Resource-Priority Header Policy Element would
taken into account at RSVP-hops within a given administrative domain. be taken into account at RSVP-hops within a given administrative
It is expected to be used at administrative domain boundaries only in domain. It is expected to be used at administrative domain
order to set/reset the RSVP Admission Priority Policy Element. boundaries only in order to set/reset the RSVP Admission Priority
Policy Element.
The existence of pre-established inter-domain policy agreements or The existence of pre-established inter-domain policy agreements or
Service Level Agreements may avoid the need to take real-time action Service Level Agreements may avoid the need to take real-time action
at administrative domain boundaries for mapping/remapping of at administrative domain boundaries for mapping/remapping of
admission priorities. admission priorities.
Mapping/remapping by PDPs may also be applied to boundaries between Mapping/remapping by PDPs may also be applied to boundaries between
various signaling protocols, such as those advanced by the NSIS various signaling protocols, such as those advanced by the NSIS
working group. working group.
skipping to change at page 7, line 5 skipping to change at page 7, line 6
into an RSVP preemption priority (when preemption is indeed needed). into an RSVP preemption priority (when preemption is indeed needed).
In that case, when processing the RSVP Application-Level Resource- In that case, when processing the RSVP Application-Level Resource-
Priority Policy Element, the PDPs at boundaries between Priority Policy Element, the PDPs at boundaries between
administrative domains (or between various QoS signaling protocols) administrative domains (or between various QoS signaling protocols)
can map it into an RSVP "preemption priority" information. This can map it into an RSVP "preemption priority" information. This
Preemption priority information comprises a setup preemption level Preemption priority information comprises a setup preemption level
and a defending preemption priority level. This preemption priority and a defending preemption priority level. This preemption priority
information can then be encoded inside the Preemption Priority Policy information can then be encoded inside the Preemption Priority Policy
Element of [RFC3181] and thus, can be taken into account at every Element of [RFC3181] and thus, can be taken into account at every
RSVP-enabled network hop as discussed [RFC4542]. Appendix B provides RSVP-enabled network hop as discussed [RFC4542]. Appendix B provides
examples of various hypothetical policies for emergency call examples of various hypothetical policies for emergency session
handling, some of them involving admission priority, some of them handling, some of them involving admission priority, some of them
involving both admission priority and preemption priority. Appendix involving both admission priority and preemption priority. Appendix
B also identifies how the Application-Level Resource Priority need to B also identifies how the Application-Level Resource Priority need to
be mapped into RSVP policy elements by the PDPs to realize these be mapped into RSVP policy elements by the PDPs to realize these
policies. policies.
2.1. Operations of Admission Priority 2.1. Operations of Admission Priority
The RSVP Admission Priority policy element defined in this document The RSVP Admission Priority policy element defined in this document
allows admission bandwidth to be allocated preferentially to an allows admission bandwidth to be allocated preferentially to an
skipping to change at page 9, line 17 skipping to change at page 9, line 17
* ADMISSION_PRI = To be allocated by IANA (see "IANA * ADMISSION_PRI = To be allocated by IANA (see "IANA
Considerations" section) Considerations" section)
o Flags: Reserved o Flags: Reserved
* SHALL be set to zero on transmit and SHALL be ignored on * SHALL be set to zero on transmit and SHALL be ignored on
reception reception
o Merge Strategy: 8 bits (only applicable to multicast flows) o Merge Strategy: 8 bits (only applicable to multicast flows)
* 1 Take priority of highest QoS * values are defined by corresponding registry maintained by IANA
(see "IANA Considerations" section)
* 2 Take highest priority
* 3 Force Error on heterogeneous merge (See section 3.1.1)
o Error code: 8 bits (only applicable to multicast flows) o Error code: 8 bits (only applicable to multicast flows)
* 0 NO_ERROR Value used for regular ADMISSION_PRI elements * values are defined by corresponding registry maintained by IANA
(see "IANA Considerations" section)
* 2 HETEROGENEOUS This element encountered heterogeneous merge
o Reserved: 8 bits o Reserved: 8 bits
* SHALL be set to zero on transmit and SHALL be ignored on * SHALL be set to zero on transmit and SHALL be ignored on
reception reception
o Reserved: 24 bits o Reserved: 24 bits
* SHALL be set to zero on transmit and SHALL be ignored on * SHALL be set to zero on transmit and SHALL be ignored on
reception reception
o Adm. Priority (Admission Priority): 8 bits (unsigned) o Adm. Priority (Admission Priority): 8 bits (unsigned)
* The admission control priority of the flow, in terms of access * The admission control priority of the flow, in terms of access
to network bandwidth in order to provide higher probability of to network bandwidth in order to provide higher probability of
call completion to selected flows. Higher values represent session completion to selected flows. Higher values represent
higher Priority. A given Admission Priority is encoded in this higher Priority. A given Admission Priority is encoded in this
information element using the same value as when encoded in the information element using the same value as when encoded in the
"Admission Priority" field of the "Admission Priority" "Admission Priority" field of the "Admission Priority"
parameter defined in [I-D.ietf-nsis-qspec], or in the parameter defined in [I-D.ietf-nsis-qspec], or in the
"Admission Priority" parameter defined in "Admission Priority" parameter defined in
[I-D.ietf-dime-qos-parameters]. In other words, a given value [I-D.ietf-dime-qos-parameters]. In other words, a given value
inside the Admission Priority information element defined in inside the Admission Priority information element defined in
the present document, inside the [I-D.ietf-nsis-qspec] the present document, inside the [I-D.ietf-nsis-qspec]
Admission Priority field or inside the Admission Priority field or inside the
[I-D.ietf-dime-qos-parameters] Admission Priority parameter, [I-D.ietf-dime-qos-parameters] Admission Priority parameter,
refers to the same admission priority. Bandwidth allocation refers to the same admission priority. Bandwidth allocation
models such as those described in Appendix A are to be used by models such as those described in Appendix A are to be used by
the RSVP router to achieve such increased probability of call the RSVP router to achieve such increased probability of
completion. The admission priority value effectively indicates session establishment. The admission priority value
which bandwidth constraint(s) of the bandwidth constraint model effectively indicates which bandwidth constraint(s) of the
in use is(are) applicable to admission of this RSVP bandwidth constraint model in use is(are) applicable to
reservation. admission of this RSVP reservation.
Note that the Admission Priority Policy Element does NOT indicate Note that the Admission Priority Policy Element does NOT indicate
that this RSVP reservation is to preempt any other RSVP reservation. that this RSVP reservation is to preempt any other RSVP reservation.
If a priority session justifies both admission priority and If a priority session justifies both admission priority and
preemption priority, the corresponding RSVP reservation needs to preemption priority, the corresponding RSVP reservation needs to
carry both an Admission Priority Policy Element and a Preemption carry both an Admission Priority Policy Element and a Preemption
Priority Policy Element. The Admission Priority and Preemption Priority Policy Element. The Admission Priority and Preemption
Priority are handled by LPDPs and PEPs as separate mechanisms. They Priority are handled by LPDPs and PEPs as separate mechanisms. They
can be used one without the other, or they can be used both in can be used one without the other, or they can be used both in
combination. combination.
3.1.1. Admission Priority Merging Rules 3.1.1. Admission Priority Merging Rules
This section discusses alternatives for dealing with RSVP admission This section discusses alternatives for dealing with RSVP admission
priority in case of merging of reservations. As merging is only priority in case of merging of reservations. As merging is only
applicable to multicast, this section also only applies to multicast applicable to multicast, this section also only applies to multicast
sessions. sessions.
The rules for merging Admission Priority Policy Elements are the same The rules for merging Admission Priority Policy Elements are defined
as those defined in [RFC3181] for merging Preemption Priority Policy by the value encoded inside the Merge Strategy field in accordance
Elements. In particular, the following merging strategies are with the corresponding IANA registry. The merge strategies (and
supported: associated values) defined by the present document are the same as
those defined in [RFC3181] for merging Preemption Priority Policy
o Take priority of highest QoS Elements (see "IANA Considerations" section).
o Take highest priority
o Force Error on heterogeneous merge.
The only difference with [RFC3181] is that this document does not The only difference with [RFC3181] is that this document does not
recommend any merge strategies for Admission Priority while [RFC3181] recommend any merge strategies for Admission Priority, while
recommends the first of these merge strategies for Preemption [RFC3181] recommends the first of these merge strategies for
Priority. Note that with the Admission Priority (as is the case with Preemption Priority. Note that with the Admission Priority (as is
the Preemption Priority), "Take highest priority" translates into the case with the Preemption Priority), "Take highest priority"
"take the highest numerical value". translates into "take the highest numerical value".
3.2. Application-Level Resource Priority Policy Element 3.2. Application-Level Resource Priority Policy Element
The format of the Application-Level Resource Priority policy element The format of the Application-Level Resource Priority policy element
is as shown in Figure 2: is as shown in Figure 2:
0 0 0 1 1 2 2 3 0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type = APP_RESOURCE_PRI | | Length | P-Type = APP_RESOURCE_PRI |
skipping to change at page 14, line 25 skipping to change at page 14, line 25
the policies outlined in [RFC2434]. the policies outlined in [RFC2434].
IANA needs to allocate two P-Types from the Standard RSVP Policy IANA needs to allocate two P-Types from the Standard RSVP Policy
Element range: Element range:
o one P-Type to the Admission Priority Policy Element o one P-Type to the Admission Priority Policy Element
o one P-Type to the Application-Level Resource Priority Policy o one P-Type to the Application-Level Resource Priority Policy
Element. Element.
In section 3.1, the present document defines a Merge Strategy field
inside the Admission Priority policy element. IANA needs to create a
registry for this field and allocate the following values:
o 1: Take priority of highest QoS
o 2: Take highest priority
o 3: Force Error on heterogeneous merge
Following the policies outlined in [RFC2434], numbers in the range
4-127 are allocated through an IETF Consensus action, numbers in the
range 128-240 as First Come First Served and numbers between 241-255
are reserved for Private Use. Value 0 is Reserved (for consistency
with [RFC3181] Merge Strategy values).
In section 3.1, the present document defines an Error Code field
inside the Admission Priority policy element. IANA needs to create a
registry for this field and allocate the following values:
o 0: NO_ERROR Value used for regular ADMISSION_PRI elements
o 2: HETEROGENEOUS This element encountered heterogeneous merge
Following the policies outlined in [RFC2434], numbers in the range
3-127 are allocated through an IETF Consensus action, numbers in the
range 128-240 as First Come First Served and numbers between 241-255
are reserved for Private Use. Value 1 is Reserved (for consistency
with [RFC3181] Error Code values).
The present document defines an ALRP Namespace field in section 3.2 The present document defines an ALRP Namespace field in section 3.2
that contains a numerical value identifying the namespace of the that contains a numerical value identifying the namespace of the
application-level resource priority. The IANA already maintains the application-level resource priority. The IANA already maintains the
Resource-Priority Namespaces registry (under the SIP Parameters) Resource-Priority Namespaces registry (under the SIP Parameters)
listing all such namespace. However, that registry does not listing all such namespace. However, that registry does not
currently allocate a numerical value to each namespace. Hence, this currently allocate a numerical value to each namespace. Hence, this
document requests the IANA to extend the Resource-Priority Namespace document requests the IANA to extend the Resource-Priority Namespace
registry in the following ways: registry in the following ways:
o a new column should be added to the registry o a new column should be added to the registry
skipping to change at page 15, line 45 skipping to change at page 16, line 26
o add a line at the bottom of the registry stating the following "* o add a line at the bottom of the registry stating the following "*
: [RFCXXX] " where XXX is the RFC number of the present document : [RFCXXX] " where XXX is the RFC number of the present document
o allocate an actual numerical value to each and state that value in o allocate an actual numerical value to each and state that value in
the new "Priority Numerical Value *" column. the new "Priority Numerical Value *" column.
A numerical value should be allocated immediately by IANA to all A numerical value should be allocated immediately by IANA to all
existing priority. Then, in the future, IANA should automatically existing priority. Then, in the future, IANA should automatically
allocate a numerical value to any new namespace added to the allocate a numerical value to any new namespace added to the
registry. The numerical value must be unique within each namespace. registry. The numerical value must be unique within each namespace.
Within each namespace, values should be allocated in decreasing order For the initial allocation, within each namespace, values should be
ending with 0 (so that the greatest priority is always allocated allocated in decreasing order ending with 0 (so that the greatest
value 0). For example, in the drsn namespace, "routine" would be priority is always allocated value 0). For example, in the drsn
allocated numerical value 5 and "flash-override-override" would be namespace, "routine" would be allocated numerical value 5 and "flash-
allocated numerical value 0. override-override" would be allocated numerical value 0.
6. Acknowledgments 6. Acknowledgments
We would like to thank An Nguyen for his encouragement to address We would like to thank An Nguyen for his encouragement to address
this topic and ongoing comments. Also, this document borrows heavily this topic and ongoing comments. Also, this document borrows heavily
from some of the work of S. Herzog on Preemption Priority Policy from some of the work of S. Herzog on Preemption Priority Policy
Element [RFC3181]. Dave Oran and Janet Gunn provided useful input Element [RFC3181]. Dave Oran and Janet Gunn provided useful input
into this document. into this document.
7. References 7. References
skipping to change at page 19, line 33 skipping to change at page 20, line 11
Figure 4 shows a link within a routed network conforming to this Figure 4 shows a link within a routed network conforming to this
document. On this link are two amounts of bandwidth available to two document. On this link are two amounts of bandwidth available to two
types of traffic: non-priority and priority. types of traffic: non-priority and priority.
If the non-priority traffic load reaches the maximum bandwidth If the non-priority traffic load reaches the maximum bandwidth
available for non-priority, no additional non-priority sessions can available for non-priority, no additional non-priority sessions can
be accepted even if the bandwidth reserved for priority traffic is be accepted even if the bandwidth reserved for priority traffic is
not currently fully utilized. not currently fully utilized.
With the Maximum Allocation Model, in the case where the priority With the Maximum Allocation Model, in the case where the priority
load reaches the maximum bandwidth reserved for priority calls, no load reaches the maximum bandwidth reserved for priority sessions, no
additional priority sessions can be accepted. additional priority sessions can be accepted.
As illustrated in Figure 4, an operator may map the MAM model onto As illustrated in Figure 4, an operator may map the MAM model onto
the Engineered Capacity limits according to different policies. At the Engineered Capacity limits according to different policies. At
one extreme, where the proportion of priority traffic is reliably one extreme, where the proportion of priority traffic is reliably
known to be fairly small at all times and where there may be some known to be fairly small at all times and where there may be some
safety margin factored in the engineered capacity limits, the safety margin factored in the engineered capacity limits, the
operator may decide to configure the bandwidth available for non- operator may decide to configure the bandwidth available for non-
priority use to the full engineered capacity limits; effectively priority use to the full engineered capacity limits; effectively
allowing the priority traffic to ride within the safety margin of allowing the priority traffic to ride within the safety margin of
this engineered capacity. This policy can be seen as an economically this engineered capacity. This policy can be seen as an economically
attractive approach as all of the engineered capacity is made attractive approach as all of the engineered capacity is made
available to non-priority calls. This policy is illustrated as (1) available to non-priority sessions. This policy is illustrated as
in Figure 4. As an example, if the engineered capacity limit on a (1) in Figure 4. As an example, if the engineered capacity limit on
given link is X, the operator may configure the bandwidth available a given link is X, the operator may configure the bandwidth available
to non-priority traffic to X, and the bandwidth available to priority 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 traffic to 5% of X. At the other extreme, where the proportion of
priority traffic may be significant at times and the engineered priority traffic may be significant at times and the engineered
capacity limits are very tight, the operator may decide to configure capacity limits are very tight, the operator may decide to configure
the bandwidth available to non-priority traffic and the bandwidth the bandwidth available to non-priority traffic and the bandwidth
available to priority traffic such that their sum is equal to the available to priority traffic such that their sum is equal to the
engineered capacity limits. This guarantees that the total load engineered capacity limits. This guarantees that the total load
across non-priority and priority traffic is always below the across non-priority and priority traffic is always below the
engineered capacity and, in turn, guarantees there will never be any engineered capacity and, in turn, guarantees there will never be any
QoS degradation. However, this policy is less attractive QoS degradation. However, this policy is less attractive
economically as it prevents non-priority calls from using the full economically as it prevents non-priority sessions from using the full
engineered capacity, even when there is no or little priority load, engineered capacity, even when there is no or little priority load,
which is the majority of time. This policy is illustrated as (3) in which is the majority of time. This policy is illustrated as (3) in
Figure 4. As an example, if the engineered capacity limit on a given Figure 4. As an example, if the engineered capacity limit on a given
link is X, the operator may configure the bandwidth available to non- link is X, the operator may configure the bandwidth available to non-
priority traffic to 95% of X, and the bandwidth available to priority 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 traffic to 5% of X. Of course, an operator may also strike a balance
anywhere in between these two approaches. This policy is illustrated anywhere in between these two approaches. This policy is illustrated
as (2) in Figure 4. as (2) in Figure 4.
Figure 5 shows some of the non-priority capacity of this link being Figure 5 shows some of the non-priority capacity of this link being
skipping to change at page 21, line 51 skipping to change at page 22, line 27
. | | . Bandwidth available for . | | . Bandwidth available for
v |oooooooooooooo| v priority use v |oooooooooooooo| v priority use
------------------------- -------------------------
Figure 7: Full non-priority load & partial load of priority calls Figure 7: Full non-priority load & partial load of priority calls
Figure 8 shows the case where the priority traffic equates or exceeds Figure 8 shows the case where the priority traffic equates or exceeds
the bandwidth reserved for such priority traffic. the bandwidth reserved for such priority traffic.
In that case additional priority sessions could not be accepted. In that case additional priority sessions could not be accepted.
Note that this does not mean that such calls are dropped altogether: Note that this does not mean that such sessions are dropped
they may be handled by mechanisms, which are beyond the scope of this altogether: they may be handled by mechanisms, which are beyond the
particular document (such as establishment through preemption of scope of this particular document (such as establishment through
existing non-priority sessions, or such as queuing of new priority preemption of existing non-priority sessions, or such as queuing of
session requests until capacity becomes available again for priority new priority session requests until capacity becomes available again
traffic). for priority traffic).
----------------------- -----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^ ^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| . . . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . Available . . . |xxxxxxxxxxxxxx| . Available
Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| . neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| . . . . |xxxxxxxxxxxxxx| .
Capacity. . . | | . Capacity. . . | | .
skipping to change at page 24, line 26 skipping to change at page 24, line 50
| | . | | .
|oooooooooooooo| v |oooooooooooooo| v
--------------------------------------- ---------------------------------------
Figure 10: Full non-priority load & Partial Aggregate load Figure 10: Full non-priority load & Partial Aggregate load
Figure 11 shows the case where only some of the bandwidth available Figure 11 shows the case where only some of the bandwidth available
to non-priority traffic is being used and a heavy load of priority to non-priority traffic is being used and a heavy load of priority
traffic is in place. In that situation both new non-priority traffic is in place. In that situation both new non-priority
sessions and new priority sessions would be accepted. Note that, as sessions and new priority sessions would be accepted. Note that, as
illustrated in Figure 10, priority calls use some of the bandwidth illustrated in Figure 10, priority sessions use some of the bandwidth
currently not used by non-priority traffic. currently not used by non-priority traffic.
-------------------------------------- --------------------------------------
|xxxxxxxxxxxxxx| . ^ |xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth . |xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . Available for . |xxxxxxxxxxxxxx| . Available for .
|xxxxxxxxxxxxxx| . non-priority . |xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use . |xxxxxxxxxxxxxx| . use .
| | . . Bandwidth | | . . Bandwidth
| | . . available for | | . . available for
skipping to change at page 25, line 34 skipping to change at page 26, line 31
A.3. Admission Priority with Priority Bypass Model (PrBM) A.3. Admission Priority with Priority Bypass Model (PrBM)
This section illustrates operations of admission priority when a This section illustrates operations of admission priority when a
simple Priority Bypass Model (PrBM) is used for bandwidth allocation simple Priority Bypass Model (PrBM) is used for bandwidth allocation
across non-priority traffic and priority traffic. With the Priority across non-priority traffic and priority traffic. With the Priority
Bypass Model, non-priority traffic is subject to resource based Bypass Model, non-priority traffic is subject to resource based
admission control while priority traffic simply bypasses the resource admission control while priority traffic simply bypasses the resource
based admission control. In other words: based admission control. In other words:
o when a non-priority call arrives, this call is subject to o when a non-priority session arrives, this session is subject to
bandwidth admission control and is accepted if the current total bandwidth admission control and is accepted if the current total
load (aggregate over non-priority and priority traffic) is below load (aggregate over non-priority and priority traffic) is below
the engineered/allocated bandwidth. the engineered/allocated bandwidth.
o when a priority call arrives, this call is admitted regardless of o when a priority session arrives, this session is admitted
the current load. regardless of the current load.
A property of this model is that a priority call is never rejected. A property of this model is that a priority session is never
rejected.
The rationale for this simple scheme is that, in practice in some The rationale for this simple scheme is that, in practice in some
networks: networks:
o the volume of priority calls is very low for the vast majority of o the volume of priority sessions is very low for the vast majority
time, so it may not be economical to completely set aside of time, so it may not be economical to completely set aside
bandwidth for priority calls and preclude the utilization of this bandwidth for priority sessions and preclude the utilization of
bandwidth by normal calls in normal situations this bandwidth by normal sessions in normal situations
o even in emergency periods where priority calls are more heavily
o even in emergency periods where priority sessions are more heavily
used, those always still represent a fairly small proportion of used, those always still represent a fairly small proportion of
the overall load which can be absorbed within the safety margin of the overall load which can be absorbed within the safety margin of
the engineered capacity limits. Thus, even if they are admitted the engineered capacity limits. Thus, even if they are admitted
beyond the engineered bandwidth threshold, they are unlikely to beyond the engineered bandwidth threshold, they are unlikely to
result in noticeable QoS degradation. result in noticeable QoS degradation.
As with the MAM and RDM model, an operator may map the Priority As with the MAM and RDM model, an operator may map the Priority
Bypass model onto the Engineered Capacity limits according to Bypass model onto the Engineered Capacity limits according to
different policies. The operator may decide to configure the different policies. The operator may decide to configure the
bandwidth limit for admission of non-priority traffic to the full bandwidth limit for admission of non-priority traffic to the full
skipping to change at page 26, line 50 skipping to change at page 27, line 47
v . | | v v . | | v
. |--------------| --- . |--------------| ---
. | | . | |
v | | v | |
| | | |
Figure 13: Priority Bypass Model Bandwidth Allocation Figure 13: Priority Bypass Model Bandwidth Allocation
Figure 14 shows some of the non-priority capacity of this link being Figure 14 shows some of the non-priority capacity of this link being
used. In this situation, both new non-priority and new priority used. In this situation, both new non-priority and new priority
calls would be accepted. sessions would be accepted.
----------------------- -----------------------
^ ^ |xxxxxxxxxxxxxx| ^ ^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| . . . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . | | . for admission Engi- . . | | . for admission
neered . or . | | . of non-priority traffic neered . or . | | . of non-priority traffic
. . | | . . . | | .
Capacity. . | | . Capacity. . | | .
v . | | v v . | | v
. |--------------| --- . |--------------| ---
. | | . | |
v | | v | |
| | | |
Figure 14: Partial load of non-priority calls Figure 14: Partial load of non-priority calls
Figure 15 shows the same amount of non-priority load being used at Figure 15 shows the same amount of non-priority load being used at
this link, and a small amount of priority bandwidth being used. In this link, and a small amount of priority bandwidth being used. In
this situation, both new non-priority and new priority calls would be this situation, both new non-priority and new priority sessions would
accepted. be accepted.
----------------------- -----------------------
^ ^ |xxxxxxxxxxxxxx| ^ ^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| . . . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission Engi- . . |oooooooooooooo| . for admission
neered . or . | | . of non-priority traffic neered . or . | | . of non-priority traffic
. . | | . . . | | .
Capacity. . | | . Capacity. . | | .
skipping to change at page 27, line 47 skipping to change at page 28, line 47
. |--------------| --- . |--------------| ---
. | | . | |
v | | v | |
| | | |
Figure 15: Partial load of non-priority calls & partial load of Figure 15: Partial load of non-priority calls & partial load of
priority calls priority calls
Figure 16 shows the case where aggregate non-priority and priority Figure 16 shows the case where aggregate non-priority and priority
load exceeds the bandwidth limit for admission of non-priority load exceeds the bandwidth limit for admission of non-priority
traffic. In this situation, any new non-priority call is rejected traffic. In this situation, any new non-priority session is rejected
while any new priority call is admitted. while any new priority session is admitted.
----------------------- -----------------------
^ ^ |xxxxxxxxxxxxxx| ^ ^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| . . . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission Engi- . . |oooooooooooooo| . for admission
neered . or . |xxxooxxxooxxxo| . of non-priority traffic neered . or . |xxxooxxxooxxxo| . of non-priority traffic
. . |xxoxxxxxxoxxxx| . . . |xxoxxxxxxoxxxx| .
Capacity. . |oxxxooooxxxxoo| . Capacity. . |oxxxooooxxxxoo| .
skipping to change at page 28, line 37 skipping to change at page 29, line 37
handling Emergency sessions in a given administrative domain. This handling Emergency sessions in a given administrative domain. This
Appendix does not provide additional specification. It is only Appendix does not provide additional specification. It is only
included in this document for illustration purposes. included in this document for illustration purposes.
We assume an environment where SIP is used for session control and We assume an environment where SIP is used for session control and
RSVP is used for resource reservation. RSVP is used for resource reservation.
In a mild abuse of language, we refer here to "Call Queueing" as the 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 set of "session" layer capabilities that may be implemented by SIP
user agents to influence their treatment of SIP requests. This may user agents to influence their treatment of SIP requests. This may
include the ability to "queue" call requests when those can not be include the ability to "queue" session requests when those can not be
immediately honored (in some cases with the notion of "bumping", or immediately honored (in some cases with the notion of "bumping", or
"displacement", of less important call request from that queue). It "displacement", of less important session requests from that queue).
may include additional mechanisms such as exemption from certain It may include additional mechanisms such as exemption from certain
network management controls, and alternate routing. network management controls, and alternate routing.
We only mention below the RSVP policy elements that are to be We only mention below the RSVP policy elements that are to be
enforced by PEPs. It is assumed that these policy elements are set enforced by PEPs. It is assumed that these policy elements are set
at administrative domain boundaries by PDPs. The Admission Priority at administrative domain boundaries by PDPs. The Admission Priority
and Preemption Priority RSVP policy elements are set by PDPs as a and Preemption Priority RSVP policy elements are set by PDPs as a
result of processing the Application Level Resource Priority Policy result of processing the Application Level Resource Priority Policy
Element (which is carried in RSVP messages). Element (which is carried in RSVP messages).
If one wants to implement an emergency service purely based on Call If one wants to implement an emergency service purely based on Call
Queueing, one can achieve this by signaling emergency calls: Queueing, one can achieve this by signaling emergency sessions:
o using "Resource-Priority" Header in SIP o using "Resource-Priority" Header in SIP
o not using Admission-Priority Policy Element in RSVP o not using Admission-Priority Policy Element in RSVP
o not using Preemption Policy Element in RSVP o not using Preemption Policy Element in RSVP
If one wants to implement an emergency service based on Call Queueing If one wants to implement an emergency service based on Call Queueing
and on "prioritized access to network layer resources", one can and on "prioritized access to network layer resources", one can
achieve this by signaling emergency calls: achieve this by signaling emergency sessions:
o using "Resource-Priority" Header in SIP o using "Resource-Priority" Header in SIP
o using Admission-Priority Policy Element in RSVP o using Admission-Priority Policy Element in RSVP
o not using Preemption Policy Element in RSVP o not using Preemption Policy Element in RSVP
Emergency calls will not result in preemption of any session. Emergency sessions will not result in preemption of any session.
Different bandwidth allocation models can be used to offer different Different bandwidth allocation models can be used to offer different
"prioritized access to network resources". Just as examples, this "prioritized access to network resources". Just as examples, this
includes strict setting aside of capacity for emergency sessions as includes strict setting aside of capacity for emergency sessions as
well as simple bypass of admission limits for emergency sessions. well as simple bypass of admission limits for emergency sessions.
If one wants to implement an emergency service based on Call If one wants to implement an emergency service based on Call
Queueing, on "prioritized access to network layer resources", and Queueing, on "prioritized access to network layer resources", and
ensures that (say) "Emergency-1" sessions can preempt "Emergency-2" ensures that (say) "Emergency-1" sessions can preempt "Emergency-2"
sessions, but non-emergency sessions are not affected by preemption, sessions, but non-emergency sessions are not affected by preemption,
one can do that by signaling emergency calls: one can do that by signaling emergency sessions:
o using "Resource-Priority" Header in SIP o using "Resource-Priority" Header in SIP
o using Admission-Priority Policy Element in RSVP o using Admission-Priority Policy Element in RSVP
o using Preemption Policy Element in RSVP with: o using Preemption Policy Element in RSVP with:
* setup (Emergency-1) > defending (Emergency-2) * setup (Emergency-1) > defending (Emergency-2)
* setup (Emergency-2) <= defending (Emergency-1) * setup (Emergency-2) <= defending (Emergency-1)
* setup (Emergency-1) <= defending (Non-Emergency) * setup (Emergency-1) <= defending (Non-Emergency)
* setup (Emergency-2) <= defending (Non-Emergency) * setup (Emergency-2) <= defending (Non-Emergency)
If one wants to implement an emergency service based on Call If one wants to implement an emergency service based on Call
Queueing, on "prioritized access to network layer resources", and Queueing, on "prioritized access to network layer resources", and
ensure that "emergency" sessions can preempt regular sessions, one ensure that "emergency" sessions can preempt regular sessions, one
could do that by signaling emergency calls: could do that by signaling emergency sessions:
o using "Resource-Priority" Header in SIP o using "Resource-Priority" Header in SIP
o using Admission-Priority Policy Element in RSVP o using Admission-Priority Policy Element in RSVP
o using Preemption Policy Element in RSVP with: o using Preemption Policy Element in RSVP with:
* setup (Emergency) > defending (Non-Emergency) * setup (Emergency) > defending (Non-Emergency)
* setup (Non-Emergency) <= defending (Emergency) * setup (Non-Emergency) <= defending (Emergency)
If one wants to implement an emergency service based on Call If one wants to implement an emergency service based on Call
Queueing, on "prioritized access to network layer resources", and Queueing, on "prioritized access to network layer resources", and
ensure that "emergency" sessions can partially preempt regular ensure that "emergency" sessions can partially preempt regular
sessions (ie reduce their reservation size), one could do that by sessions (ie reduce their reservation size), one could do that by
signaling emergency calls: signaling emergency sessions:
o using "Resource-Priority" Header in SIP o using "Resource-Priority" Header in SIP
o using Admission-Priority Policy Element in RSVP o using Admission-Priority Policy Element in RSVP
o using Preemption in Policy Element RSVP with: o using Preemption in Policy Element RSVP with:
* setup (Emergency) > defending (Non-Emergency) * setup (Emergency) > defending (Non-Emergency)
* setup (Non-Emergency) <= defending (Emergency) * setup (Non-Emergency) <= defending (Emergency)
 End of changes. 49 change blocks. 
128 lines changed or deleted 153 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/