draft-ietf-tsvwg-emergency-rsvp-02.txt   draft-ietf-tsvwg-emergency-rsvp-03.txt 
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-02.txt draft-ietf-tsvwg-emergency-rsvp-03.txt
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 23 skipping to change at page 2, line 23
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
1.3. Changes from previous versions.............................4 2. Overview of RSVP extensions and Operations.....................5
2. Overview of RSVP extensions and Operations.....................6 2.1. Operations of Admission Priority..........................7
2.1. Operations of Admission Priority..........................8 3. New Policy Elements............................................7
3. New Policy Elements............................................8 3.1. Admission Priority Policy Element.........................8
3.1. Admission Priority Policy Element.........................9 3.1.1. Admission Priority Merging Rules 9
3.1.1. Admission Priority Merging Rules 10 3.2. Application-Level Resource Priority Policy Element.......10
3.2. Application-Level Resource Priority Policy Element.......11
3.2.1. Application-Level Resource Priority Modifying and 3.2.1. Application-Level Resource Priority Modifying and
Merging Rules 12 Merging Rules 11
4. Security Considerations.......................................13 3.3. Default Handling.........................................11
4.1. Use of RSVP Authentication...............................13 4. Security Considerations.......................................12
4.2. Use of INTEGRITY object within the POLICY_DATA object....14 4.1. Use of RSVP Authentication between RSVP nighbors.........12
5. IANA Considerations...........................................14 4.2. Use of INTEGRITY object within the POLICY_DATA object....12
6. Acknowledgments...............................................15 5. IANA Considerations...........................................13
7. Normative References..........................................15 6. Acknowledgments...............................................14
7. Normative References..........................................14
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.........................................................17 Priority.........................................................16
A.1 Admission Priority with Maximum Allocation Model (MAM)......17 A.1 Admission Priority with Maximum Allocation Model (MAM)......16
A.2 Admission Priority with Russian Dolls Model (RDM)...........21 A.2 Admission Priority with Russian Dolls Model (RDM)...........20
A.3 Admission Priority with Priority Bypass Model (PBM).........23 A.3 Admission Priority with Priority Bypass Model (PrBM)........22
Appendix B: Example Usages of RSVP Extensions....................26 Appendix B: Example Usages of RSVP Extensions....................25
Authors' Address.................................................28 Authors' Address.................................................27
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 4, line 51 skipping to change at page 5, line 5
- Local Policy Decision Point (LPDP): PDP local to the network - Local Policy Decision Point (LPDP): PDP local to the network
element element
- Policy Enforcement Point (PEP): The point where the policy - Policy Enforcement Point (PEP): The point where the policy
decisions are actually enforced. decisions are actually enforced.
- Policy Ignorant Node (PIN): A network element that does not - 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
[FW-POLICY]. [FW-POLICY].
1.3. Changes from previous versions
[Note to RFC Editor: This section is to be removed before
publication]
Changes from ietf-tsvwg-emergency-rsvp-01 to ietf-tsvwg-emergency-
rsvp-02
The changes are:
o fix the idnits
o Removed reference to Kerberos in Security Considerations
section (in line with IESG review comment on Security
Considerations section of draft-ietf-tsvwg-rsvp-ipsec)
Changes from ietf-tsvwg-emergency-rsvp-00 to ietf-tsvwg-emergency-
rsvp-01
The most significant changes are:
o editorial change (correction in description of
"Take highest priority" in section 3.1.1).
o expanded Security Considerations section
Changes from lefaucheur-rsvp-emergency-01 to ietf-tsvwg-emergency-
rsvp-00
The most significant change is:
o Extended the Admission Priority field from 3 to 8 bits and
inverted the encoding order, in particular for better
alignment with NSIS Qspec.
Changes from lefaucheur-rsvp-emergency-01 to lefaucheur-rsvp-
emergency-02
The most significant changes are:
o modified the Introduction to add additional clarity and to
place related work in a better context to the extensions
proposed in this draft
o Moved bandwidth allocation models to an appendix
o Allowed multiple Application-Level Resource Priority inside
ALRP Policy Element
o Added a 2nd appendix providing examples of RSVP extensions
usage
Changes from lefaucheur-rsvp-emergency-00 to lefaucheur-rsvp-
emergency-01
The most significant changes were:
o adding a second RSVP Policy Element that contains the
application-level resource priority requirements (for example
as communicated in the SIP Resource-Priority Header) for
scenarios where priority calls transits through multiple
administrative domains.
o adding description of a third bandwidth allocation model
example: the Priority Bypass Model
o adding discussion on policies for mapping the various
bandwidth allocation model over the engineered capacity limits.
2. Overview of RSVP extensions and Operations 2. Overview of RSVP extensions and Operations
Let us consider the case where a call requiring ETS type service is Let us consider the case where a call requiring ETS type service is
to be established, and more specifically that the preference to be to be established, and more specifically that the preference to be
granted to this call is in terms of network layer "admission granted to this call is in terms of network layer "admission
priority" (as opposed to preference granted through preemption of priority" (as opposed to preference granted through preemption of
existing calls). By "admission priority" we mean allowing that existing calls). By "admission priority" we mean allowing that
priority call to seize network layer resources from the engineered priority call to seize network layer resources from the engineered
capacity that have been set-aside and not made available to normal capacity that have been set-aside and not made available to normal
calls, or alternatively by allowing that call to seize additional calls, or alternatively by allowing that call to seize additional
skipping to change at page 8, line 47 skipping to change at page 7, line 24
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 [DSTE- Those include the Maximum Allocation Model (MAM) defined in [DSTE-
MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These
same models MAY however be applied for allocation of bandwidth across same models MAY however be applied for allocation of bandwidth across
different levels of admission priority as defined in this document. different levels of admission priority as defined in this document.
Appendix A provides an illustration of how these bandwidth allocation Appendix A provides an illustration of how these bandwidth allocation
models can be applied for such purposes and introduces an additional models can be applied for such purposes and introduces an additional
bandwidth allocation model that we term the Priority Bypass Model bandwidth allocation model that we term the Priority Bypass Model
(PBM). It is important to note that the models described and (PrBM). It is important to note that the models described and
illustrated in Appendix A are only informative and do not represent a illustrated in Appendix A are only informative and do not represent a
recommended course of action. recommended course of action.
We can see in these examples, that the RSVP Admission Priority may
effectively influence the fundamental admission control decision of
RSVP (for example by determining which bandwidth pool is to be used
by RSVP for performing its fundamental bandwidth allocation). In that
sense, we observe that the policy control and admission control are
not separate logics but instead somewhat blended.
3. New Policy Elements 3. New Policy Elements
The Framework document for policy-based admission control [FW-POLICY] The Framework document for policy-based admission control [FW-POLICY]
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 2 of the present document, the Application- As described in section 2 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:
- the Application-Level Resource Priority Policy Element conveys - the Application-Level Resource Priority Policy Element conveys
application level information and is processed by PDPs application level information and is processed by PDPs
skipping to change at page 9, line 40 skipping to change at page 8, line 26
Element. Element.
This document defines two new Policy Elements called: This document defines two new Policy Elements called:
- the Admission Priority Policy Element - the Admission Priority Policy Element
- the Application-Level Resource Priority Policy Element - the Application-Level Resource Priority Policy Element
3.1. Admission Priority Policy Element 3.1. Admission Priority Policy Element
The format of the Admission Priority policy element is as follows: The format of the Admission Priority policy element is as follows:
0 0 0 1 1 2 2 3
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 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
|Adm. Priority| Reserved | | 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 (MUST be set to zero on transmit and ignored on
receive) receive)
Merge Strategy: 8 bit (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)
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. Always 0.
Reserved: 24 bits
Always 0.
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 network bandwidth in order to provide higher probability of to network bandwidth in order to provide higher probability of
call completion to selected flows. Higher values represent call completion to selected flows. Higher values represent
higher Priority. higher Priority.
Bandwidth allocation models such as those described in Appendix Bandwidth allocation models such as those described in Appendix
A are to be used by the RSVP router to achieve such increased A are to be used by the RSVP router to achieve such increased
probability of call completion. The admission priority value probability of call completion. The admission priority value
effectively indicates which bandwidth constraint(s) of the effectively indicates which bandwidth constraint(s) of the
bandwidth constraint model in use is(are) applicable to bandwidth constraint model in use is(are) applicable to
admission of this RSVP reservation. admission of this RSVP reservation.
Reserved: 16 bits
Always 0.
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 orthogonal and independent Priority are handled by LPDPs and PEPs as separate mechanisms. They
mechanisms. can be used one without the other, or they can be used both in
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 11, line 28 skipping to change at page 10, line 19
Note that with the Admission Priority (as is the case with the Note that with the Admission Priority (as is the case with the
Preemption Priority), "Take highest priority" translates into "take Preemption Priority), "Take highest priority" translates into "take
the highest numerical value". the highest numerical value".
3.2. Application-Level Resource Priority Policy Element 3.2. Application-Level Resource Priority Policy Element
The format of the Application-Level Resource Priority policy element The format of the Application-Level Resource Priority policy element
is as follows: is as follows:
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type = APP_RESOURCE_PRI | | Length | P-Type = APP_RESOURCE_PRI |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// ALRP List // // ALRP List //
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Length: The length of the policy element (including the Length and P- Length: The length of the policy element (including the Length and P-
Type) is in number of octets (MUST be a multiple of 4) and 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.
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)
ARLP: ALRP:
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+---------------------------+---------------------------+ +---------------------------+---------------------------+
| ALRP Namespace |ALRP Priority| Reserved | | 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 the namespace of the application-level resource Contains a numerical value identifying the namespace of the
priority. This is encoded as a numerical value which application-level resource priority. This value is encoded
represents the position of the namespace in the "Resource- as per the "Resource-Priority Namespace" IANA registry. (See
Priority Namespace" IANA registry, starting with 0. Creation IANA Considerations section for the request to IANA to
of this registry has been requested to IANA in [SIP- extend the registry to include this numerical value).
PRIORITY].
For example, as "drsn", "dsn", "q735", "ets" and "wps" are
currently the first, second, third, fourth and fifth
namespaces defined in the "Resource-Priority Namespace"
registry, those are respectively encoded as value 0, 1, 2, 3
and 4.
ALRP Priority: (Application-Level Resource Priority Priority): 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 is encoded as a
numerical value which represents the priority defined in the numerical value which represents the priority defined in the
"Resource-Priority Namespace" IANA registry for the "Resource-Priority Namespace" IANA registry for the
considered namespace, starting from 0 for the highest considered namespace, starting from 0 for the highest
priority and increasing as priority decreases. priority and increasing as priority decreases.
For example, as "flash-override", "flash", "immediate", For example, as "flash-override", "flash", "immediate",
skipping to change at page 12, line 35 skipping to change at page 11, line 26
are respectively encoded as value 0, 1, 2, 3 and 4. As are respectively encoded as value 0, 1, 2, 3 and 4. As
another example, as "flash-override-override", "flash- another example, as "flash-override-override", "flash-
override", "flash", "immediate", "priority" and "routine" override", "flash", "immediate", "priority" and "routine"
are the priorities in decreasing order of priority are the priorities in decreasing order of priority
registered for the "drsn" namespace, those are respectively registered for the "drsn" namespace, those are respectively
encoded as value 0, 1, 2, 3, 4 and 5. encoded as value 0, 1, 2, 3, 4 and 5.
Reserved: 16 bits Reserved: 16 bits
Always 0. Always 0.
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:
The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list
all the ALRPs appearing in the ALRP List of an incoming all the ALRPs appearing in the ALRP List of an incoming
APP_RESOURCE_PR 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 reunion of once. In other words, the outgoing ALRP List is the union of the
the incoming ARLP Lists that are merged. incoming ALRP Lists that are merged.
As merging is only applicable to Multicast, this rule only applies to As merging is only applicable to Multicast, this rule only applies to
Multicast sessions. Multicast sessions.
3.3. Default Handling
As specified in section 4.2 of [RSVP-POLICY], Policy Ignorant Nodes
(PINs) implement a default handling of POLICY_DATA objects ensuring
that those objects can traverse PIN nodes in transit from one PEP to
another. This applies to the situations where POLICY_DATA objects
contain the Admission Priority Policy Element and the ALRP Policy
Element specified in this document, so that those can traverse PIN
nodes.
Section 4.2 of [RSVP-POLICY] also defines a similar default behavior
for policy-capable nodes that do not recognized a particular Policy
Element. This applies to the Admission Priority Policy Element and
the ALRP Policy Element specified in this document, so that those can
traverse policy-capable nodes that do not support this document.
4. Security Considerations 4. Security Considerations
The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can
be signaled by RSVP through encapsulation in a Policy Data object as be signaled by RSVP through encapsulation in a Policy Data object as
defined in [RSVP-POLICY]. Therefore, like any other Policy Elements, defined in [RSVP-POLICY]. Therefore, like any other Policy Elements,
their integrity can be protected as discussed in section 6 of [RSVP- their integrity can be protected as discussed in section 6 of [RSVP-
POLICY] by two optional security mechanisms. The first mechanism POLICY] by two optional security mechanisms. The first mechanism
relies on RSVP Authentication as specified in [RSVP-CRYPTO-1] and relies on RSVP Authentication as specified in [RSVP-CRYPTO-1] and
[RSVP-CRYPTO-2] to provide a chain of trust when all RSVP nodes are [RSVP-CRYPTO-2] to provide a chain of trust when all RSVP nodes are
policy capable. The second mechanism relies on the INTEGRITY object policy capable. With this mechanism, the INTEGRITY object is carried
within the POLICY_DATA object to guarantee integrity between RSVP inside RSVP messages. The second mechanism relies on the INTEGRITY
Policy Enforcement Points (PEPs) that are not RSVP neighbors. object within the POLICY_DATA object to guarantee integrity between
RSVP Policy Enforcement Points (PEPs) that are not RSVP neighbors.
4.1. Use of RSVP Authentication
[RSVP-CRYPTO-1] discusses several approaches for distribution of keys
to be used for RSVP Authentication. First, the RSVP Authentication
shared keys can be distributed manually. This is the base option and
its support is mandated for any implementation. However, in some
environments, this approach may become a burden if keys frequently
change over time. Alternatively, a standard key management protocol
for secure key distribution can be used. However, existing key
distribution protocols may not be appropriate in all environments
because of the complexity or operational burden they involve.
The use of RSVP Authentication in parts of the network where there
may be one or more IP hops in between two RSVP neighbors raises an
additional challenge. This is because, with some RSVP messages such
as a Path message, an RSVP router does not know the RSVP next hop for
that message at the time of forwarding it. In fact, part of the role
of a Path message is precisely to discover the RSVP next hop (and to
dynamically re-discover it when it changes, say because of a routing
change). Hence, the RSVP router may not know which security
association to use when forwarding such a message.
In that situation, one approach is to share the same RSVP 4.1. Use of RSVP Authentication between RSVP nighbors
Authentication shared key across all the RSVP routers of a part of
the network where there may be RSVP neighbors with IP hops in between.
For example, all the RSVP routers of an administrative domain could
share the same RSVP Authentication key, while different per-neighbor
keys could be used between any RSVP router pair straddling the
boundary between two administrative domains that have agreed to use
RSVP signaling.
When the same RSVP Authentication shared key is to be shared among This mechanism can be used can be used between RSVP neighbors that
multiple RSVP neighbors, manual key distribution may be used. For are policy capable. The RSVP neighbors use shared keys to compute the
situations where RSVP is being used for multicast flows, it might cryptographic signature of the RSVP message. [RSVP-GROUPKEYING]
also be possible, in the future, to adapt a multicast key management discusses key types, key provisioning methods as well as their
method (e.g. from IETF Multicast Security Working Group) for key respective applicability.
distribution with such multicast RSVP usage. For situations where
RSVP is being used for unicast flows across domain boundaries, it is
not currently clear how one might provide automated key management.
Specification of a specific automated key management technique is
outside the scope of this document. Operators should consider these
key management issues when contemplating deployment of this
specification.
4.2. Use of INTEGRITY object within the POLICY_DATA object 4.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. guarantee integrity between non-neighboring RSVP PEPs.
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 [RSVP-POLICY]. This states that the Policy found in Appendix B of [RSVP-POLICY]. This states that the Policy
Decision Point (PDP), at its discretion, and based on destination Decision Point (PDP), at its discretion, and based on 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 distributed algorithm to be used. Keys to be used between PDPs can be distributed
manually or via standard key management protocol for secure key manually or via standard key management protocol for secure key
distribution. 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 Policy Ignorant Nodes (PINs) may exist in
between PEPs, it may be difficult for the PDP to determine what is between PEPs, it may be difficult for the PDP to determine what is
the destination PDP for a POLICY_DATA object contained in some RSVP the destination PDP for a POLICY_DATA object contained in some RSVP
messages (such as a Path message). This is because in those cases the messages (such as a Path message). This is because in those cases the
next PEP is not known at the time of forwarding the message. This next PEP is not known at the time of forwarding the message. In this
issue is similar to the one discussed in section 4.1, except it now situation, key shared across multiple PDPs may be used. This is
applies to PDP neighbors instead of RSVP neighbors. Hence similar conceptually similar to the use of key shared across multiple RSVP
approaches could be used, such as the use of a key shared across neighbors discussed in [RSVP-GROUPKEYING]. We observe also that this
multiple PDPs. We observe that this issue may not exist in some issue may not exist in some deployment scenarios where a single (or
deployment scenarios where a single (or low number of) PDP is used to low number of) PDP is used to control all the PEPs of a region (such
control all the PEPs of a region (such as an administrative domain). as an administrative domain). In such scenarios, it may be easy for a
In such scenarios, it may be easy for a PDP to determine what is the PDP to determine what is the next hop PDP, even when the next hop PEP
next hop PDP, even when the next hop PEP is not known, simply by is not known, simply by determining what is the next region that will
determining what is the next region that will be traversed (say based be traversed (say based on the destination address).
on the destination address).
5. IANA Considerations 5. IANA Considerations
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
contains a numerical value identifying the namespace of the
application-level resource priority. The IANA already maintains the
Resource-Priority Namespaces registry (under the SIP Parameters)
listing all such namespace. However, that registry does not currently
allocate a numerical value to each namespace. Hence, this document
requests the IANA to extend the Resource-Priority Namespace registry
in the following ways:
- a new column should be added to the registry
- the title of the new column should be "Namespace numerical
Value *"
- in the Legend, add a line saying "Namespace numerical
Value = the unique numerical value identifying the
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 namespace in
the registry and state that value in the new "Namespace
numerical Value *" column.
A numerical value should be allocated immediately by IANA to all
existing namespace. Then, in the future, IANA should automatically
allocate a numerical value to any new namespace added to the registry.
[draft-ietf-nsis-qspec] also uses numerical values for Resource-
Priority Namespaces. The request 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 only do one of the two approaches (an 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 16, line 33 skipping to change at page 15, line 36
[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.
[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 Security using Dynamic Group Keying", draft-behringer-tsvwg-
rsvp-security-groupkeying-00.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-
RDM] can be used for support of admission priority. Section A.3 RDM] can be used for support of admission priority. Section A.3
skipping to change at page 23, line 32 skipping to change at page 22, line 32
|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
--------------------------------------- ---------------------------------------
Chart 9. Full non-priority load & Full Aggregate load Chart 9. Full non-priority load & Full Aggregate load
A.3 Admission Priority with Priority Bypass Model (PBM) 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 (PBM) is used for bandwidth allocation simple Priority Bypass Model (PrBM) is used for bandwidth allocation
across non-priority traffic and priority traffic. With the Priority across non-priority traffic and priority traffic. With the Priority
Bypass Model, non-priority traffic is subject to resource based Bypass Model, non-priority traffic is subject to resource based
admission control while priority traffic simply bypasses the resource admission control while priority traffic simply bypasses the resource
based admission control. In other words: based admission control. In other words:
- when a non-priority call arrives, this call is subject to - when a non-priority call arrives, this call is subject to
bandwidth admission control and is accepted if the current total load bandwidth admission control and is accepted if the current total load
(aggregate over non-priority and priority traffic) is below the (aggregate over non-priority and priority traffic) is below the
engineered/allocated bandwidth. engineered/allocated bandwidth.
- when a priority call arrives, this call is admitted regardless - when a priority call arrives, this call is admitted regardless
of the current load. of the current load.
skipping to change at page 29, line 30 skipping to change at page 28, line 30
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
PURPOSE.
 End of changes. 33 change blocks. 
177 lines changed or deleted 134 lines changed or added

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