draft-ietf-tsvwg-emergency-rsvp-04.txt   draft-ietf-tsvwg-emergency-rsvp-05.txt 
RSVP Extensions for Emergency Services November 2007 RSVP Extensions for Emergency Services January 2008
TSVWG Francois Le Faucheur TSVWG Francois Le Faucheur
Internet-Draft James Polk Internet-Draft James Polk
Intended Status: Standards Track Cisco Systems, Inc. Intended Status: Standards Track Cisco Systems, Inc.
Ken Carlberg Ken Carlberg
G11 G11
draft-ietf-tsvwg-emergency-rsvp-04.txt draft-ietf-tsvwg-emergency-rsvp-05.txt
Expires: May 2008 November 19, 2007 Expires: August 1, 2008 January 31, 2008
Resource ReSerVation Protovol (RSVP) Extensions for Emergency Resource ReSerVation Protovol (RSVP) Extensions for Emergency
Services Services
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 2, line 12 skipping to change at page 2, line 12
resources may be explicitly set aside for emergency services, or they resources may be explicitly set aside for emergency services, or they
may be shared with other sessions. may be shared with other sessions.
This document specifies RSVP extensions that can be used to support This document specifies RSVP extensions that can be used to support
such an admission priority capability at the network layer. Note that such an admission priority capability at the network layer. Note that
these extensions represent one possible solution component in these extensions represent one possible solution component in
satisfying ETS requirements. Other solution components, or other satisfying ETS requirements. Other solution components, or other
solutions, are outside the scope of this document. solutions, are outside the scope of this document.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Specification of Requirements Specification of Requirements
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. document are to be interpreted as described in RFC 2119.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Related Technical Documents.................................3 1.1. Related Technical Documents................................3
1.2. Terminology.................................................4 1.2. Terminology................................................4
2. Overview of RSVP extensions and Operations.....................5 2. Overview of RSVP extensions and Operations.....................5
2.1. Operations of Admission Priority..........................7 2.1. Operations of Admission Priority..........................7
3. New Policy Elements............................................7 3. New Policy Elements............................................7
3.1. Admission Priority Policy Element.........................8 3.1. Admission Priority Policy Element.........................8
3.1.1. Admission Priority Merging Rules 9 3.1.1. Admission Priority Merging Rules 9
3.2. Application-Level Resource Priority Policy Element.......10 3.2. Application-Level Resource Priority Policy Element.......10
3.2.1. Application-Level Resource Priority Modifying and 3.2.1. Application-Level Resource Priority Modifying and
Merging Rules 11 Merging Rules 11
3.3. Default Handling.........................................11 3.3. Default Handling.........................................11
4. Security Considerations.......................................12 4. Security Considerations.......................................12
skipping to change at page 6, line 24 skipping to change at page 6, line 24
As another example of operation across multiple administrative As another example of operation across multiple administrative
domains, we can consider the case where the resource priority header domains, we can consider the case where the resource priority header
enumerates several namespaces, as explicitly allowed by [SIP- enumerates several namespaces, as explicitly allowed by [SIP-
PRIORITY], for support of scenarios where calls traverse multiple PRIORITY], for support of scenarios where calls traverse multiple
administrative domains using different namespace. In that case, the administrative domains using different namespace. In that case, the
relevant namespace can be used at each domain boundary to map into an relevant namespace can be used at each domain boundary to map into an
RSVP Admission priority for that domain. It is not expected that the RSVP Admission priority for that domain. It is not expected that the
RSVP Application-Level Resource-Priority Header Policy Element would RSVP Application-Level Resource-Priority Header Policy Element would
be taken into account at RSVP-hops within a given administrative be taken into account at RSVP-hops within a given administrative
domain. It is expected to be used at administrative domain boundaries domain. It is expected to be used at administrative domain boundaries
only in order to set/reset the RSVP Admission Priority Policy Element. only in order to set/reset the RSVP Admission Priority Policy
Element.
The existence of pre-established inter-domain policy agreements or The existence of pre-established inter-domain policy agreements or
Service Level Agreements may avoid the need to take real-time action Service Level Agreements may avoid the need to take real-time action
at administrative domain boundaries for mapping/remapping of at administrative domain boundaries for mapping/remapping of
admission priorities. admission priorities.
Mapping/remapping by PDPs may also be applied to boundaries between Mapping/remapping by PDPs may also be applied to boundaries between
various signaling protocols, such as those advanced by the NSIS various signaling protocols, such as those advanced by the NSIS
working group. working group.
skipping to change at page 8, line 43 skipping to change at page 8, line 43
| Reserved |Adm. Priority| | Reserved |Adm. Priority|
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Length: 16 bits 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.
P-Type: 16 bits P-Type: 16 bits
ADMISSION_PRI = To be allocated by IANA ADMISSION_PRI = To be allocated by IANA
(see "IANA Considerations" section) (see "IANA Considerations" section)
Flags: Reserved (MUST be set to zero on transmit and ignored on Flags: Reserved (SHALL be set to zero on transmit and SHALL be
receive) ignored on reception)
Merge Strategy: 8 bits (only applicable to multicast flows) Merge Strategy: 8 bits (only applicable to multicast flows)
1 Take priority of highest QoS 1 Take priority of highest QoS
2 Take highest priority 2 Take highest priority
3 Force Error on heterogeneous merge 3 Force Error on heterogeneous merge
(See section 3.1.1) (See section 3.1.1)
Error code: 8 bits (only applicable to multicast flows) Error code: 8 bits (only applicable to multicast flows)
0 NO_ERROR Value used for regular ADMISSION_PRI elements 0 NO_ERROR Value used for regular ADMISSION_PRI elements
2 HETEROGENEOUS This element encountered heterogeneous merge 2 HETEROGENEOUS This element encountered heterogeneous merge
Reserved: 8 bits Reserved: 8 bits
Always 0. SHALL be set to zero on transmit and SHALL be ignored on
reception.
Reserved: 24 bits Reserved: 24 bits
Always 0. SHALL be set to zero on transmit and SHALL be ignored on
reception.
Adm. Priority (Admission Priority): 8 bits (unsigned) 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
to network bandwidth in order to provide higher probability of network bandwidth in order to provide higher probability of call
call completion to selected flows. Higher values represent completion to selected flows. Higher values represent higher
higher Priority. Priority. A given Admission Priority is encoded in this information
element using the same value as when encoded in the Admission
Priority parameter defined in section 6.2.9 of [NSIS-QSPEC], or in
the Admission Priority parameter defined in section 4.10 of [DIME-
PARAM]. In other words, a given value inside the Admission Priority
information element defined in the present document, inside the
[NSIS-QSPEC] Admission Priority parameter or inside the [DIME-PARAM]
Admission Priority parameter, refers to the same Admission Priority.
Bandwidth allocation models such as those described in Appendix Bandwidth allocation models such as those described in Appendix A are
A are to be used by the RSVP router to achieve such increased to be used by the RSVP router to achieve such increased probability
probability of call completion. The admission priority value of call completion. The admission priority value effectively
effectively indicates which bandwidth constraint(s) of the indicates which bandwidth constraint(s) of the bandwidth constraint
bandwidth constraint model in use is(are) applicable to model in use is(are) applicable to admission of this RSVP
admission of this RSVP reservation. reservation.
Note that the Admission Priority Policy Element does NOT indicate Note that the Admission Priority Policy Element does NOT indicate
that this RSVP reservation is to preempt any other RSVP reservation. that this RSVP reservation is to preempt any other RSVP reservation.
If a priority session justifies both admission priority and If a priority session justifies both admission priority and
preemption priority, the corresponding RSVP reservation needs to preemption priority, the corresponding RSVP reservation needs to
carry both an Admission Priority Policy Element and a Preemption carry both an Admission Priority Policy Element and a Preemption
Priority Policy Element. The Admission Priority and Preemption Priority Policy Element. The Admission Priority and Preemption
Priority are handled by LPDPs and PEPs as separate mechanisms. They Priority are handled by LPDPs and PEPs as separate mechanisms. They
can be used one without the other, or they can be used both in can be used one without the other, or they can be used both in
combination. combination.
3.1.1. 3.1.1. Admission Priority Merging Rules
Admission Priority Merging Rules
This section discusses alternatives for dealing with RSVP admission This section discusses alternatives for dealing with RSVP admission
priority in case of merging of reservations. As merging is only priority in case of merging of reservations. As merging is only
applicable to multicast, this section also only applies to multicast applicable to multicast, this section also only applies to multicast
sessions. sessions.
The rules for merging Admission Priority Policy Elements are the same The rules for merging Admission Priority Policy Elements are the same
as those defined in [RSVP-PREEMP] for merging Preemption Priority as those defined in [RSVP-PREEMP] for merging Preemption Priority
Policy Elements. In particular, the following merging strategies are Policy Elements. In particular, the following merging strategies are
supported: supported:
skipping to change at page 10, line 42 skipping to change at page 11, line 4
APP_RESOURCE_PRI = To be allocated by IANA APP_RESOURCE_PRI = To be allocated by IANA
(see "IANA Considerations" section) (see "IANA Considerations" section)
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 Priority| | ALRP Namespace | Reserved |ALRP Priority|
+---------------------------+---------------------------+ +---------------------------+---------------------------+
ALRP Namespace (Application-Level Resource Priority Namespace): ALRP Namespace (Application-Level Resource Priority Namespace):
16 bits (unsigned) 16 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 application-level resource priority. This value is encoded
as per the "Resource-Priority Namespaces" IANA registry. (See as per the "Resource-Priority Namespaces" IANA registry. (See
IANA Considerations section for the request to IANA to IANA Considerations section for the request to IANA to
extend the registry to include this numerical value). extend the registry to include this numerical value).
Reserved: 8 bits Reserved: 8 bits
Always 0. SHALL be set to zero on transmit and SHALL be ignored on
reception.
ALRP Priority: (Application-Level Resource Priority Priority): ALRP Priority: (Application-Level Resource Priority Priority):
8 bits (unsigned) 8 bits (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 application-level resource priority. This value is encoded
as per the "Resource-Priority Priority-Value" IANA registry. as per the "Resource-Priority Priority-Value" IANA registry.
(See IANA Considerations section for the request to IANA to (See IANA Considerations section for the request to IANA to
extend the registry to include this numerical value). extend the registry to include this numerical value).
3.2.1. 3.2.1. Application-Level Resource Priority Modifying and Merging Rules
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 as-is to ensure their
security envelope is not invalidated. 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 merge Priority elements to reduce their size and number. When they do merge
those, LPDPs MUST do so according to the following rule: those, LPDPs MUST do so according to the following rule:
skipping to change at page 13, line 43 skipping to change at page 14, line 9
Value = the unique numerical value identifying the Value = the unique numerical value identifying the
namespace" namespace"
- add a line at the bottom of the registry stating the - add a line at the bottom of the registry stating the
following "* : [RFCXXX] " where XXX is the RFC number of following "* : [RFCXXX] " where XXX is the RFC number of
the present document the present document
- allocate an actual numerical value to each namespace in - allocate an actual numerical value to each namespace in
the registry and state that value in the new "Namespace the registry and state that value in the new "Namespace
numerical Value *" column. numerical Value *" column.
A numerical value should be allocated immediately by IANA to all A numerical value should be allocated immediately by IANA to all
existing namespace. Then, in the future, IANA should automatically existing namespace. Then, in the future, IANA should automatically
allocate a numerical value to any new namespace added to the registry. allocate a numerical value to any new namespace added to the
registry.
[draft-ietf-nsis-qspec] also uses numerical values for Resource-
Priority Namespaces. To that end, the document requests IANA to
create a new registry to allocate numerical values to each namespace.
We suggest that the approach above be followed instead (i.e. extend
the existing registry) and that [draft-ietf-nsis-qspec] also makes
use of the values defined in the new "Namespace numerical Value *"
column of the extended existing Resource-Priority Namespace registry.
In any case, the IANA should honor only one of the two competing
requests (and not both).
The present document defines an ALRP Priority field in section 3.2 The present document defines an ALRP Priority field in section 3.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. However, that registry does not currently allocate a
numerical value to each priority-value. Hence, this document requests numerical value to each priority-value. Hence, this document requests
the IANA to extend the Resource-Priority Priority-Values registry in the IANA to extend the Resource-Priority Priority-Values registry in
the following ways: the following ways:
skipping to change at page 14, line 38 skipping to change at page 14, line 42
- At the bottom of the registry, add a "Legend" with a line - At the bottom of the registry, add a "Legend" with a line
saying "Priority Numerical Value = the unique numerical saying "Priority Numerical Value = the unique numerical
value identifying the priority within a namespace" value identifying the priority within a namespace"
- add a line at the bottom of the registry stating the - add a line at the bottom of the registry stating the
following "* : [RFCXXX] " where XXX is the RFC number of following "* : [RFCXXX] " where XXX is the RFC number of
the present document the present document
- allocate an actual numerical value to each and state that - allocate an actual numerical value to each and state that
value in the new "Priority Numerical Value *" column. value in the new "Priority Numerical Value *" column.
A numerical value should be allocated immediately by IANA to all A numerical value should be allocated immediately by IANA to all
existing priority. Then, in the future, IANA should automatically existing priority. Then, in the future, IANA should automatically
allocate a numerical value to any new namespace added to the registry. allocate a numerical value to any new namespace added to the
The numerical value must be unique within each namespace. Within each registry. The numerical value must be unique within each namespace.
namespace, values should be allocated in decreasing order ending with Within each namespace, values should be allocated in decreasing order
0 (so that the greatest priority is always allocated value 0). For ending with 0 (so that the greatest priority is always allocated
example, in the drsn namespace, "routine" would be allocated value 0). For example, in the drsn namespace, "routine" would be
numerical value 5 and "flash-override-override" would be allocated allocated numerical value 5 and "flash-override-override" would be
numerical value 0. allocated numerical value 0.
[draft-ietf-nsis-qspec] also uses numerical values for Resource-
Priority Priorities. To that end, the document requests IANA to
create a new registry to allocate numerical values to each priority.
We suggest that the approach above be followed instead (i.e. extend
the existing registry) and that [draft-ietf-nsis-qspec] also makes
use of the values defined in the new "Priority Numerical Value *"
column of the extended existing Resource-Priority Priority-Values
registry. In any case, the IANA should honor only one of the two
competing requests (and not both).
6. Acknowledgments 6. Acknowledgments
We would like to thank An Nguyen for his encouragement to address We would like to thank An Nguyen for his encouragement to address
this topic and ongoing comments. Also, this document borrows heavily this topic and ongoing comments. Also, this document borrows heavily
from some of the work of S. Herzog on Preemption Priority Policy from some of the work of S. Herzog on Preemption Priority Policy
Element [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input Element [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input
into this document. into this document.
7. Normative References 7. Normative References
skipping to change at page 15, line 42 skipping to change at page 15, line 40
[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 3181, October 2001. Element", RFC 3181, October 2001.
[SIP] Rosenberg et al., "SIP: Session Initiation Protocol", RFC3261, [SIP] Rosenberg et al., "SIP: Session Initiation Protocol", RFC3261,
[SIP-PRIORITY] H. Schulzrinne & J. Polk. "Communications Resource [SIP-PRIORITY] H. Schulzrinne & J. Polk. "Communications Resource
Priority for the Session Initiation Protocol (SIP)", RFC4412, Priority for the Session Initiation Protocol (SIP)", RFC4412,
February 2006. February 2006.
8. Informative References 8. Informative References
[DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth [DIME-PARAM] J. Korhonen & H. Tschofenig, "Quality of Service
Parameters for Usage with the AAA Framework", draft-ietf-dime-qos-
parameters-01.txt, work in progress.
[DSTE-MAM] F. Le Faucheur & W. Lai, "Maximum Allocation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC
4125, June 2005. 4125, June 2005.
[DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints [DSTE-RDM] Le Faucheur et al., Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June
2005 2005.
[EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency [EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency
Telecommunications Service for Real Time Services in the Internet Telecommunications Service for Real Time Services in the Internet
Protocol Suite", RFC 4542, May 2006. Protocol Suite", RFC 4542, May 2006.
[EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for [EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for
Emergency Telecommunication Service (ETS)", RFC 3689, February 2004. Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements [EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
for Emergency Telecommunication Service (ETS)", RFC 3690, February for Emergency Telecommunication Service (ETS)", RFC 3690, February
2004. 2004.
[FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework [FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, January 2000. for Policy-based Admission Control", RFC 2753, January 2000.
[ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU, [ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU,
Recommendation, I.255.3, July, 1990. Recommendation, I.255.3, July, 1990.
[NSIS-QSPEC] G. Ash et al., "QoS NLSP QSPEC Template", draft-ietf-
nsis-qspec-18.txt, work in progress.
[RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., [RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182,
October 2001. October 2001.
[RSVP-GROUPKEYING] Behringer, M., Le Faucheur, F., "A Framework for [RSVP-GROUPKEYING] Behringer, M., Le Faucheur, F., "Applicability of
RSVP Security using Dynamic Group Keying", draft-behringer-tsvwg- Keying Methods for RSVP Security", draft-behringer-tsvwg-rsvp-
rsvp-security-groupkeying-00.txt, work in progress. security-groupkeying-01.txt, work in progress.
[SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg, [SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation Protocol "Integration of Resource Management and Session Initiation Protocol
(SIP)", RFC 3312, October 2002. (SIP)", RFC 3312, October 2002.
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 Sections A.1 and A.2 respectively illustrate how the Maximum
Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE- Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE-
skipping to change at page 18, line 38 skipping to change at page 18, line 38
operator may configure the bandwidth available to non-priority 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. of X.
At the other extreme, where the proportion of priority traffic may be At the other extreme, where the proportion of priority traffic may be
significant at times and the engineered capacity limits are very significant at times and the engineered capacity limits are very
tight, the operator may decide to configure the bandwidth available tight, the operator may decide to configure the bandwidth available
to non-priority traffic and the bandwidth available to priority to non-priority traffic and the bandwidth available to priority
traffic such that their sum is equal to the engineered capacity traffic such that their sum is equal to the engineered capacity
limits. This guarantees that the total load across non-priority and limits. This guarantees that the total load across non-priority and
priority traffic is always below the engineered capacity and, in turn, priority traffic is always below the engineered capacity and, in
guarantees there will never be any QoS degradation. However, this turn, guarantees there will never be any QoS degradation. However,
policy is less attractive economically as it prevents non-priority this policy is less attractive economically as it prevents non-
calls from using the full engineered capacity, even when there is no priority calls from using the full engineered capacity, even when
or little priority load, which is the majority of time. This policy there is no or little priority load, which is the majority of time.
illustrated as (3) in Chart 1. As an example, if the engineered This policy illustrated as (3) in Chart 1. 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 95% of X, and the configure the bandwidth available to non-priority traffic to 95%
bandwidth available to priority traffic to 5% of X. 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 Of course, an operator may also strike a balance anywhere in between
these two approaches. This policy illustrated as (2) in Chart 1. these two approaches. This policy illustrated as (2) in Chart 1.
Chart 2 shows some of the non-priority capacity of this link being Chart 2 shows some of the non-priority capacity of this link being
used. used.
----------------------- -----------------------
^ ^ ^ | | ^ ^ ^ ^ | | ^
. . . | | . . . . | | .
skipping to change at page 26, line 31 skipping to change at page 26, line 31
Chart 13. Full non-priority load Chart 13. 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 conjunctions with other RSVP functionality
and SIP functionality) to enforce different hypothetical policies for and SIP functionality) to enforce different hypothetical policies for
handling Emergency sessions in a given administrative domain. This handling Emergency sessions in a given administrative domain. This
Appendix does not provide additional specification. It is only Appendix does not provide additional specification. It is only
included in this document for illustration purposes. The content of included in this document for illustration purposes.
this appendix may be moved into a future applicability statement
document.
We assume an environment where SIP is used for session control and We assume an environment where SIP is used for session control and
RSVP is used for resource reservation. RSVP is used for resource reservation.
In a mild abuse of language, we refer here to "Call Queueing" as the In a mild abuse of language, we refer here to "Call Queueing" as the
set of "session" layer capabilities that may be implemented by SIP set of "session" layer capabilities that may be implemented by SIP
user agents to influence their treatment of SIP requests. This may user agents to influence their treatment of SIP requests. This may
include the ability to "queue" call requests when those can not be include the ability to "queue" call requests when those can not be
immediately honored (in some cases with the notion of "bumping", or immediately honored (in some cases with the notion of "bumping", or
"displacement", of less important call request from that queue). It "displacement", of less important call request from that queue). It
skipping to change at page 27, line 26 skipping to change at page 27, line 25
can achieve this by signaling emergency calls: can achieve this by signaling emergency calls:
* using "Resource-Priority" Header in SIP * using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP * using Admission-Priority Policy Element in RSVP
* not using Preemption Policy Element in RSVP * not using Preemption Policy Element in RSVP
Emergency calls will not result in preemption of any session. Emergency calls will not result in preemption of any session.
Different bandwidth allocation models can be used to offer different Different bandwidth allocation models can be used to offer different
"prioritized access to network resources". Just as examples, this "prioritized access to network resources". Just as examples, this
includes strict setting aside of capacity for emergency sessions as includes strict setting aside of capacity for emergency sessions as
well as simple bypass of admission limits for emergency sessions. well as simple bypass of admission limits for emergency sessions.
If one wants to implement an emergency service based on Call Queueing, If one wants to implement an emergency service based on Call
Queueing,
on "prioritized access to network layer resources", and ensures that on "prioritized access to network layer resources", and ensures that
(say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but
non-emergency sessions are not affected by preemption, one can do non-emergency sessions are not affected by preemption, one can do
that by signaling emergency calls: that by signaling emergency calls:
* using "Resource-Priority" Header in SIP * using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP * using Admission-Priority Policy Element in RSVP
* using Preemption Policy Element in RSVP with: * using Preemption Policy Element in RSVP with:
o setup (Emergency-1) > defending (Emergency-2) o setup (Emergency-1) > defending (Emergency-2)
o setup (Emergency-2) <= defending (Emergency-1) o setup (Emergency-2) <= defending (Emergency-1)
o setup (Emergency-1) <= defending (Non-Emergency) o setup (Emergency-1) <= defending (Non-Emergency)
o setup (Emergency-2) <= defending (Non-Emergency) o setup (Emergency-2) <= defending (Non-Emergency)
If one wants to implement an emergency service based on Call Queueing, If one wants to implement an emergency service based on Call
Queueing,
on "prioritized access to network layer resources", and ensure that on "prioritized access to network layer resources", and ensure that
"emergency" sessions can preempt regular sessions, one could do that "emergency" sessions can preempt regular sessions, one could do that
by signaling emergency calls: by signaling emergency calls:
* using "Resource-Priority" Header in SIP * using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP * using Admission-Priority Policy Element in RSVP
* using Preemption Policy Element in RSVP with: * using Preemption Policy Element in RSVP with:
o setup (Emergency) > defending (Non-Emergency) o setup (Emergency) > defending (Non-Emergency)
o setup (Non-Emergency) <= defending (Emergency) o setup (Non-Emergency) <= defending (Emergency)
If one wants to implement an emergency service based on Call Queueing, If one wants to implement an emergency service based on Call
Queueing,
on "prioritized access to network layer resources", and ensure that on "prioritized access to network layer resources", and ensure that
"emergency" sessions can partially preempt regular sessions (ie "emergency" sessions can partially preempt regular sessions (ie
reduce their reservation size), one could do that by signaling reduce their reservation size), one could do that by signaling
emergency calls: emergency calls:
* using "Resource-Priority" Header in SIP * using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP * using Admission-Priority Policy Element in RSVP
* using Preemption in Policy Element RSVP with: * using Preemption in Policy Element RSVP with:
o setup (Emergency) > defending (Non-Emergency) o setup (Emergency) > defending (Non-Emergency)
o setup (Non-Emergency) <= defending (Emergency) o setup (Non-Emergency) <= defending (Emergency)
* activate RFC4495 RSVP Bandwidth Reduction mechanisms * activate RFC4495 RSVP Bandwidth Reduction mechanisms
skipping to change at page 29, line 22 skipping to change at page 29, line 22
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 27 change blocks. 
78 lines changed or deleted 74 lines changed or added

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