draft-ietf-tsvwg-emergency-rsvp-15.txt   rfc6401.txt 
TSVWG F. Le Faucheur Internet Engineering Task Force (IETF) F. Le Faucheur
Internet-Draft J. Polk Request for Comments: 6401 J. Polk
Intended status: Standards Track Cisco Category: Standards Track Cisco
Expires: September 9, 2010 K. Carlberg ISSN: 2070-1721 K. Carlberg
G11 G11
March 8, 2010 October 2011
Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority RSVP Extensions for Admission Priority
draft-ietf-tsvwg-emergency-rsvp-15.txt
Abstract Abstract
Some applications require the ability to provide an elevated Some applications require the ability to provide an elevated
probability of session establishment to specific sessions in times of probability of session establishment to specific sessions in times of
network congestion. When supported over the Internet Protocol suite, network congestion. When supported over the Internet Protocol suite,
this may be facilitated through a network layer admission control this may be facilitated through a network-layer admission control
solution that supports prioritized access to resources (e.g., solution that supports prioritized access to resources (e.g.,
bandwidth). These resources may be explicitly set aside for bandwidth). These resources may be explicitly set aside for
prioritized sessions, or may be shared with other sessions. This prioritized sessions, or may be shared with other sessions. This
document specifies extensions to the Resource reSerVation Protocol document specifies extensions to the Resource reSerVation Protocol
(RSVP) that can be used to support such an admission priority (RSVP) that can be used to support such an admission priority
capability at the network layer. capability at the network layer.
Based on current security concerns, these extensions are intended for Based on current security concerns, these extensions are intended for
use in a single administrative domain. use in a single administrative domain.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 9, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6401.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Overview of RSVP extensions and Operations . . . . . . . . . . 5 4. Overview of RSVP Extensions and Operations . . . . . . . . . . 4
4.1. Operations of Admission Priority . . . . . . . . . . . . . 7 4.1. Operations of Admission Priority . . . . . . . . . . . . . 6
5. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 8 5. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 7
5.1. Admission Priority Policy Element . . . . . . . . . . . . 9 5.1. Admission Priority Policy Element . . . . . . . . . . . . 8
5.1.1. Admission Priority Merging Rules . . . . . . . . . . . 10 5.1.1. Admission Priority Merging Rules . . . . . . . . . . . 9
5.2. Application-Level Resource Priority Policy Element . . . . 11 5.2. Application-Level Resource Priority Policy Element . . . . 10
5.2.1. Application-Level Resource Priority Modifying and 5.2.1. Application-Level Resource Priority Modifying and
Merging Rules . . . . . . . . . . . . . . . . . . . . 12 Merging Rules . . . . . . . . . . . . . . . . . . . . 11
5.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12 5.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Use of RSVP Authentication between RSVP neighbors . . . . 14 6.1. Use of RSVP Authentication between RSVP Neighbors . . . . 13
6.2. Use of INTEGRITY object within the POLICY_DATA object . . 14 6.2. Use of INTEGRITY object within the POLICY_DATA Object . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Examples of Bandwidth Allocation Model for Appendix A. Examples of Bandwidth Allocation Model for
Admission Priority . . . . . . . . . . . . . . . . . 19 Admission Priority . . . . . . . . . . . . . . . . . 19
A.1. Admission Priority with Maximum Allocation Model (MAM) . . 20 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 19
A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 24 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 23
A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 27 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 26
Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 30 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Some applications require the ability to provide an elevated Some applications require the ability to provide an elevated
probability of session establishment to specific sessions in times of probability of session establishment to specific sessions in times of
network congestion. network congestion.
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" session establishment requests when include the ability to "queue" session establishment requests when
those can not be immediately honored (in some cases with the notion those can not be immediately honored (in some cases with the notion
of "bumping", or "displacement", of less important session of "bumping", or "displacement", of less important session
establishment requests from that queue). It may include additional establishment requests from that queue). It may include additional
mechanisms such as exemption from certain network management mechanisms such as alternate routing and exemption from certain
controls, and alternate routing. network management controls.
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 (QoS) requirements of that
class. Admission priority may involve setting aside some network traffic class. Admission priority may involve setting aside some
resources (e.g. Bandwidth) out of the engineered capacity limits for network resources (e.g., bandwidth) out of the engineered capacity
the prioritized sessions only. Or alternatively, it may involve limits for the prioritized sessions only. Or alternatively, it may
allowing the prioritized sessions to seize additional resources involve allowing the prioritized sessions to seize additional
beyond the engineered capacity limits applied to normal sessions. resources beyond the engineered capacity limits applied to normal
This document specifies the necessary extensions to support such sessions. This document specifies the necessary extensions to
admission priority when network layer admission control is performed support such admission priority when network-layer admission control
using the Resource reSerVation Protocol (RSVP) ([RFC2205]). is performed using the Resource reSerVation Protocol (RSVP)
[RFC2205].
[RFC3181] specifies the Signaled Preemption Priority Policy Element [RFC3181] specifies the Signaled Preemption Priority Policy Element
that can be signaled in RSVP so that network node may take into that can be signaled in RSVP so that network node may take into
account this policy element in order to preempt some previously account this policy element in order to preempt some previously
admitted low priority sessions in order to make room for a newer, admitted low-priority sessions in order to make room for a newer,
higher priority session. In contrast, this document specifies new higher-priority session. In contrast, this document specifies new
RSVP extensions to increase the probability of session establishment RSVP extensions to increase the probability of session establishment
without preemption of existing sessions. This is achieved by without preemption of existing sessions. This is achieved by
engineered capacity techniques in the form of bandwidth allocation engineered capacity techniques in the form of bandwidth allocation
models. In particular this document specifies two new RSVP Policy models. In particular, this document specifies two new RSVP policy
Elements allowing the admission priority to be conveyed inside RSVP elements allowing the admission priority to be conveyed inside RSVP
signaling messages so that RSVP nodes can enforce selective bandwidth signaling messages so that RSVP nodes can enforce a selective
admission control decision based on the session admission priority. bandwidth admission control decision based on the session admission
Appendix A of this document also provides examples of bandwidth priority. Appendix A of this document also provides examples of
allocation models which can be used by RSVP-routers to enforce such bandwidth allocation models that can be used by RSVP-routers to
admission priority on every link. A given reservation may be enforce such admission priority on every link. A given reservation
signaled with the admission priority extensions specified in the may be signaled with the admission priority extensions specified in
present document, with the preemption priority specified in [RFC3181] the present document, with the preemption priority specified in
or with both. [RFC3181], or with both.
1.1. Terminology 1.1. 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 definitions of a few key terms are 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): The PDP local to the network
element. element.
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. Applicability Statement 2. Applicability Statement
A subset of RSVP messages are signaled with the Router Alert Option A subset of RSVP messages are signaled with the Router Alert Option
(RAO)([RFC2113],[RFC2711]). The security aspects and common (RAO) ([RFC2113], [RFC2711]). The security aspects and common
practices around the use of the current IP Router Alert option and practices around the use of the current IP Router Alert Option and
consequences on the use of IP Router Alert by applications such as consequences on the use of IP Router Alert by applications such as
RSVP are discussed in [I-D.rahman-rtg-router-alert-considerations]. RSVP are discussed in [RFC6398]. Based on those, the extensions
Based on those, the extensions defined in this document are intended defined in this document are intended for use within a single
for use within a single administrative domain. Thus, in particular, administrative domain. Thus, in particular, the extensions defined
the extensions defined in this document are not intended for use end in this document are not intended for end-to-end use on the Internet.
to end on the Internet.
3. Requirements Language 3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
4. Overview of RSVP extensions and Operations 4. Overview of RSVP Extensions and Operations
Let us consider the case where a session requires elevated Let us consider the case where a session requires elevated
probability of establishment, and more specifically that the probability of establishment, and more specifically that the
preference to be granted to this session is in terms of network layer preference to be granted to this session is in terms of network-layer
"admission priority" (as opposed to preference granted through "admission priority" (as opposed to preference granted through
preemption of existing sessions). By "admission priority" we mean preemption of existing sessions). By "admission priority" we mean
allowing the priority session to seize network layer resources from allowing the priority session to seize network-layer resources from
the engineered capacity that has been set-aside for priority sessions the engineered capacity that has been set aside for priority sessions
(and not made available to normal sessions), or alternatively (and not made available to normal sessions) or, alternatively,
allowing the priority session to seize additional resources beyond allowing the priority session to seize additional resources beyond
the engineered capacity limits applied to normal sessions. the engineered capacity limits applied to normal sessions.
Session establishment can be made conditional on resource-based and Session establishment can be made conditional on resource-based and
policy-based network layer admission control achieved via RSVP policy-based network-layer admission control achieved via RSVP
signaling. In the case where the session control protocol is SIP, signaling. In the case where the session control protocol is SIP,
the use of RSVP-based admission control in conjunction with SIP is the use of RSVP-based admission control in conjunction with SIP is
specified in [RFC3312]. 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 prioritized aware of the application-level priority requirements of prioritized
sessions. For example, considering the case where the session sessions. For example, considering the case where the session
control protocol is SIP, the SIP user agents may be made aware of the control protocol is SIP, the SIP user agents may be made aware of the
resource priority requirements of a given session using the resource priority requirements of a given session using the
"Resource-Priority" header mechanism specified in [RFC4412]. The "Resource-Priority" header mechanism specified in [RFC4412]. The
end-devices involved in the upper-layer session establishment simply end-devices involved in the upper-layer session establishment simply
need to copy the application-level resource priority requirements need to copy the application-level resource priority requirements
(e.g. As communicated in SIP "Resource-Priority" header) inside the (e.g., as communicated in the SIP "Resource-Priority" header) inside
new RSVP Application-Level Resource Priority Policy Element defined the new RSVP Application-Level Resource Priority Policy Element
in this document. 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 a mapped/remapped into a different RSVP "admission priority" at a
policy boundary based on the policy applicable in that policy area. policy boundary based on the policy applicable in that policy area.
In a typical model (see [RFC2753]) where PDPs control PEPs at the In a typical model (see [RFC2753]) where PDPs control PEPs at the
periphery of the policy area (e.g. On the first hop router), PDPs periphery of the policy area (e.g., on the first hop router), 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 prioritized session into an Element and map the requirement of the prioritized session into an
RSVP "admission priority" level. Then, PDPs would convey this RSVP "admission priority" level. Then, PDPs would convey this
information inside the new Admission Priority Policy Element defined information inside the new Admission Priority Policy Element defined
in this document. This way, the RSVP admission priority can be in this document. This way, the RSVP admission priority can be
communicated to downstream PEPs (i.e. RSVP Routers) of the same communicated to downstream PEPs (i.e., RSVP routers) of the same
policy domain, which have LPDPs but no controlling PDP. In turn, policy domain that have LPDPs but no controlling PDP. In turn, this
this means the necessary RSVP Admission priority can be enforced at means the necessary RSVP Admission priority can be enforced at every
every RSVP hop, including all the (possibly many) hops which do not RSVP hop, including all the (possibly many) hops that do not have any
have any understanding of Application-Level Resource Priority understanding of application-level resource priority semantics. It
semantics. It is not expected that the RSVP Application-Level is not expected that the RSVP Application-Level Resource Priority
Resource Priority Header Policy Element would be taken into account Header Policy Element would be taken into account at RSVP hops within
at RSVP-hops within a given policy area. It is expected to be used a given policy area. It is expected to be used at policy area
at policy area boundaries only in order to set/reset the RSVP boundaries only in order to set/reset the RSVP Admission Priority
Admission Priority Policy Element. Policy Element.
Remapping by PDPs of the Admission Priority Policy Element from the Remapping by PDPs of the Admission Priority Policy Element from the
Application-Level Resource Priority Policy Element may also be used Application-Level Resource Priority Policy Element may also be used
at boundaries with other signaling protocols, such as the NSIS at boundaries with other signaling protocols, such as the NSIS
Signaling Layer Protocol (NSLP) for QoS Signaling Signaling Layer Protocol (NSLP) for QoS Signaling [RFC5974].
([I-D.ietf-nsis-qos-nslp]).
As can be observed, the framework described above for mapping/ As can be observed, the framework described above for mapping/
remapping application level resource priority requirements into an remapping application-level resource priority requirements into an
RSVP admission priority can also be used together with [RFC3181] for RSVP admission priority can also be used together with [RFC3181] for
mapping/remapping application level resource priority requirements mapping/remapping application-level resource priority requirements
into an RSVP preemption priority (when preemption is indeed deemed into an RSVP preemption priority (when preemption is indeed deemed
necessary by the prioritized session handling policy). In that case, necessary by the prioritized session handling policy). In that case,
when processing the RSVP Application-Level Resource Priority Policy when processing the RSVP Application-Level Resource Priority Policy
Element, the PDPs at policy boundaries (or between various QoS Element, the PDPs at policy boundaries (or between various QoS
signaling protocols) can map it into an RSVP "preemption priority" signaling protocols) can map it into an RSVP "preemption priority"
information. This Preemption priority information comprises a setup information. This preemption priority information comprises a setup
preemption level and a defending preemption priority level that can preemption level and a defending preemption priority level that can
then be encoded inside the Preemption Priority Policy Element of then be encoded inside the Preemption Priority Policy Element of
[RFC3181]. [RFC3181].
Appendix B provides examples of various hypothetical policies for Appendix B provides examples of various hypothetical policies for
prioritized session handling, some of them involving admission prioritized session handling, some of them involving admission
priority, some of them involving both admission priority and priority, some of them involving both admission priority and
preemption priority. Appendix B also identifies how the Application- preemption priority. Appendix B also identifies how the application-
Level Resource Priority needs to be mapped into RSVP policy elements level resource priority needs to be mapped into RSVP policy elements
by the PDPs to realize these policies. by the PDPs to realize these policies.
4.1. Operations of Admission Priority 4.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 allows admission bandwidth to be allocated preferentially to
prioritized sessions. Multiple models of bandwidth allocation MAY be prioritized sessions. Multiple models of bandwidth allocation MAY be
used to that end. used to that end.
A number of bandwidth allocation models have been defined in the IETF A number of bandwidth allocation models have been defined in the IETF
for allocation of bandwidth across different classes of traffic for allocation of bandwidth across different classes of traffic
trunks in the context of Diffserv-aware MPLS Traffic Engineering. trunks in the context of Diffserv-aware MPLS Traffic Engineering.
Those include the Maximum Allocation Model (MAM) defined in Those include the Maximum Allocation Model (MAM) defined in
[RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127] and [RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127], and
the Maximum Allocation model with Reservation (MAR) defined in the Maximum Allocation model with Reservation (MAR) defined in
[RFC4126]. These same models MAY however be applied for allocation [RFC4126]. However, these same models MAY be applied for allocation
of bandwidth across different levels of admission priority as defined of bandwidth across different levels of admission priority as defined
in this document. Appendix A provides an illustration of how these in this document. Appendix A provides an illustration of how these
bandwidth allocation models can be applied for such purposes and also bandwidth allocation models can be applied for such purposes and also
introduces an additional bandwidth allocation model that we term the introduces an additional bandwidth allocation model that we term the
Priority Bypass Model (PrBM). It is important to note that the Priority Bypass Model (PrBM). It is important to note that the
models described and illustrated in Appendix A are only informative models described and illustrated in Appendix A are only informative
and do not represent a recommended course of action. and do not represent a recommended course of action.
We can see in these examples how the RSVP Admission Priority can be We can see in these examples how the RSVP Admission Priority can be
used by RSVP routers to influence their admission control decision used by RSVP routers to influence their admission control decision
(for example by determining which bandwidth pool is to be used by (for example, by determining which bandwidth pool is to be used by
RSVP for performing its bandwidth allocation) and therefore to RSVP for performing its bandwidth allocation) and therefore to
increase the probability of reservation establishment. In turn, this increase the probability of reservation establishment. In turn, this
increases the probability of application level session establishment increases the probability of application-level session establishment
for the corresponding session. for the corresponding session.
5. New Policy Elements 5. New Policy Elements
The Framework document for policy-based admission control [RFC2753] The Framework document for policy-based admission control [RFC2753]
describes the various components that participate in policy decision describes the various components that participate in policy decision
making (i.e., PDP, PEP and LPDP). making (i.e., PDP, PEP, and LPDP).
As described in Section 4 of the present document, the Application- As described in Section 4 of the present document, the Application-
Level Resource Priority Policy Element and the Admission Priority Level Resource Priority Policy Element and the Admission Priority
Policy Element serve different roles in this framework: Policy Element serve different roles in this framework:
o the Application-Level Resource Priority Policy Element conveys o The Application-Level Resource Priority Policy Element conveys
application level information and is processed by PDPs application-level information and is processed by PDPs.
o the emphasis of Admission Priority Policy Element is to be simple, o The emphasis of Admission Priority Policy Element is to be simple,
stateless, and light-weight such that it can be processed stateless, and lightweight such that it can be processed
internally within a node's LPDP. It can then be enforced internally within a node's LPDP. It can then be enforced
internally within a node's PEP. It is set by PDPs based on internally within a node's PEP. It is set by PDPs based on
processing of the Application-Level Resource Priority Policy processing of the Application-Level Resource Priority Policy
Element. Element.
[RFC2750] defines extensions for supporting generic policy based [RFC2750] defines extensions for supporting generic policy-based
admission control in RSVP. These extensions include the standard admission control in RSVP. These extensions include the standard
format of POLICY_DATA objects and a description of RSVP handling of format of POLICY_DATA objects and a description of RSVP handling of
policy events. policy events.
The POLICY_DATA object contains one or more of Policy Elements, each The POLICY_DATA object contains one or more policy elements, each
representing a different (and perhaps orthogonal) policy. As an representing a different (and perhaps orthogonal) policy. As an
example, [RFC3181] specifies the Preemption Priority Policy Element. example, [RFC3181] specifies the Preemption Priority Policy Element.
This document defines two new Policy Elements called: This document defines two new policy elements called:
o the Admission Priority Policy Element o the Admission Priority Policy Element
o the Application-Level Resource Priority Policy Element o the Application-Level Resource Priority Policy Element
5.1. Admission Priority Policy Element 5.1. Admission Priority Policy Element
The format of the Admission Priority policy element is as shown in The format of the Admission Priority Policy Element is as shown in
Figure 1: Figure 1:
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 = ADMISSION_PRI | | Length | P-Type = ADMISSION_PRI |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved | | Flags | M. Strategy | Error Code | Reserved |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Reserved |Adm. Priority| | Reserved |Adm. Priority|
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Figure 1: Admission Priority Policy Element Figure 1: Admission Priority Policy Element
where: where:
o Length: 16 bits o Length: 16 bits
* Always 12. The overall length of the policy element, in bytes. * Always 12. The overall length of the policy element, in bytes.
o P-Type: 16 bits o P-Type: 16 bits
* ADMISSION_PRI = To be allocated by IANA (see "IANA * ADMISSION_PRI = 0x05 (see the "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 (applicable to multicast flows) o Merge Strategy: 8 bits (applicable to multicast flows)
* values are defined by corresponding registry maintained by IANA * values are defined in the corresponding registry maintained by
(see "IANA Considerations" section) IANA (see the "IANA Considerations" section).
o Error code: 8 bits (applicable to multicast flows) o Error code: 8 bits (applicable to multicast flows)
* values are defined by corresponding registry maintained by IANA * values are defined in the corresponding registry maintained by
(see "IANA Considerations" section) IANA (see the "IANA Considerations" section).
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
session completion to selected flows. Higher values represent session completion to selected flows. Higher values represent
higher priority. Bandwidth allocation models such as those higher priority. Bandwidth allocation models such as those
described in Appendix A are to be used by the RSVP router to described in Appendix A are to be used by the RSVP router to
achieve increased probability of session establishment. The achieve increased probability of session establishment. The
admission priority value effectively indicates which bandwidth admission priority value effectively indicates which bandwidth
constraint(s) of the bandwidth constraint model in use is(are) constraint(s) of the bandwidth constraint model in use is/are
applicable to admission of this RSVP reservation. applicable to 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
skipping to change at page 10, line 43 skipping to change at page 9, line 43
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 applies to priority in case of merging of reservations. As merging applies to
multicast, this section also applies to multicast sessions. multicast, this section also applies to multicast sessions.
The rules for merging Admission Priority Policy Elements are defined The rules for merging Admission Priority Policy Elements are defined
by the value encoded inside the Merge Strategy field in accordance by the value encoded inside the Merge Strategy field in accordance
with the corresponding IANA registry. This registry applies both to with the corresponding IANA registry. This registry applies both to
the Merge Strategy field of the Admission Priority Policy Element the Merge Strategy field of the Admission Priority Policy Element
defined in the present document and to the Merge Strategy field of defined in the present document and to the Merge Strategy field of
the Preemption Priority Policy Elements defined in [RFC3181]. The the Preemption Priority Policy Element defined in [RFC3181]. The
registry initially contains the values already defined in [RFC3181] registry initially contains the values already defined in [RFC3181]
(see "IANA Considerations" section). (see the "IANA Considerations" section).
The only difference from [RFC3181] is that this document does not The only difference from [RFC3181] is that this document does not
recommend a given merge strategy over the others for Admission recommend a given merge strategy over the others for Admission
Priority, while [RFC3181] recommends the first of these merge Priority, while [RFC3181] recommends the first of these merge
strategies for Preemption Priority. Note that with the Admission strategies for Preemption Priority. Note that with the Admission
Priority (as is the case with the Preemption Priority), "Take highest Priority (as is the case with the Preemption Priority), "take highest
priority" translates into "take the highest numerical value". priority" translates into "take the highest numerical value".
5.2. Application-Level Resource Priority Policy Element 5.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 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// ALRP List // // ALRP List //
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Figure 2: Application-Level Resource Priority Policy Element Figure 2: Application-Level Resource Priority Policy Element
where: where:
o Length: o Length:
* The length of the policy element (including the Length and * The length of the policy element (including the Length and
P-Type) is in number of octets (MUST be a multiple of 4) and P-Type) is in number of octets (MUST be a multiple of 4) and
indicates the end of the ALRP list. indicates the end of the ALRP list.
o P-Type: 16 bits o P-Type: 16 bits
* APP_RESOURCE_PRI = To be allocated by IANA (see "IANA * APP_RESOURCE_PRI = 0x06 (see the "IANA Considerations"
Considerations" section) section).
o ALRP List: o ALRP List:
* List of ALRP where each ALRP is encoded as shown in Figure 3. * List of ALRPs where each ALRP is encoded as shown in Figure 3.
ALRP: ALRP:
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
+---------------------------+-------------+-------------+ +---------------------------+-------------+-------------+
| ALRP Namespace | Reserved |ALRP Value | | ALRP Namespace | Reserved |ALRP Value |
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Figure 3: Application-Level Resource Priority Figure 3: Application-Level Resource Priority
where: where:
o ALRP Namespace (Application-Level Resource Priority Namespace): 16 o ALRP Namespace (Application-Level Resource Priority Namespace): 16
bits (unsigned) bits (unsigned)
* Contains a numerical value identifying the namespace of the * Contains a numerical value identifying the namespace of the
application-level resource priority. This value is encoded as application-level resource priority. This value is encoded as
per the "Resource Priority Namespaces" IANA registry. (See per the "Resource Priority Namespaces" IANA registry. (See the
IANA Considerations section for the request to IANA to extend "IANA Considerations" section; IANA has extended the registry
the registry to include this numerical value). to include this numerical value).
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 ALRP Value: (Application-Level Resource Priority Value): 8 bits o ALRP Value (Application-Level Resource Priority Value): 8 bits
(unsigned) (unsigned)
* Contains the priority value within the namespace of the * Contains the priority value within the namespace of the
application-level resource priority. This value is encoded as application-level resource priority. This value is encoded as
per the "Resource Priority Priority-Value" IANA registry. (See per the "Resource Priority Priority-Value" IANA registry. (See
IANA Considerations section for the request to IANA to extend the "IANA Considerations" section; IANA has extended the
the registry to include this numerical value). registry to include this numerical value).
5.2.1. Application-Level Resource Priority Modifying and Merging Rules 5.2.1. Application-Level Resource Priority Modifying and Merging Rules
When POLICY_DATA objects are protected by integrity, LPDPs should not When POLICY_DATA objects are protected by integrity, LPDPs should not
attempt to modify them. They MUST be forwarded as-is to ensure their attempt to modify them. They MUST be forwarded without modification
security envelope is not invalidated. to ensure their security envelope is not invalidated.
In case of multicast, when POLICY_DATA objects are not protected by In case of multicast, when POLICY_DATA objects are not protected by
integrity, LPDPs MAY merge incoming Application-Level Resource integrity, LPDPs MAY merge incoming Application-Level Resource
Priority elements to reduce their size and number. When they do Priority Elements to reduce their size and number. When they do
merge those, LPDPs MUST do so according to the following rule: merge those elements, LPDPs MUST do so according to the following
rule:
o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST
contain all the ALRPs appearing in the ALRP List of an incoming contain all the ALRPs appearing in the ALRP List of an incoming
APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than
once. In other words, the outgoing ALRP List is the union of the once. In other words, the outgoing ALRP List is the union of the
incoming ALRP Lists that are merged. incoming ALRP Lists that are merged.
As merging applies to Multicast, this rule also applies to Multicast As merging applies to multicast, this rule also applies to multicast
sessions. sessions.
5.3. Default Handling 5.3. Default Handling
As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes As specified in Section 4.2 of [RFC2750], Policy Ignorant Nodes
(PINs) implement a default handling of POLICY_DATA objects ensuring (PINs) implement a default handling of POLICY_DATA objects ensuring
that those objects can traverse PIN nodes in transit from one PEP to that those objects can traverse PINs in transit from one PEP to
another. This applies to the situations where POLICY_DATA objects another. This applies to the situations where POLICY_DATA objects
contain the Admission Priority Policy Element and the ALRP Policy contain the Admission Priority Policy Element and the ALRP Policy
Element specified in this document, so that those can traverse PIN Element specified in this document, so that those objects can
nodes. traverse PINs.
Section 4.2 of [RFC2750] also defines a similar default behavior for Section 4.2 of [RFC2750] also defines a similar default behavior for
policy-capable nodes that do not recognized a particular Policy policy-capable nodes that do not recognize a particular policy
Element. This applies to the Admission Priority Policy Element and element. This applies to the Admission Priority Policy Element and
the ALRP Policy Element specified in this document, so that those can the ALRP Policy Element specified in this document, so that those
traverse policy-capable nodes that do not support these extensions elements can traverse policy-capable nodes that do not support these
defined in the present document. extensions defined in the present document.
6. Security Considerations 6. Security Considerations
As this document defines extensions to RSVP, the security As this document defines extensions to RSVP, the security
considerations of RSVP apply. Those are discussed in [RFC2205], considerations of RSVP apply. Those are discussed in [RFC2205],
[RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. Approaches [RFC4230], and [RFC6411]. Approaches for addressing those concerns
for addressing those concerns are discussed further below. are discussed further below.
A subset of RSVP messages are signaled with the Router Alert Option A subset of RSVP messages are signaled with the Router Alert Option
(RAO)(,[RFC2711]). The security aspects and common practices around (RAO) ([RFC2113], [RFC2711]). The security aspects and common
the use of the current IP Router Alert option and consequences on the practices around the use of the current IP Router Alert Option and
use of IP Router Alert by applications such as RSVP are discussed in consequences on the use of IP Router Alert by applications such as
[I-D.rahman-rtg-router-alert-considerations]. As discussed in RSVP are discussed in [RFC6398]. As discussed in Section 2, the
Section 2, the extensions defined in this document are intended for extensions defined in this document are intended for use within a
use within a single administrative domain. single administrative domain.
[I-D.rahman-rtg-router-alert-considerations] discusses router alert [RFC6398] discusses router alert protection approaches for service
protection approaches for Service Providers. These approaches can be providers. These approaches can be used to protect a given network
used to protect a given network against the potential risks against the potential risks associated with the leaking of router
associated with the leaking of router alert packets resulting from alert packets resulting from the use of the present extensions in
the use of the present extensions in another domain. Also, where another domain. Also, where RSVP is not used, by simply not enabling
RSVP is not used, by simply not enabling RSVP on the routers of a RSVP on the routers of a given network, generally that network can
given network, that network can generally isolate itself from any isolate itself from any RSVP signaling that may leak from another
RSVP signaling that may leak from another network that uses the network that uses the present extensions (since the routers will then
present extensions (since the routers will then typically ignore RSVP typically ignore RSVP messages). Where RSVP is to be used internally
messages). Where RSVP is to be used internally within a given within a given network, the network operator can activate, on the
network, the network operator can activate, on the edge of his edge of his network, mechanisms that either tunnel or, as a last
network, mechanisms that either tunnel or drop incoming RSVP messages resort, drop incoming RSVP messages in order to protect the given
in order to protect the given network from RSVP signaling that may network from RSVP signaling that may leak from another network that
leak from another network that uses the present extensions. uses the present extensions.
The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in
this document are signaled by RSVP through encapsulation in a Policy this document are signaled by RSVP through encapsulation in a
Data object as defined in [RFC2750]. Therefore, like any other POLICY_DATA object as defined in [RFC2750]. Therefore, like any
Policy Elements, their integrity can be protected as discussed in other policy elements, their integrity can be protected as discussed
section 6 of [RFC2750] by two optional security mechanisms. The in Section 6 of [RFC2750] by two optional security mechanisms. The
first mechanism relies on RSVP Authentication as specified in first mechanism relies on RSVP authentication as specified in
[RFC2747] and [RFC3097] to provide a chain of trust when all RSVP [RFC2747] and [RFC3097] to provide a chain of trust when all RSVP
nodes are policy capable. With this mechanism, the INTEGRITY object nodes are policy capable. With this mechanism, the INTEGRITY object
is carried inside RSVP messages. The second mechanism relies on the is carried inside RSVP messages. The second mechanism relies on the
INTEGRITY object within the POLICY_DATA object to guarantee integrity INTEGRITY object within the POLICY_DATA object to guarantee integrity
between RSVP Policy Enforcement Points (PEPs) that are not RSVP between RSVP PEPs that are not RSVP neighbors.
neighbors.
6.1. Use of RSVP Authentication between RSVP neighbors 6.1. Use of RSVP Authentication between RSVP Neighbors
RSVP authentication can be used between RSVP neighbors that are RSVP authentication can be used between RSVP neighbors that are
policy capable. RSVP Authentication (defined in [RFC2747] and policy capable. RSVP authentication (defined in [RFC2747] and
[RFC3097]) SHOULD be supported by an implementation of the present [RFC3097]) SHOULD be supported by an implementation of the present
document. document.
With RSVP authentication, the RSVP neighbors use shared keys to With RSVP authentication, the RSVP neighbors use shared keys to
compute the cryptographic signature of the RSVP message. compute the cryptographic signature of the RSVP message. [RFC6411]
[I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key discusses key types and key provisioning methods as well as their
provisioning methods as well as their respective applicability. respective applicabilities.
6.2. Use of INTEGRITY object within the POLICY_DATA object 6.2. Use of INTEGRITY object within the POLICY_DATA Object
The INTEGRITY object within the POLICY_DATA object can be used to The INTEGRITY object within the POLICY_DATA object can be used to
guarantee integrity between non-neighboring RSVP PEPs. This is guarantee integrity between non-neighboring RSVP PEPs. This is
useful only when some RSVP nodes are Policy Ignorant Nodes (PINs). useful only when some RSVP nodes are Policy Ignorant Nodes (PINs).
The INTEGRITY object within the POLICY_DATA object MAY be supported The INTEGRITY object within the POLICY_DATA object MAY be supported
by an implementation of the present document. by an implementation of the present document.
Details for computation of the content of the INTEGRITY object can be Details for computation of the content of the INTEGRITY object can be
found in Appendix B of [RFC2750]. This states that the Policy found in Appendix B of [RFC2750]. This states that the Policy
Decision Point (PDP), at its discretion, and based on destination Decision Point (PDP), at its discretion, and based on the destination
PEP/PDP or other criteria, selects an Authentication Key and the hash PEP/PDP or other criteria, selects an Authentication Key and the hash
algorithm to be used. Keys to be used between PDPs can be algorithm to be used. Keys to be used between PDPs can be
distributed manually or via standard key management protocol for distributed manually or via a standard key management protocol for
secure key distribution. secure key distribution.
Note that where non-RSVP hops may exist in between RSVP hops, as well Note that where non-RSVP hops may exist in between RSVP hops, as well
as where RSVP capable Policy Ignorant Nodes (PINs) may exist in as where RSVP-capable PINs may exist in between PEPs, it may be
between PEPs, it may be difficult for the PDP to determine what is difficult for the PDP to determine what is the destination PDP for a
the destination PDP for a POLICY_DATA object contained in some RSVP POLICY_DATA object contained in some RSVP messages (such as a Path
messages (such as a Path message). This is because in those cases message). This is because in those cases the next PEP is not known
the next PEP is not known at the time of forwarding the message. In at the time of forwarding the message. In this situation, key shared
this situation, key shared across multiple PDPs may be used. This is across multiple PDPs may be used. This is conceptually similar to
conceptually similar to the use of key shared across multiple RSVP the use of a key shared across multiple RSVP neighbors as discussed
neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. in [RFC6411]. We observe also that this issue may not exist in some
We observe also that this issue may not exist in some deployment deployment scenarios where a single (or low number of) PDP is used to
scenarios where a single (or low number of) PDP is used to control control all the PEPs of a region (such as an administrative domain).
all the PEPs of a region (such as an administrative domain). In such In such scenarios, it may be easy for a PDP to determine what is the
scenarios, it may be easy for a PDP to determine what is the next hop next-hop PDP, even when the next-hop PEP is not known, simply by
PDP, even when the next hop PEP is not known, simply by determining determining what is the next region that will be traversed (say,
what is the next region that will be traversed (say based on the based on the destination address).
destination address).
7. IANA Considerations 7. IANA Considerations
As specified in [RFC2750], Standard RSVP Policy Elements (P-type As specified in [RFC2750], standard RSVP policy elements (P-type
values) are to be assigned by IANA as per "IETF Consensus" policy values) are to be assigned by IANA as per "IETF Consensus" policy as
following the policies outlined in [RFC2434] (this policy is now outlined in [RFC2434] (this policy is now called "IETF Review" as per
called "IETF Review" as per [RFC5226]) . [RFC5226]) .
IANA needs to allocate two P-Types from the Standard RSVP Policy IANA has allocated two P-Types from the standard RSVP policy element
Element range: range:
o one P-Type to the Admission Priority Policy Element o 0x05 ADMISSION_PRI for the Admission Priority Policy Element
o one P-Type to the Application-Level Resource Priority Policy o 0x06 APP_RESOURCE_PRI for the Application-Level Resource Priority
Element. Policy Element
In Section 5.1, the present document defines a Merge Strategy field In Section 5.1, the present document defines a Merge Strategy field
inside the Admission Priority policy element. This registry is to be inside the Admission Priority Policy Element. This registry is to be
specified as also applicable to the Merge Strategy field of the specified as also applicable to the Merge Strategy field of the
Preemption Priority Policy Elements defined in [RFC3181]. Since it Preemption Priority Policy Elements defined in [RFC3181]. Since it
is conceivable that, in the future, values are added to the registry is conceivable that, in the future, values will be added to the
that only apply to the Admission Priority Policy Element or to the registry that only apply to the Admission Priority Policy Element or
Preemption Priority Policy Element (but not to both), IANA needs to to the Preemption Priority Policy Element (but not to both), IANA has
list the applicable documents for each value. IANA needs to allocate listed the applicable documents for each value. IANA has allocated
the following values:: the following values:
o 0: Reserved o 0: Reserved
o 1: Take priority of highest QoS [RFC3181] [RFC-XXX] o 1: Take priority of highest QoS [RFC3181] [RFC6401]
o 2: Take highest priority [RFC3181] [RFC-XXX] o 2: Take highest priority [RFC3181] [RFC6401]
o 3: Force Error on heterogeneous merge [RFC3181] [RFC-XXX] o 3: Force Error on heterogeneous merge [RFC3181] [RFC6401]
Following the policies outlined in [RFC5226], numbers in the range Following the policies outlined in [RFC5226], numbers in the range
4-127 are allocated according to the "IETF Review" policy, numbers in 0-127 are allocated according to the "IETF Review" policy, numbers in
the range 128-240 as "First Come First Served" and numbers between the range 128-240 as "First Come First Served", and numbers in the
241-255 are reserved for "Private Use". range 241-255 are "Reserved for Private Use".
In Section 5.1, the present document defines an Error Code field In Section 5.1, the present document defines an Error Code field
inside the Admission Priority policy element. IANA needs to create a inside the Admission Priority Policy Element. IANA has created a
registry for this field and allocate the following values: registry for this field and allocate the following values:
o 0: NO_ERROR Value used for regular ADMISSION_PRI elements o 0: NO_ERROR - Value used for regular ADMISSION_PRI elements
o 2: HETEROGENEOUS This element encountered heterogeneous merge o 2: HETEROGENEOUS - This element encountered heterogeneous merge
Following the policies outlined in [RFC5226], numbers in the range Following the policies outlined in [RFC5226], numbers in the range
3-127 are allocated according to the "IETF Review" policy, numbers in 0-127 are allocated according to the "IETF Review" policy, numbers in
the range 128-240 as "First Come First Served" and numbers between the range 128-240 as "First Come First Served", and numbers in the
241-255 are reserved for "Private Use". Value 1 is Reserved (for range 241-255 are "Reserved for Private Use". Value 1 is Reserved
consistency with [RFC3181] Error Code values). (for consistency with [RFC3181] Error Code values).
The present document defines an ALRP Namespace field in Section 5.2 The present document defines an ALRP Namespace field in Section 5.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 namespaces. That registry has been updated to
currently allocate a numerical value to each namespace. Hence, this allocate a numerical value to each namespace. To be exact, the IANA
document requests the IANA to extend the Resource-Priority Namespaces has extended the Resource-Priority Namespaces registry in the
registry in the following ways: following ways:
o a new column should be added to the registry o A new column has been added to the registry.
o the title of the new column should be "Namespace Numerical Value o The title of the new column is "Namespace Numerical Value *".
*"
o in the Legend, add a line saying "Namespace Numerical Value = the o In the Legend, a line has been added stating "Namespace Numerical
unique numerical value identifying the namespace" Value = the unique numerical value identifying the namespace".
o add a line at the bottom of the registry stating the following "* o In the Legend, a line has been added stating "* : [RFC6401]".
: [RFCXXX] " where XXX is the RFC number of the present document
o allocate an actual numerical value to each namespace in the o An actual numerical value has been allocated to each namespace in
registry and state that value in the new "Namespace numerical the registry and is listed in the new "Namespace Numerical Value
Value *" column. *" column.
A numerical value should be allocated immediately by IANA to all A numerical value has been allocated by IANA for all existing
existing namespaces. Then, in the future, IANA should automatically namespaces. In the future, IANA should automatically allocate a
allocate a numerical value to any new namespace added to the numerical value to any new namespace added to the registry.
registry.
The present document defines an ALRP Priority field in Section 5.2 The present document defines an ALRP Priority field in Section 5.2
that contains a numerical value identifying the actual application- that contains a numerical value identifying the actual application-
level resource priority within the application-level resource level resource priority within the application-level resource
priority namespace. The IANA already maintains the Resource-Priority priority namespace. The IANA already maintains the Resource-Priority
Priority-values registry (under the SIP Parameters) listing all such Priority-Values registry (under the SIP Parameters) listing all such
priorities. However, that registry does not currently allocate a priorities. That registry has been updated to allocate a numerical
numerical value to each priority-value. Hence, this document value to each priority-value. To be exact, the IANA has extended the
requests the IANA to extend the Resource-Priority Priority-Values Resource-Priority Priority-Values registry in the following ways:
registry in the following ways:
o for each namespace, the registry should be structured with two o For each namespace, the registry is structured with two columns.
columns
o the title of the first column should read "Priority Values (least o The title of the first column is "Priority Values (least to
to greatest)" greatest)".
o the first column should list all the values currently defined in o The first column lists all the values currently defined in the
the registry (e.g. For the drsn namespace: "routine", "priority", registry (e.g., for the drsn namespace: "routine", "priority",
"immediate", "flash", "flash-override", "flash-override-override" "immediate", "flash", "flash-override", and "flash-override-
for the drsn namespace) override")
o the title of the second column should read "Priority Numerical o The title of the second column is "Priority Numerical Value *".
Value *"
o At the bottom of the registry, add a "Legend" with a line saying o At the bottom of the registry, a "Legend" has been added with a
"Priority Numerical Value = the unique numerical value identifying line stating "Priority Numerical Value = the unique numerical
the priority within a namespace" value identifying the priority within a namespace".
o add a line at the bottom of the registry stating the following "* o In the Legend, a line has been added stating "* : [RFC6401]".
: [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 An actual numerical value has been allocated to each priority
the new "Priority Numerical Value *" column. value and is listed in the new "Priority Numerical Value *"
column.
A numerical value should be allocated immediately by IANA to all A numerical value has been allocated by IANA to all existing
existing priorities. Then, in the future, IANA should automatically priorities. In the future, IANA should automatically allocate a
allocate a numerical value to any new namespace added to the numerical value to any new namespace added to the registry. The
registry. The numerical value must be unique within each namespace. numerical value must be unique within each namespace. Within each
For the initial allocation, within each namespace, values should be namespace, values should be allocated in decreasing order ending with
allocated in decreasing order ending with 0 (so that the greatest 0 (so that the greatest priority is always allocated value 0). For
priority is always allocated value 0). For example, in the drsn example, in the drsn namespace, "routine" is allocated numerical
namespace, "routine" would be allocated numerical value 5 and "flash- value 5, and "flash-override-override" is allocated numerical value
override-override" would be allocated numerical value 0. 0.
8. Acknowledgments 8. 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 the 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. Ron Bonica, Magnus Westerlund, Cullen Jennings, for this document. Ron Bonica, Magnus Westerlund, Cullen Jennings,
Ross Callon and Tim Polk provided specific guidance for the Ross Callon and Tim Polk provided specific guidance for the
applicability statement of the mechanisms defined in this document. applicability statement of the mechanisms defined in this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 18, line 15 skipping to change at page 17, line 23
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC
RFC 2750, January 2000. 2750, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
April 2001. April 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001. RFC 3181, October 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", Priority for the Session Initiation Protocol (SIP)", RFC
RFC 4412, February 2006. 4412, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
9.2. Informative References [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, October 2011.
[I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), January 2010.
[I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), June 2009.
[I-D.rahman-rtg-router-alert-considerations] 9.2. Informative References
Faucheur, F., "IP Router Alert Considerations and Usage",
draft-rahman-rtg-router-alert-considerations-03 (work in
progress), October 2009.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
February 1997. 1997.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999. RFC 2711, October 1999.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, for Policy-based Admission Control", RFC 2753, January
January 2000. 2000.
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic Constraints Model for Diffserv-aware MPLS Traffic
Engineering", RFC 4125, June 2005. Engineering", RFC 4125, June 2005.
[RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth [RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic Constraints Model for Diffserv-aware MPLS Traffic
Engineering & Performance Comparisons", RFC 4126, Engineering & Performance Comparisons", RFC 4126, June
June 2005. 2005.
[RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints [RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering", Model for Diffserv-aware MPLS Traffic Engineering", RFC
RFC 4127, June 2005. 4127, June 2005.
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
Properties", RFC 4230, December 2005. Properties", RFC 4230, December 2005.
[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol
(RSVP) Extension for the Reduction of Bandwidth of a
Reservation Flow", RFC 4495, May 2006.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-Service
Signaling", RFC 5974, October 2010.
[RFC6411] Behringer, M., Le Faucheur, F., and B. Weis,
"Applicability of Keying Methods for RSVP Security", RFC
6411, October 2011.
Appendix A. Examples of Bandwidth Allocation Model for Admission Appendix A. Examples of Bandwidth Allocation Model for Admission
Priority Priority
Sections A.1 and A.2 respectively illustrate how the Maximum Appendices A.1 and A.2 respectively illustrate how the Maximum
Allocation Model (MAM) ([RFC4125]) and the Russian Dolls Model (RDM) Allocation Model (MAM) [RFC4125] and the Russian Dolls Model (RDM)
([RFC4127]) can be used for support of admission priority. The [RFC4127] can be used for support of admission priority. The Maximum
Maximum Allocation model with Reservation (MAR) ([RFC4126]) could Allocation model with Reservation (MAR) [RFC4126] can also be used in
also be used in a similar manner for support of admission priority. a similar manner for support of admission priority. Appendix A.3
Section A.3 illustrates how a simple "Priority Bypass Model" can also illustrates how a simple "Priority Bypass Model" can also be used for
be used for support of admission priority. support of admission priority.
For simplicity, operations with only a single "priority" level For simplicity, operations with only a single "priority" level
(beyond non-priority) are illustrated here; However, the reader will (beyond non-priority) are illustrated here; however, the reader will
appreciate that operations with multiple priority levels can easily appreciate that operations with multiple priority levels can easily
be supported with these models. be supported with these models.
In all the figures below: In all the figures below:
x represents a non-priority session "x" represents a non-priority session
"o" represents a priority session
o represents a priority session
A.1. Admission Priority with Maximum Allocation Model (MAM) A.1. Admission Priority with Maximum Allocation Model (MAM)
This section illustrates operations of admission priority when a This section illustrates operations of admission priority when a
Maximum Allocation Model (MAM) is used for bandwidth allocation Maximum Allocation Model (MAM) is used for bandwidth allocation
across non-priority traffic and priority traffic. A property of the across non-priority traffic and priority traffic. A property of the
Maximum Allocation Model is that priority traffic can not use more Maximum Allocation Model is that priority traffic cannot use more
than the bandwidth made available to priority traffic (even if the than the bandwidth made available to priority traffic (even if the
non-priority traffic is not using all of the bandwidth available for non-priority traffic is not using all of the bandwidth available for
it). it).
----------------------- -----------------------
^ ^ ^ | | ^ ^ ^ ^ | | ^
. . . | | . . . . | | .
Total . . . | | . Bandwidth Total . . . | | . Bandwidth
(1)(2)(3) | | . Available (1)(2)(3) | | . available
Engi- . . . | | . for non-priority use Engi- . . . | | . for non-priority use
neered .or.or. | | . neered .or.or. | | .
. . . | | . . . . | | .
Capacity. . . | | . Capacity. . . | | .
v . . | | v v . . | | v
. . |--------------| --- . . |--------------| ---
v . | | ^ v . | | ^
. | | . Bandwidth available for . | | . Bandwidth available for
v | | v priority use v | | v priority use
------------------------- -------------------------
Figure 4: MAM Bandwidth Allocation Figure 4: MAM Bandwidth Allocation
Figure 4 shows a link within a routed network conforming to this Figure 4 shows a link that is within a routed network and conforms to
document. On this link are two amounts of bandwidth available to two this document. On this link are two amounts of bandwidth available
types of traffic: non-priority and priority. to two 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 fully utilized currently.
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 sessions, 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 to the As illustrated in Figure 4, an operator may map the MAM to the
Engineered Capacity limits according to different policies. At one engineered capacity limits according to different policies. At one
extreme, where the proportion of priority traffic is reliably known extreme, where the proportion of priority traffic is reliably known
to be fairly small at all times and where there may be some safety to be fairly small at all times and where there may be some safety
margin factored in the engineered capacity limits, the operator may margin factored in the engineered capacity limits, the operator may
decide to configure the bandwidth available for non-priority use to decide to configure the bandwidth available for non-priority use to
the full engineered capacity limits; effectively allowing the the full engineered capacity limits, effectively allowing the
priority traffic to ride within the safety margin of this engineered priority traffic to ride within the safety margin of this engineered
capacity. This policy can be seen as an economically attractive capacity. This policy can be seen as an economically attractive
approach as all of the engineered capacity is made available to non- approach as all of the engineered capacity is made available to non-
priority sessions. This policy is illustrated as (1) in Figure 4. priority sessions. This policy is illustrated as (1) in Figure 4.
As an example, if the engineered capacity limit on a given link is X, As an example, if the engineered capacity limit on a given link is X,
the operator may configure the bandwidth available to non-priority the operator may configure the bandwidth available to non-priority
traffic to X, and the bandwidth available to priority traffic to 5% traffic to X, and the bandwidth available to priority traffic to 5%
of X. At the other extreme, where the proportion of priority traffic of X. At the other extreme, where the proportion of priority traffic
may be significant at times and the engineered capacity limits are may be significant at times and the engineered capacity limits are
very tight, the operator may decide to configure the bandwidth very tight, the operator may decide to configure the bandwidth
available to non-priority traffic and the bandwidth available to available to non-priority traffic and the bandwidth available to
priority traffic such that their sum is equal to the engineered priority traffic such that their sum is equal to the engineered
capacity limits. This guarantees that the total load across non- capacity limits. This guarantees that the total load across non-
priority and priority traffic is always below the engineered capacity priority and priority traffic is always below the engineered capacity
and, in turn, guarantees there will never be any QoS degradation. and, in turn, guarantees there will never be any QoS degradation.
However, this policy is less attractive economically as it prevents However, this policy is less attractive economically as it prevents
non-priority sessions from using the full engineered capacity, even non-priority sessions from using the full engineered capacity, even
when there is no or little priority load, which is the majority of when there is no or little priority load, which is the majority of
time. This policy is illustrated as (3) in Figure 4. As an example, time. This policy is illustrated as (3) in Figure 4. As an example,
if the engineered capacity limit on a given link is X, the operator if the engineered capacity limit on a given link is X, the operator
may configure the bandwidth available to non-priority traffic to 95% 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 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 course, an operator may also strike a balance anywhere in between
these two approaches. This policy is illustrated as (2) in Figure 4. these two approaches. This policy is illustrated 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
used. used.
----------------------- -----------------------
^ ^ ^ | | ^ ^ ^ ^ | | ^
. . . | | . . . . | | .
Total . . . | | . Bandwidth Total . . . | | . Bandwidth
. . . | | . Available . . . | | . available
Engi- . . . | | . for non-priority use Engi- . . . | | . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| . neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| . . . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| . Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v v . . |xxxxxxxxxxxxxx| v
. . |--------------| --- . . |--------------| ---
v . | | ^ v . | | ^
. | | . Bandwidth available for . | | . Bandwidth available for
v | | v priority use v | | v priority use
------------------------- -------------------------
Figure 5: Partial load of non-priority calls Figure 5: Partial Load of Non-Priority Calls
Figure 6 shows the same amount of non-priority load being used at Figure 6 shows the same amount of non-priority load being used at
this link, and a small amount of priority bandwidth being used. this link and a small amount of priority bandwidth being used.
----------------------- -----------------------
^ ^ ^ | | ^ ^ ^ ^ | | ^
. . . | | . . . . | | .
Total . . . | | . Bandwidth Total . . . | | . Bandwidth
. . . | | . Available . . . | | . available
Engi- . . . | | . for non-priority use Engi- . . . | | . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| . neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| . . . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| . Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v v . . |xxxxxxxxxxxxxx| v
. . |--------------| --- . . |--------------| ---
v . | | ^ v . | | ^
. | | . Bandwidth available for . | | . Bandwidth available for
v |oooooooooooooo| v priority use v |oooooooooooooo| v priority use
------------------------- -------------------------
Figure 6: Partial load of non-priority calls & partial load of Figure 6: Partial Load of Non-Priority Calls and Partial Load of
priority calls Calls Priority Calls
Figure 7 shows the case where non-priority load equates or exceeds Figure 7 shows the case where non-priority load equates or exceeds
the maximum bandwidth available to non-priority traffic. Note that the maximum bandwidth available to non-priority traffic. Note that
additional non-priority sessions would be rejected even if the additional non-priority sessions would be rejected even if the
bandwidth reserved for priority sessions is not fully utilized. bandwidth reserved for priority sessions is not fully utilized.
----------------------- -----------------------
^ ^ ^ |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. . . |xxxxxxxxxxxxxx| . Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v v . . |xxxxxxxxxxxxxx| v
. . |--------------| --- . . |--------------| ---
v . | | ^ v . | | ^
. | | . 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 and 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 sessions are dropped Note that this does not mean that such sessions are dropped
altogether: they may be handled by mechanisms, which are beyond the altogether: they may be handled by mechanisms, which are beyond the
scope of this particular document (such as establishment through scope of this particular document (such as establishment through
preemption of existing non-priority sessions, or such as queuing of preemption of existing non-priority sessions or such as queueing of
new priority session requests until capacity becomes available again new priority session requests until capacity becomes available again
for priority 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. . . | | .
v . . | | v v . . | | v
. . |--------------| --- . . |--------------| ---
v . |oooooooooooooo| ^ v . |oooooooooooooo| ^
. |oooooooooooooo| . Bandwidth available for . |oooooooooooooo| . Bandwidth available for
v |oooooooooooooo| v priority use v |oooooooooooooo| v priority use
------------------------- -------------------------
Figure 8: Partial non-priority load & Full priority load Figure 8: Partial Non-Priority Load and Full Priority Load
A.2. Admission Priority with Russian Dolls Model (RDM) A.2. Admission Priority with Russian Dolls Model (RDM)
This section illustrates operations of admission priority when a This section illustrates operations of admission priority when a
Russian Dolls Model (RDM) is used for bandwidth allocation across Russian Dolls Model (RDM) is used for bandwidth allocation across
non-priority traffic and priority traffic. A property of the Russian non-priority traffic and priority traffic. A property of the RDM is
Dolls Model is that priority traffic can use the bandwidth which is that priority traffic can use the bandwidth that is not currently
not currently used by non-priority traffic. used by non-priority traffic.
As with the MAM, an operator may map the RDM onto the Engineered As with the MAM, an operator may map the RDM onto the engineered
Capacity limits according to different policies. The operator may capacity limits according to different policies. The operator may
decide to configure the bandwidth available for non-priority use to decide to configure the bandwidth available for non-priority use to
the full engineered capacity limits; As an example, if the engineered the full engineered capacity limits. As an example, if the
capacity limit on a given link is X, the operator may configure the engineered capacity limit on a given link is X, the operator may
bandwidth available to non-priority traffic to X, and the bandwidth configure the bandwidth available to non-priority traffic to X, and
available to non-priority and priority traffic to 105% of X. the bandwidth available to non-priority and priority traffic to 105%
of X.
Alternatively, the operator may decide to configure the bandwidth Alternatively, the operator may decide to configure the bandwidth
available to non-priority and priority traffic to the engineered available to non-priority and priority traffic to the engineered
capacity limits; As an example, if the engineered capacity limit on a capacity limits. 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 95% of X, and the bandwidth available to to non-priority traffic to 95% of X, and the bandwidth available to
non-priority and priority traffic to X. non-priority and priority traffic to X.
Finally, the operator may decide to strike a balance in between. The Finally, the operator may decide to strike a balance in between. The
considerations presented for these policies in the previous section considerations presented for these policies in the previous section
in the MAM context are equally applicable to RDM. in the MAM context are equally applicable to RDM.
Figure 9 shows the case where only some of the bandwidth available to Figure 9 shows the case where only some of the bandwidth available to
non-priority traffic is being used and a small amount of priority non-priority traffic is being used, and a small amount 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. sessions and new priority sessions would be accepted.
-------------------------------------- --------------------------------------
|xxxxxxxxxxxxxx| . ^ |xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth . |xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . Available for . |xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority . |xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use . |xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth |xxxxxxxxxxxxxx| . . Bandwidth
| | . . available for | | . . available for
| | v . non-priority | | v . non-priority
|--------------| --- . and priority |--------------| --- . and priority
| | . use | | . use
| | . | | .
|oooooooooooooo| v |oooooooooooooo| v
--------------------------------------- ---------------------------------------
Figure 9: Partial non-priority load & Partial Aggregate load Figure 9: Partial Non-Priority Load and Partial Aggregate Load
Figure 10 shows the case where all of the bandwidth available to non- Figure 10 shows the case where all of the bandwidth available to non-
priority traffic is being used and a small amount of priority traffic priority traffic is being used and a small amount of priority traffic
is in place. In that situation new priority sessions would be is in place. In that situation, new priority sessions would be
accepted but new non-priority sessions would be rejected. accepted, but new non-priority sessions would be rejected.
-------------------------------------- --------------------------------------
|xxxxxxxxxxxxxx| . ^ |xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth . |xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . Available for . |xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority . |xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use . |xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth |xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for |xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority |xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority |--------------| --- . and priority
| | . use | | . use
| | . | | .
|oooooooooooooo| v |oooooooooooooo| v
--------------------------------------- ---------------------------------------
Figure 10: Full non-priority load & Partial Aggregate load Figure 10: Full Non-Priority Load and 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 sessions 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
|oooooooooooooo| v . non-priority |oooooooooooooo| v . non-priority
|--------------| --- . and priority |--------------| --- . and priority
|oooooooooooooo| . use |oooooooooooooo| . use
|oooooooooooooo| . |oooooooooooooo| .
|oooooooooooooo| v |oooooooooooooo| v
--------------------------------------- ---------------------------------------
Figure 11: Partial non-priority load & Heavy Aggregate load Figure 11: Partial Non-Priority Load and Heavy Aggregate Load
Figure 12 shows the case where all of the bandwidth available to non- Figure 12 shows the case where all of the bandwidth available to non-
priority traffic is being used and all of the remaining available priority traffic is being used, and all of the remaining available
bandwidth is used by priority traffic. In that situation new non- bandwidth is used by priority traffic. In that situation, new non-
priority sessions would be rejected. In that situation new priority priority sessions would be rejected, and new priority sessions could
sessions could not be accepted right away. Those priority sessions not be accepted right away. Those priority sessions may be handled
may be handled by mechanisms, which are beyond the scope of this by mechanisms, which are beyond the scope of this particular document
particular document (such as established through preemption of (such as established through preemption of existing non-priority
existing non-priority sessions, or such as queuing of new priority sessions or such as queueing of new priority session requests until
session requests until capacity becomes available again for priority capacity becomes available again for priority traffic).
traffic).
-------------------------------------- --------------------------------------
|xxxxxxxxxxxxxx| . ^ |xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth . |xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . Available for . |xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority . |xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use . |xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth |xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for |xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority |xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority |--------------| --- . and priority
|oooooooooooooo| . use |oooooooooooooo| . use
|oooooooooooooo| . |oooooooooooooo| .
|oooooooooooooo| v |oooooooooooooo| v
--------------------------------------- ---------------------------------------
Figure 12: Full non-priority load & Full Aggregate load Figure 12: Full Non-Priority Load and Full Aggregate Load
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 PrBM,
Bypass Model, non-priority traffic is subject to resource based non-priority traffic is subject to resource-based admission control,
admission control while priority traffic simply bypasses the resource while priority traffic simply bypasses the resource-based admission
based admission control. In other words: control. In other words:
o when a non-priority session arrives, this session 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 session arrives, this session is admitted o when a priority session arrives, this session is admitted
regardless of the current load. regardless of the current load.
A property of this model is that a priority session is never A property of this model is that a priority session is never
rejected. 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 sessions is very low for the vast majority o The volume of priority sessions is very low for the vast majority
of 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 sessions and preclude the utilization of bandwidth for priority sessions and preclude the utilization of
this bandwidth by normal sessions in normal situations this bandwidth by normal sessions in normal situations.
o even in congestion periods where priority sessions may be more o Even in congestion periods where priority sessions may be more
heavily used, those always still represent a fairly small heavily used, those sessions always still represent a fairly small
proportion of the overall load which can be absorbed within the proportion of the overall load that can be absorbed within the
safety margin of the engineered capacity limits. Thus, even if safety margin of the engineered capacity limits. Thus, even if
they are admitted beyond the engineered bandwidth threshold, they they are admitted beyond the engineered bandwidth threshold, they
are unlikely to result in noticeable QoS degradation. are unlikely to result in noticeable QoS degradation.
As with the MAM and RDM, an operator may map the Priority Bypass As with the MAM and RDM, an operator may map the PrBM onto the
model onto the Engineered Capacity limits according to different engineered capacity limits according to different policies. The
policies. The operator may decide to configure the bandwidth limit operator may decide to configure the bandwidth limit for admission of
for admission of non-priority traffic to the full engineered capacity non-priority traffic to the full engineered capacity limit. As an
limits; As an example, if the engineered capacity limit on a given example, if the engineered capacity limit on a given link is X, the
link is X, the operator may configure the bandwidth limit for non- operator may configure the bandwidth limit for non-priority traffic
priority traffic to X. Alternatively, the operator may decide to to X. Alternatively, the operator may decide to configure the
configure the bandwidth limit for non-priority traffic to below the bandwidth limit for non-priority traffic to below the engineered
engineered capacity limits (so that the sum of the non-priority and capacity limits (so that the sum of the non-priority and priority
priority traffic stays below the engineered capacity); As an example, traffic stays below the engineered capacity). As an example, if the
if the engineered capacity limit on a given link is X, the operator engineered capacity limit on a given link is X, the operator may
may configure the bandwidth limit for non-priority traffic to 95% of configure the bandwidth limit for non-priority traffic to 95% of X.
X. Finally, the operator may decide to strike a balance in between. Finally, the operator may decide to strike a balance in between.
The considerations presented for these policies in the previous The considerations presented for these policies in the previous
sections in the MAM and RDM contexts are equally applicable to the sections in the MAM and RDM contexts are equally applicable to the
Priority Bypass Model. PrBM.
Figure 13 illustrates the bandwidth allocation with the Priority Figure 13 illustrates the bandwidth allocation with the PrBM.
Bypass Model.
----------------------- -----------------------
^ ^ | | ^ ^ ^ | | ^
. . | | . . . | | .
Total . . | | . Bandwidth Limit Total . . | | . Bandwidth limit
(1) (2) | | . (on non-priority + priority) (1) (2) | | . (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 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
sessions 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 sessions would this situation, both new non-priority and new priority sessions would
be 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. . | | .
v . | | v v . | | v
. |--------------| --- . |--------------| ---
. | | . | |
v | | v | |
| | | |
Figure 15: Partial load of non-priority calls & partial load of Figure 15: Partial Load of Non-Priority Calls and 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 session is rejected traffic. In this situation, any new non-priority session is
while any new priority session is admitted. rejected, 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| .
v . |xxoxxxooxxxxxx| v v . |xxoxxxooxxxxxx| v
. |--------------| --- . |--------------| ---
. |oooooooooooooo| . |oooooooooooooo|
v | | v | |
| | | |
Figure 16: Full non-priority load Figure 16: Full Non-Priority Load
Appendix B. Example Usages of RSVP Extensions Appendix B. Example Usages of RSVP Extensions
This section provides examples of how RSVP extensions defined in this This section provides examples of how RSVP extensions defined in this
document can be used (in conjunctions with other RSVP functionality document can be used (in conjunction with other RSVP functionality
and SIP functionality) to enforce different hypothetical policies for and SIP functionality) to enforce different hypothetical policies for
handling prioritized sessions in a given administrative domain. This handling prioritized 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.
We refer here to "Session Queueing" as the set of "session" layer We refer here to "Session Queueing" as the set of "session-layer"
capabilities that may be implemented by SIP user agents to influence capabilities that may be implemented by SIP user agents to influence
their treatment of SIP requests. This may include the ability to their treatment of SIP requests. This may include the ability to
"queue" session requests when those can not be immediately honored "queue" session requests when those cannot be immediately honored (in
(in some cases with the notion of "bumping", or "displacement", of some cases with the notion of "bumping", or "displacement", of less
less important session requests from that queue). It may include important session requests from that queue). It may include
additional mechanisms such as exemption from certain network additional mechanisms such as alternate routing and exemption from
management controls, and alternate routing. certain network management controls.
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 a policy area boundary by PDPs. The Admission Priority and at a policy area boundary by PDPs. The Admission Priority and
Preemption Priority RSVP policy elements are set by PDPs as a result Preemption Priority RSVP policy elements are set by PDPs as a result
of processing the Application Level Resource Priority Policy Element of processing the Application-Level Resource Priority Policy Element
(which is carried in RSVP messages). (which is carried in RSVP messages).
If one wants to implement a prioritized service purely based on If one wants to implement a prioritized service purely based on
Session Queueing, one can achieve this by signaling prioritized Session Queueing, one can achieve this by signaling prioritized
sessions: sessions:
o using "Resource-Priority" header in SIP o using the "Resource-Priority" header in SIP
o not using Admission-Priority Policy Element in RSVP o not using the Admission-Priority Policy Element in RSVP
o not using Preemption Policy Element in RSVP o not using the Preemption Policy Element in RSVP
If one wants to implement a prioritized service based on Session If one wants to implement a prioritized service based on Session
Queueing and on "prioritized access to network layer resources", one Queueing and "prioritized access to network-layer resources", one can
can achieve this by signaling prioritized sessions: achieve this by signaling prioritized sessions:
o using "Resource-Priority" header in SIP o using the "Resource-Priority" header in SIP
o using Admission-Priority Policy Element in RSVP o using the Admission-Priority Policy Element in RSVP
o not using Preemption Policy Element in RSVP o not using the Preemption Policy Element in RSVP
Establishment of prioritized sessions will not result in preemption Establishment of prioritized sessions will not result in preemption
of any session. Different bandwidth allocation models can be used to of any session. Different bandwidth allocation models can be used to
offer different "prioritized access to network resources". Just as offer different "prioritized access to network-layer resources".
examples, this includes strict setting aside of capacity for Just as examples, this includes setting aside capacity exclusively
prioritized sessions as well as simple bypass of admission limits for for prioritized sessions as well as simple bypass of admission limits
prioritized sessions. for prioritized sessions.
If one wants to implement a prioritized service based on Session If one wants to implement a prioritized service based on Session
Queueing, on "prioritized access to network layer resources", and Queueing and "prioritized access to network-layer resources", and
ensures that (say) "Prioritized-1" sessions can preempt wants to ensure that (say) "Prioritized-1" sessions can preempt
"Prioritized-2" sessions, but non-prioritized sessions are not "Prioritized-2" sessions, but non-prioritized sessions are not
affected by preemption, one can do that by signaling prioritized affected by preemption, one can do that by signaling prioritized
sessions: sessions:
o using "Resource-Priority" header in SIP o using the "Resource-Priority" header in SIP
o using Admission-Priority Policy Element in RSVP o using the Admission-Priority Policy Element in RSVP
o using Preemption Policy Element in RSVP with: o using the Preemption Policy Element in RSVP with:
* setup (Prioritized-1) > defending (Prioritized-2) * setup (Prioritized-1) > defending (Prioritized-2)
* setup (Prioritized-2) <= defending (Prioritized-1) * setup (Prioritized-2) <= defending (Prioritized-1)
* setup (Prioritized-1) <= defending (Non-Prioritized) * setup (Prioritized-1) <= defending (Non-Prioritized)
* setup (Prioritized-2) <= defending (Non-Prioritized) * setup (Prioritized-2) <= defending (Non-Prioritized)
If one wants to implement a prioritized service based on Session If one wants to implement a prioritized service based on Session
Queueing, on "prioritized access to network layer resources", and Queueing and "prioritized access to network-layer resources", and
ensure that prioritized sessions can preempt regular sessions, one wants to ensure that prioritized sessions can preempt regular
could do that by signaling Prioritized sessions: sessions, one could do that by signaling Prioritized sessions:
o using "Resource-Priority" header in SIP o using the "Resource-Priority" header in SIP
o using Admission-Priority Policy Element in RSVP o using the Admission-Priority Policy Element in RSVP
o using Preemption Policy Element in RSVP with: o using the Preemption Policy Element in RSVP with:
* setup (Prioritized) > defending (Non-Prioritized) * setup (Prioritized) > defending (Non-Prioritized)
* setup (Non-Prioritized) <= defending (Prioritized) * setup (Non-Prioritized) <= defending (Prioritized)
If one wants to implement a prioritized service based on Session If one wants to implement a prioritized service based on Session
Queueing, on "prioritized access to network layer resources", and Queueing and "prioritized access to network-layer resources", and
ensure that prioritized sessions can partially preempt regular wants to ensure that prioritized sessions can partially preempt
sessions (i.e. Reduce their reservation size), one could do that by regular sessions (i.e., reduce their reservation size), one could do
signaling prioritized sessions: that by signaling prioritized sessions:
o using "Resource-Priority" header in SIP o using the "Resource-Priority" header in SIP
o using Admission-Priority Policy Element in RSVP o using the Admission-Priority Policy Element in RSVP
o using Preemption in Policy Element RSVP with: o using the Preemption Policy Element in RSVP with:
* setup (Prioritized) > defending (Non-Prioritized) * setup (Prioritized) > defending (Non-Prioritized)
* setup (Non-Prioritized) <= defending (Prioritized) * setup (Non-Prioritized) <= defending (Prioritized)
o activate RFC4495 RSVP Bandwidth Reduction mechanisms o activate [RFC4495] RSVP bandwidth reduction mechanisms
Authors' Addresses Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com EMail: flefauch@cisco.com
James Polk James Polk
Cisco Systems Cisco Systems
2200 East President George Bush Highway 2200 East President George Bush Highway
Richardson, TX 75082-3550 Richardson, TX 75082-3550
United States United States
Phone: +1 972 813 5208 Phone: +1 972 813 5208
Email: jmpolk@cisco.com EMail: jmpolk@cisco.com
Ken Carlberg Ken Carlberg
G11 G11
123a Versailles Circle 123a Versailles Circle
Towson, MD 21204 Towson, MD 21204
United States United States
Email: carlberg@g11.org.uk EMail: carlberg@g11.org.uk
 End of changes. 212 change blocks. 
471 lines changed or deleted 448 lines changed or added

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