draft-ietf-tsvwg-emergency-rsvp-03.txt   draft-ietf-tsvwg-emergency-rsvp-04.txt 
RSVP Extensions for Emergency Services November 2007
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-03.txt draft-ietf-tsvwg-emergency-rsvp-04.txt
Expires: May 2008 November 19, 2007
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 38 skipping to change at page 2, line 38
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
4.1. Use of RSVP Authentication between RSVP nighbors.........12 4.1. Use of RSVP Authentication between RSVP nighbors.........12
4.2. Use of INTEGRITY object within the POLICY_DATA object....12 4.2. Use of INTEGRITY object within the POLICY_DATA object....12
5. IANA Considerations...........................................13 5. IANA Considerations...........................................13
6. Acknowledgments...............................................14 6. Acknowledgments...............................................15
7. Normative References..........................................14 7. Normative References..........................................15
8. Informative References........................................15 8. Informative References........................................15
Appendix A: Examples of Bandwidth Allocation Model for Admission Appendix A: Examples of Bandwidth Allocation Model for Admission
Priority.........................................................16 Priority.........................................................17
A.1 Admission Priority with Maximum Allocation Model (MAM)......16 A.1 Admission Priority with Maximum Allocation Model (MAM)......17
A.2 Admission Priority with Russian Dolls Model (RDM)...........20 A.2 Admission Priority with Russian Dolls Model (RDM)...........21
A.3 Admission Priority with Priority Bypass Model (PrBM)........22 A.3 Admission Priority with Priority Bypass Model (PrBM)........23
Appendix B: Example Usages of RSVP Extensions....................25 Appendix B: Example Usages of RSVP Extensions....................26
Authors' Address.................................................27 Authors' Address.................................................28
1. Introduction 1. Introduction
[EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency [EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency
Telecommunications Service (ETS), which is an umbrella term Telecommunications Service (ETS), which is an umbrella term
identifying those networks and specific services used to support identifying those networks and specific services used to support
emergency communications. An underlying goal of these documents is to emergency communications. An underlying goal of these documents is to
present requirements that elevate the probability of session present requirements that elevate the probability of session
establishment from an authorized user in times of network congestion establishment from an authorized user in times of network congestion
(presumably because of a crisis condition). In some extreme cases, (presumably because of a crisis condition). In some extreme cases,
skipping to change at page 9, line 37 skipping to change at page 9, line 37
Note that the Admission Priority Policy Element does NOT indicate Note that the Admission Priority Policy Element does NOT indicate
that this RSVP reservation is to preempt any other RSVP reservation. that this RSVP reservation is to preempt any other RSVP reservation.
If a priority session justifies both admission priority and If a priority session justifies both admission priority and
preemption priority, the corresponding RSVP reservation needs to preemption priority, the corresponding RSVP reservation needs to
carry both an Admission Priority Policy Element and a Preemption carry both an Admission Priority Policy Element and a Preemption
Priority Policy Element. The Admission Priority and Preemption Priority Policy Element. The Admission Priority and Preemption
Priority are handled by LPDPs and PEPs as separate mechanisms. They Priority are handled by LPDPs and PEPs as separate mechanisms. They
can be used one without the other, or they can be used both in can be used one without the other, or they can be used both in
combination. combination.
3.1.1. Admission Priority Merging Rules 3.1.1.
Admission Priority Merging Rules
This section discusses alternatives for dealing with RSVP admission This section discusses alternatives for dealing with RSVP admission
priority in case of merging of reservations. As merging is only priority in case of merging of reservations. As merging is only
applicable to multicast, this section also only applies to multicast applicable to multicast, this section also only applies to multicast
sessions. sessions.
The rules for merging Admission Priority Policy Elements are the same The rules for merging Admission Priority Policy Elements are 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 39 skipping to change at page 10, line 39
indicates the end of the ALRP list. indicates the end of the ALRP list.
P-Type: 16 bits P-Type: 16 bits
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 Namespace" 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
Always 0.
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 is encoded as a application-level resource priority. This value is encoded
numerical value which represents the priority defined in the as per the "Resource-Priority Priority-Value" IANA registry.
"Resource-Priority Namespace" IANA registry for the (See IANA Considerations section for the request to IANA to
considered namespace, starting from 0 for the highest extend the registry to include this numerical value).
priority and increasing as priority decreases.
For example, as "flash-override", "flash", "immediate",
"priority" and "routine" are the priorities in decreasing
order of priority registered for the "dsn" namespace, those
are respectively encoded as value 0, 1, 2, 3 and 4. As
another example, as "flash-override-override", "flash-
override", "flash", "immediate", "priority" and "routine"
are the priorities in decreasing order of priority
registered for the "drsn" namespace, those are respectively
encoded as value 0, 1, 2, 3, 4 and 5.
Reserved: 16 bits
Always 0.
3.2.1. Application-Level Resource Priority Modifying and Merging Rules 3.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 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 29 skipping to change at page 13, line 21
As specified in [RSVP-POLICY], Standard RSVP Policy Elements (P-type As specified in [RSVP-POLICY], Standard RSVP Policy Elements (P-type
values) are to be assigned by IANA as per "IETF Consensus" following values) are to be assigned by IANA as per "IETF Consensus" following
the policies outlined in [IANA-CONSIDERATIONS]. the policies outlined in [IANA-CONSIDERATIONS].
IANA needs to allocate two P-Types from the Standard RSVP Policy IANA needs to allocate two P-Types from the Standard RSVP Policy
Element range: Element range:
- one P-Type to the Admission Priority Policy Element - one P-Type to the Admission Priority Policy Element
- one P-Type to the Application-Level Resource Priority - one P-Type to the Application-Level Resource Priority
Policy Element Policy Element
This document defines an ALRP Priority field in section 3.2 that The present document defines an ALRP Namespace field in section 3.2
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 currently listing all such namespace. However, that registry does not currently
allocate a numerical value to each namespace. Hence, this document allocate a numerical value to each namespace. Hence, this document
requests the IANA to extend the Resource-Priority Namespace registry requests the IANA to extend the Resource-Priority Namespace registry
in the following ways: in the following ways:
- a new column should be added to the registry - a new column should be added to the registry
- the title of the new column should be "Namespace numerical - the title of the new column should be "Namespace Numerical
Value *" Value *"
- in the Legend, add a line saying "Namespace numerical - in the Legend, add a line saying "Namespace Numerical
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- [draft-ietf-nsis-qspec] also uses numerical values for Resource-
Priority Namespaces. The request IANA to create a new registry to Priority Namespaces. To that end, the document requests IANA to
allocate numerical values to each namespace. We suggest that the create a new registry to allocate numerical values to each namespace.
approach above be followed instead (i.e. extend the existing We suggest that the approach above be followed instead (i.e. extend
registry) and that [draft-ietf-nsis-qspec] also makes use of the the existing registry) and that [draft-ietf-nsis-qspec] also makes
values defined in the new "Namespace numerical Value *" column of the use of the values defined in the new "Namespace numerical Value *"
extended existing Resource-Priority Namespace registry. In any case, column of the extended existing Resource-Priority Namespace registry.
the IANA should only do one of the two approaches (an not both).
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
that contains a numerical value identifying the actual application-
level resource priority within the application-level resource
priority namespace. The IANA already maintains the Resource-Priority
Priority-values registry (under the SIP Parameters) listing all such
priorities. However, that registry does not currently allocate a
numerical value to each priority-value. Hence, this document requests
the IANA to extend the Resource-Priority Priority-Values registry in
the following ways:
- for each namespace, the registry should be structured with
two columns
- the title of the first column should read "Priority Values
(least to greatest)"
- the first column should list all the values currently
defined in the registry (e.g. for the drsn namespace:
"routine", "priority", "immediate", "flash", "flash-
override", "flash-override-override" for the drsn
namespace)
- the title of the second column should read "Priority
Numerical Value *"
- At the bottom of the registry, add a "Legend" with a line
saying "Priority Numerical Value = the unique numerical
value identifying the priority within a namespace"
- add a line at the bottom of the registry stating the
following "* : [RFCXXX] " where XXX is the RFC number of
the present document
- allocate an actual numerical value to each and state that
value in the new "Priority Numerical Value *" column.
A numerical value should be allocated immediately by IANA to all
existing priority. Then, in the future, IANA should automatically
allocate a numerical value to any new namespace added to the registry.
The numerical value must be unique within each namespace. Within each
namespace, values should be allocated in decreasing order ending with
0 (so that the greatest priority is always allocated value 0). For
example, in the drsn namespace, "routine" would be allocated
numerical value 5 and "flash-override-override" would be 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
 End of changes. 14 change blocks. 
41 lines changed or deleted 87 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/