draft-ietf-rap-rsvp-ext-01.txt   draft-ietf-rap-rsvp-ext-02.txt 
Internet Draft Shai Herzog Internet Draft Shai Herzog
Expiration: Apr. 1999 IPHighway Expiration: July 1999 IPHighway
File: draft-ietf-rap-rsvp-ext-01.txt File: draft-ietf-rap-rsvp-ext-02.txt
RSVP Extensions for Policy Control RSVP Extensions for Policy Control
November 18, 1998 January 22, 1999
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts. documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other Internet Drafts may be updated, replaced, or obsoleted by other
skipping to change at page 1, line 39 skipping to change at page 1, line 39
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested. This document will and suggestions for improvement are requested. This document will
expire at the expiration date listed above. Distribution of this draft expire at the expiration date listed above. Distribution of this draft
is unlimited. is unlimited.
Abstract Abstract
This memo presents a set of extensions for supporting generic policy This memo presents a set of extensions for supporting generic policy
based admission control in RSVP. It should be perceived as an extension based admission control in RSVP. It should be perceived as an extension
to the RSVP functional specifications [RSVPSP] to the RSVP functional specifications [RSVP]
These extensions include the standard format of POLICY_DATA objects, These extensions include the standard format of POLICY_DATA objects,
and a description of RSVP's handling of policy events. and a description of RSVP's handling of policy events.
This document does not advocate particular policy control mechanisms; This document does not advocate particular policy control mechanisms;
however, a Router/Server Policy Protocol description for these however, a Router/Server Policy Protocol description for these
extensions can be found in [Fwk, COPS, COPS-RSVP]. extensions can be found in [RAP, COPS, COPS-RSVP].
Table of Contents Table of Contents
Abstract...............................................................1 Abstract...............................................................1
Table of Contents......................................................2 Table of Contents......................................................2
1. Introduction........................................................3 1. Introduction........................................................3
2. Policy Data Object Format...........................................3 2. Policy Data Object Format...........................................3
2.1. Base Format.......................................................4 2.1. Base Format.......................................................4
2.2. Options...........................................................4 2.2. Options...........................................................4
2.2.1.Native RSVP Options..............................................5 2.2.1.Native RSVP Options..............................................5
2.2.2.Other Options....................................................6 2.2.2.Other Options....................................................6
2.3. Policy Elements...................................................6 2.3. Policy Elements...................................................7
3. Processing Rules....................................................7 3. Processing Rules....................................................7
3.1. Basic Signaling...................................................7 3.1. Basic Signaling...................................................7
3.2. Error Signaling...................................................7 3.2. Default Handling..................................................7
3.3. Default Handling..................................................7 3.3. Error Signaling...................................................8
4. References..........................................................9 4. IANA Considerations.................................................8
5. Acknowledgments.....................................................9 5. References..........................................................9
6. Author Information..................................................9 6. Acknowledgments.....................................................9
7. Author Information..................................................9
A. Appendix: Policy Error Codes.......................................10
1. Introduction 1. Introduction
RSVP, by definition, discriminates between users, by providing some RSVP, by definition, discriminates between users, by providing some
users with better service at the expense of others. Therefore, it is users with better service at the expense of others. Therefore, it is
reasonable to expect that RSVP be accompanied by mechanisms for reasonable to expect that RSVP be accompanied by mechanisms for
controlling and enforcing access and usage policies. Historically, controlling and enforcing access and usage policies. Historically,
when RSVP Ver. 1 was developed, the knowledge and understanding of when RSVP Ver. 1 was developed, the knowledge and understanding of
policy issues was in its infancy. As a result, Ver. 1 of the RSVP policy issues was in its infancy. As a result, Ver. 1 of the RSVP
Functional Specifications [RSVPSP] left a place holder for policy Functional Specifications [RSVP] left a place holder for policy support
support in the form of POLICY_DATA objects. However, it deliberately in the form of POLICY_DATA objects. However, it deliberately refrained
refrained from specifying mechanisms, message formats, or providing from specifying mechanisms, message formats, or providing insight into
insight into how policy enforcement should be carried out. This how policy enforcement should be carried out. This document is intended
document is intended to fill in this void. to fill in this void.
The current RSVP Functional Specification describes the interface to The current RSVP Functional Specification describes the interface to
admission (traffic) control that is based "only" on resource admission (traffic) control that is based "only" on resource
availability. In this document we describe a set of extensions to RSVP availability. In this document we describe a set of extensions to RSVP
for supporting policy based admission control as well. The scope of for supporting policy based admission control as well. The scope of
this document is limited to these extensions and does not advocate this document is limited to these extensions and does not advocate
specific architectures for policy based controls. specific architectures for policy based controls.
For the purpose of this document we define Local Policy Module (LPM) as For the purpose of this document we do not differentiate between Policy
the policy entity within the RSVP node. This may be fully contained Decision Point (PDP) and Local Decision Point (LDPs) as described in
within the RSVP node or may be using an outsourcing mechanism such as [RAP]. The term PDP should be assumed to include LDP as well.
described in [Fwk, COPS, COPS-RSVP].
2. Policy Data Object Format 2. Policy Data Object Format
The following replaces section A.13 in [RSVPSP]. The following replaces section A.13 in [RSVP].
POLICY_DATA objects are carried by RSVP messages and contain policy POLICY_DATA objects are carried by RSVP messages and contain policy
information. All policy-capable nodes (at any location in the network) information. All policy-capable nodes (at any location in the network)
can generate, modify, or remove policy objects, even when senders or can generate, modify, or remove policy objects, even when senders or
receivers do not provide, and may not even be aware of policy data receivers do not provide, and may not even be aware of policy data
objects. objects.
The exchange of POLICY_DATA objects between policy-capable nodes along The exchange of POLICY_DATA objects between policy-capable nodes along
the data path, supports the generation of consistent end-to-end the data path, supports the generation of consistent end-to-end
policies. Furthermore, such policies can be successfully deployed policies. Furthermore, such policies can be successfully deployed
skipping to change at page 4, line 14 skipping to change at page 4, line 14
2.1. Base Format 2.1. Base Format
POLICY_DATA class=14 POLICY_DATA class=14
o Type 1 POLICY_DATA object: Class=14, C-Type=1 o Type 1 POLICY_DATA object: Class=14, C-Type=1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | POLICY_DATA | 1 | | Length | POLICY_DATA | 1 |
+---------------------------+-------------+-------------+ +---------------------------+-------------+-------------+
| Data Offset | Flags | 0 (reserved)| | Data Offset | 0 (reserved) |
+---------------------------+-------------+-------------+ +---------------------------+-------------+-------------+
| | | |
// Option List // // Option List //
| | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
| | | |
// Policy Element List // // Policy Element List //
| | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
Data Offset: 16 bits Data Offset: 16 bits
The offset in bytes of the data portion (from the first The offset in bytes of the data portion (from the first
byte of the object header). byte of the object header).
Flags: 8 bits Reserved: 16 bits
0x01 PCF_Updt
A modified object, don't check against previous one. This
is an optimization for systems that attempt to detect
unchanged refreshes of POLICY_DATA objects
Reserved: 8 bits
Always 0. Always 0.
Option List: Variable length Option List: Variable length
The list of options and their usage is defined in Section 2.2. The list of options and their usage is defined in Section 2.2.
Policy Element List: Variable length Policy Element List: Variable length
The contents of policy elements is opaque to RSVP. See more The contents of policy elements is opaque to RSVP. See more
details in Section 2.3. details in Section 2.3.
2.2. Options 2.2. Options
This section describes a set of options that may appear as options in This section describes a set of options that may appear in POLICY_DATA
POLICY_DATA objects. All policy options appear as RSVP objects; some objects. All policy options appear as RSVP objects; some use their
use their valid original format while others appear as NULL objects. valid original format while others appear as NULL objects.
2.2.1. Native RSVP Options 2.2.1. Native RSVP Options
The following objects retain the same format specified in [RSVPSP] The following objects retain the same format specified in [RSVP]
however, they gain different semantics when used inside POLICY_DATA however, they gain different semantics when used inside POLICY_DATA
objects. objects.
FILTER_SPEC object (list) FILTER_SPEC object (list) or SCOPE object
The set of senders associated with the POLICY_DATA object. If none is The set of senders associated with the POLICY_DATA object. If none is
provided, the policy information is assumed to be associated with all provided, the policy information is assumed to be associated with all
the flows of the session. the flows of the session. These two types of objects are mutually
exclusive, and cannot be mixed.
This option is only useful for WF or SE reservation styles, where This option is only useful for WF or SE reservation styles, where
merged reservations may have originally been intended for different merged reservations may have originally been intended for different
subsets of senders. It can also be used to prevent “policy loops” in a subsets of senders. It can also be used to prevent “policy loops” in a
manner similar to the usage of RSVP’s SCOPE object. Using this option manner similar to the usage of RSVP’s SCOPE object. Using this option
may have significant impact on scaling and size of POLICY_DATA objects may have significant impact on scaling and size of POLICY_DATA objects
and therefore should be taken with care. and therefore should be taken with care.
Originating RSVP_HOP Originating RSVP_HOP
skipping to change at page 6, line 15 skipping to change at page 6, line 16
replay attacks of POLICY_DATA objects from other sessions, flows, replay attacks of POLICY_DATA objects from other sessions, flows,
message types or even other network locations. message types or even other network locations.
2.2.2. Other Options 2.2.2. Other Options
All options that do not use a valid RSVP object format, should use the All options that do not use a valid RSVP object format, should use the
NULL RSVP object format with different CType values. This document NULL RSVP object format with different CType values. This document
defines only one such option, however, several other may be considered defines only one such option, however, several other may be considered
in future versions. (e.g., Fragmentation, NoChange, etc.). in future versions. (e.g., Fragmentation, NoChange, etc.).
o Policy Refresh Multiplier o Policy Refresh Period (PRP)
Some policies may have looser timing constraints than RSVP, and The Policy Refresh Period (PRP) option is used slow down policy refresh
therefore may allow for lower refresh frequency. If the Policy Refresh frequency for policies that have looser timing constraints compared
Multiplier option is present, policy is refreshed only once in with RSVP. If the PRP option is present, policy refreshes can be
"Multiplier" RSVP refreshes, for "Duplicates" times. withheld as long as at least one refresh is sent before the policy
refresh timer expires (PRP must be bigger than R).
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| 8 | NULL | 1 | | 8 | NULL | 1 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Multiplier | Duplicates | | Policy Refresh Period (PRP) (in seconds) |
+-------------+-------------+---------------------------+ +-------------+-------------+---------------------------+
For example, for "Multiplier=16" and "Duplicates=3", the policy should It is recommended that this infrequent policy refresh would be
be refreshed on RSVP's refreshes number 1,2,3,16,17,18,... piggybacked with normal RSVP refreshes. Given an RSVP refresh R, the
policy must be refreshed at least once in N RSVP refreshes, where
N=Floor(PRP/R) and the Floor function provides the integer portion of
the result.
Note: this option’s natural recovery time may be as long as Multiplier In effect, state cleanup rules apply specifically to the POLICY_DATA
times the RSVP refresh period. Hence, it should only be used in object as if the RSVP refresh period was N*R.
conjunction with longer-term policies or topologies that can tolerate
longer recovery time. Any RSVP update must include the full policy information. For example,
a policy being refreshed at time T, T+N, T+2N,... may encounter a route
change detected at T+X such that T < T+X < T+N. The update event would
force an immediate update of the policy and change its refresh times to
T+X, T+X+N, T+X+2N,...
When network nodes restart, it is possible that an RSVP message in
between policy refreshes would be rejected since it arrives to a node
that did not receive the original POLICY_DATA object. This error
situation would clear with the next periodic policy refresh or by an
update triggered by ResvErr or PathErr messages.
This option is especially useful to combine strong (high overhead) and
weak (low overhead) authentication certificates. In such schemes the
weak certificate supports admitting a reservation only for a limited
time, after which the strong certificate is required.
This approach may reduce the overhead of POLICY_DATA processing. Strong
certificates could be transmitted less frequently, while weak
certificates could be included in every RSVP refresh.
2.3. Policy Elements 2.3. Policy Elements
The contents of policy elements is opaque to RSVP and its internal The content of policy elements is opaque to RSVP; their internal format
format is only known to the Local Policy Module (LPM). A list of policy is understood by policy peers e.g. an RSVP Local Decision Point (LDP)
elements code points (based on P-type) starting from 0, is registered or a Policy Decision Point (PDP) [RAP]. A registry of policy element
with IANA. Local, Proprietary, and temporary P-Types can be used from codepoints and their meaning is maintained by [IANA-CONSIDERATIONS]
the high end and down (2^16-1 and down). (also see Section 4).
Policy Elements have the following format: Policy Elements have the following format:
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type | | Length | P-Type |
+---------------------------+---------------------------+ +---------------------------+---------------------------+
| | | |
// Policy information (Opaque to RSVP) // // Policy information (Opaque to RSVP) //
| | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
3. Processing Rules 3. Processing Rules
This sections describes the minimal required policy processing rules These sections describe the minimal required policy processing rules
for RSVP. for RSVP.
3.1. Basic Signaling 3.1. Basic Signaling
It is generally agreed that policy control should only be enforced for It is generally agreed that policy control should only be enforced for
Path, Resv, PathErr, and ResvErr. PathTear and ResvTear and assumed not Path, Resv, PathErr, and ResvErr. PathTear and ResvTear and assumed not
to require policy control based on two assumptions: First, that MD-5 to require policy control based on two assumptions: First, that
authentication verifies that the Tear is received from the same node Integrity verification [MD5] guarantee that the Tear is received from
that sent the initial reservation, and second, that it is functionally the same node that sent the installed reservation, and second, that it
equivalent to that node holding-off refreshes for this reservation. is functionally equivalent to that node holding-off refreshes for this
reservation.
3.2. Error Signaling
Policy errors are reported by either ResvErr or PathErr messages with a
policy failure error code (specified in [RSVPSP]). Policy error message
must include a POLICY_DATA object; the object contains details of the
error type and reason in a P-Type specific format.
If a multicast reservation fails due to policy reasons, RSVP should not
attempt to discover which reservation caused the failure (as it would
do for blockade state). Instead, it should attempt to deliver the
policy ResvErr to ALL downstream hops, and have the LPM decide where
messages should be sent. This mechanism allows the LPM to limit the
error distribution by deciding which "culprit" next-hops should be
informed. It also allows the LPM to prevent further distribution of
ResvErr or PathErr messages by performing local repair (e.g.
substituting the failed POLICY_DATA object with a different one).
3.3. Default Handling 3.2. Default Handling
It is generally assumed that policy enforcement (at least in its It is generally assumed that policy enforcement (at least in its
initial stages) is likely to concentrate on border nodes between initial stages) is likely to concentrate on border nodes between
autonomous systems. Consequently, policy objects transmitted at one autonomous systems. Consequently, policy objects transmitted at one
edge of an autonomous cloud may traverse intermediate non-policy- edge of an autonomous cloud may traverse intermediate policy ignorant
capable RSVP nodes. The minimal requirement from a non-policy-capable RSVP nodes (PINs). A PIN is required at a minimum to forward the
RSVP node is to forward POLICY_DATA objects embedded in the appropriate received POLICY_DATA objects in the appropriate outgoing messages
outgoing messages according to the following rules: according to the following rules:
o POLICY_DATA objects are to be forwarded as is, without any o POLICY_DATA objects are to be forwarded as is, without any
modifications. modifications.
o Multicast merging (splitting) nodes: o Multicast merging (splitting) nodes:
In the upstream direction: In the upstream direction:
When multiple POLICY_DATA objects arrive from downstream, the When multiple POLICY_DATA objects arrive from downstream, the
RSVP node should concatenate all of them and forward them with RSVP node should concatenate all of them and forward them with
the outgoing (upstream) message. the outgoing (upstream) message.
On the downstream direction: On the downstream direction:
When a single incoming POLICY_DATA object arrives from When a single incoming POLICY_DATA object arrives from
upstream, it should be forwarded (copied) to all downstream upstream, it should be forwarded (copied) to all downstream
branches of the multicast tree. branches of the multicast tree.
The same rules apply to unrecognized policies (sub-objects) within the The same rules apply to unrecognized policies (sub-objects) within the
POLICY_DATA object. However, since this can only occur in a policy- POLICY_DATA object. However, since this can only occur in a policy-
capable node, it is the responsibility of the LPM and not RSVP. capable node, it is the responsibility of the PDP and not RSVP.
4. References 3.3. Error Signaling
[Fwk] R. Yavatkar, D. Pendarakis, R. Guerin. "A Framework for Policy Policy errors are reported by either ResvErr or PathErr messages with a
Based Admission Control", Internet-Draft <draft-ietf-rap- policy failure error code in the ERROR_SPEC object. Policy error
framework-00.txt>, November, 1997. message must include a POLICY_DATA object; the object contains details
of the error type and reason in a P-Type specific format.
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., If a multicast reservation fails due to policy reasons, RSVP should not
Sastry, A., "The COPS (Common Open Policy Service) Protocol", attempt to discover which reservation caused the failure (as it would
Internet-Draft <draft-ietf-rap-cops-02.txt>, Aug. 1998. do for Blockade State). Instead, it should attempt to deliver the
policy ResvErr to ALL downstream hops, and have the PDP (or LDP) decide
where messages should be sent. This mechanism allows the PDP to limit
the error distribution by deciding which "culprit" next-hops should be
informed. It also allows the PDP to prevent further distribution of
ResvErr or PathErr messages by performing local repair (e.g.
substituting the failed POLICY_DATA object with a different one).
[RSVPSP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., Error codes are described in Appendix A.
"Resource Reservation Protocol (RSVP) Version 1 Functional
Specification", IETF RFC 2205, Proposed Standard, September
1997.
[MD5] F. Baker. “RSVP Cryptographic Authentication" Internet-Draft,
<draft-ietf-rsvp-md5-05.txt>, Aug. 1997.
5. Acknowledgments 4. IANA Considerations
RSVP Policy Elements
Following the policies outlined in [IANA-CONSIDERATIONS],numbers 0-
49151 are allocated as standard policy elements by IETF Consensus
action, numbers in the range 49152-53247 are allocated as vendor
specific (one per vendor) by First Come First Serve, and numbers 53248-
65535 are reserved for private use and are not assigned by IANA.
5. References
[RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission
Control",IETF <draft-ietf-rap-framework-02.txt>, Jan., 1999.
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., Sastry,
A., "The COPS (Common Open Policy Service) Protocol", IETF
<draft-ietf-rap-cops-05.txt>, Jan. 1999.
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
Functional Specification.", IETF RFC 2205, Proposed Standard,
Sep. 1997.
[MD5] Baker, F., Linden B., Talwar, M. “RSVP Cryptographic
Authentication" Internet-Draft, <draft-ietf-rsvp-md5-07.txt>,
Nov. 1998.
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", RFC 2434,
October 1998.
6. Acknowledgments
This document incorporates inputs from Lou Berger, Bob Braden, Deborah This document incorporates inputs from Lou Berger, Bob Braden, Deborah
Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, Raju Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, Raju
Rajan, Scott Shenker, Raj Yavatkar and many others. Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar, and many others.
6. Author Information 7. Author Information
Shai Herzog, IPHighway Shai Herzog, IPHighway
Parker Plaza, Suite 1500 Parker Plaza, Suite 1500
400 Kelby St. 400 Kelby St.
Fort-Lee, NJ 07024 Fort-Lee, NJ 07024
(201) 585-0800 (201) 585-0800
herzog@iphighway.com herzog@iphighway.com
A. Appendix: Policy Error Codes
This Appendix expends the list of error codes described in Appendix B
of [RSVP].
Note that Policy Element specific errors are reported as described in
Section 3.3 and cannot be reported through RSVP (using this mechanism).
However, this mechanism provides a simple, less secure mechanism for
reporting generic policy errors. Most likely the two would be used in
concert such that a generic error code is provided by RSVP, while
Policy Element specific errors are encapsulated in a return POLICY_DATA
object (as in Section 3.3).
ERROR_SPEC class = 6
Error Code = 02: Policy Control failure
Error Value: 16 bit
0 = ERR_INFO : Information reporting
1 = ERR_WARN : Warning
2 = ERR_UNKNOWN : Reason unknown
3 = ERR_REJECT : Generic Policy Rejection
4 = ERR_EXCEED : Quota or Accounting violation
5 = ERR_PREEMPT : Flow was preempted
6 = ERR_EXPIRED : Previously installed policy expired (not refreshed)
7 = ERR_REPLACED: Previous policy data was replaced & caused rejection
8 = ERR_MERGE : Policies could not be merged (multicast)
9 = ERR_PDP : PDP down or non functioning
10= ERR_SERVER : Third Party Server (e.g., Kerberos) unavailable
11= ERR_PD_SYNTX: POLICY_DATA object has bad syntax
12= ERR_PD_INTGR: POLICY_DATA object failed Integrity Check
13= ERR_PE_BAD : POLICY_ELEMENT object has bad syntax
14= ERR_PD_MISS : Mandatory PE Missing (Empty PE is in the PD object)
15= ERR_NO_RSC : PEP Out of resources to handle policies.
16= ERR_RSVP : PDP encountered bad RSVP objects or syntax
17= ERR_SERVICE : Service type was rejected
18= ERR_STYLE : Reservation Style was rejected
19= ERR_FL_SPEC : FlowSpec was rejected (too large)
Values between 2^15 and 2^16-1 can be used for site and/or vendor error
values.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/