draft-ietf-rap-rsvp-ext-04.txt   draft-ietf-rap-rsvp-ext-05.txt 
Internet Draft Shai Herzog Internet Draft Shai Herzog
Expiration: August 1999 IPHighway Expiration: October 1999 IPHighway
File: draft-ietf-rap-rsvp-ext-04.txt File: draft-ietf-rap-rsvp-ext-05.txt
Updates RFC 2205 Updates RFC 2205
RSVP Extensions for Policy Control RSVP Extensions for Policy Control
February 26, 1999 April 2, 1999
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
This document does not advocate particular policy control This document does not advocate particular policy control
mechanisms; mechanisms;
however, a Router/Server Policy Protocol description for these however, a Router/Server Policy Protocol description for these
extensions can be found in [RAP, 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 Objects................................................3
2.1 Base Format.....................................................4 2.1 Base Format.....................................................4
2.2 Options.........................................................4 2.2 Options.........................................................4
2.3 Native RSVP Options.............................................5 2.3 Policy Elements.................................................6
2.4 Other Options...................................................6 2.4 Purging Policy State............................................7
2.5 Policy Elements.................................................7
3 Processing Rules...................................................7 3 Processing Rules...................................................7
3.1 Basic Signaling.................................................7 3.1 Basic Signaling.................................................7
3.2 Default Handling................................................7 3.2 Default Handling................................................7
3.3 Error Signaling.................................................8 3.3 Error Signaling.................................................8
4 IANA Considerations................................................9 4 IANA Considerations................................................9
5 Security Considerations............................................9 5 Security Considerations............................................9
6 References........................................................10 6 References........................................................10
7 Acknowledgments...................................................10 7 Acknowledgments...................................................10
8 Author Information................................................10 8 Author Information................................................10
A. Appendix: Policy Error Codes.....................................11 Appendix A: Policy Error Codes......................................11
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. Ver. 1 of the
when RSVP Ver. 1 was developed, the knowledge and understanding of RSVP Functional Specifications [RSVP] left a placeholder for policy
policy issues was in its infancy. As a result, Ver. 1 of the RSVP support in the form of POLICY_DATA object.
Functional Specifications [RSVP] left a place holder for policy
support in the form of POLICY_DATA objects. However, it deliberately
refrained from specifying mechanisms, message formats, or providing
insight into how policy enforcement should be carried out. This
document is intended 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 availability. In this document we describe a set of extensions to
RSVP for supporting policy based admission control as well. The RSVP for supporting policy based admission control as well. The
scope of this document is limited to these extensions and does not scope of this document is limited to these extensions and does not
advocate specific architectures for policy based controls. advocate specific architectures for policy based controls.
For the purpose of this document we do not differentiate between For the purpose of this document we do not differentiate between
Policy Decision Point (PDP) and Local Decision Point (LDPs) as Policy Decision Point (PDP) and Local Decision Point (LDPs) as
described in [RAP]. The term PDP should be assumed to include LDP as described in [RAP]. The term PDP should be assumed to include LDP as
well. well.
2 Policy Data Object Format 2 Policy Data Objects
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 information. All policy-capable nodes (at any location in the
network) can generate, modify, or remove policy objects, even when network) can generate, modify, or remove policy objects, even when
senders or receivers do not provide, and may not even be aware of senders or receivers do not provide, and may not even be aware of
policy data objects. policy data objects.
The exchange of POLICY_DATA objects between policy-capable nodes The exchange of POLICY_DATA objects between policy-capable nodes
along the data path, supports the generation of consistent end-to- along the data path, supports the generation of consistent end-to-
end policies. Furthermore, such policies can be successfully end policies. Furthermore, such policies can be successfully
deployed across multiple administrative domains when border nodes deployed across multiple administrative domains when border nodes
manipulate and translate POLICY_DATA objects according to manipulate and translate POLICY_DATA objects according to
established sets of bilateral agreements. established sets of bilateral agreements.
The following extends section A.13 in [RSVP].
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 | 0 (reserved) | | Data Offset | 0 (reserved) |
skipping to change at page 4, line 42 skipping to change at page 4, line 42
Always 0. Always 0.
Option List: Variable length Option List: Variable length
The list of options and their usage is defined in Section The list of options and their usage is defined in Section
2.2. 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.5. details in Section 2.3.
2.2 Options 2.2 Options
This section describes a set of options that may appear in This section describes a set of options that may appear in
POLICY_DATA objects. All policy options appear as RSVP objects; some POLICY_DATA objects. All policy options appear as RSVP objects but
use their valid original format while others appear as NULL objects. their semantic is modified when used as policy data options.
2.3 Native RSVP Options FILTER_SPEC object (list) or SCOPE object
The following objects retain the same format specified in [RSVP] These objects describe the set of senders associated with the
however, they gain different semantics when used inside POLICY_DATA POLICY_DATA object. If none is provided, the policy information is
objects. assumed to be associated with all the flows of the session. These
two types of objects are mutually exclusive, and cannot be mixed.
FILTER_SPEC object (list) or SCOPE object In Packed FF Resv messages, this FILTER_SPEC option provides
association between a reserved flow and its POLICY_DATA objects.
The set of senders associated with the POLICY_DATA object. If none In WF or SE styles, this option preserves the original
is provided, the policy information is assumed to be associated with flow/POLICY_DATA association as formed by PDPs, even across RSVP
all the flows of the session. These two types of objects are capable PIN nodes. Such preservation is required since PIN nodes may
mutually exclusive, and cannot be mixed. change the list of reserved flows on a per-hop basis, irrespective
of legitimate Edge-to-Edge PDP policy considerations.
This option is only useful for WF or SE reservation styles, where Last, the SCOPE object should be used to prevent "policy loops" in a
merged reservations may have originally been intended for different manner similar to the one described in [RSVP], Section 3.4. When PIN
subsets of senders. It can also be used to prevent "policy loops" in nodes are part of a WF reservation path, the RSVP SCOPE object is
a manner similar to the usage of RSVP's SCOPE object. Using this unable to prevent policy loops and the separate policy SCOPE object
option may have significant impact on scaling and size of is required.
POLICY_DATA objects and therefore should be taken with care.
Note: using the SCOPE option may have significant impact on scaling
and size of POLICY_DATA objects.
Originating RSVP_HOP Originating RSVP_HOP
The RSVP_HOP object identifies the neighbor/peer policy-capable node The RSVP_HOP object identifies the neighbor/peer policy-capable node
that constructed the policy object. When policy is enforced at that constructed the policy object. When policy is enforced at
border nodes, peer policy nodes may be several RSVP hops away from border nodes, peer policy nodes may be several RSVP hops away from
each other and the originating RSVP_HOP is the basis for the each other and the originating RSVP_HOP is the basis for the
mechanism that allows them to recognize each other and communicate mechanism that allows them to recognize each other and communicate
safely and directly. safely and directly.
skipping to change at page 5, line 48 skipping to change at page 5, line 46
Destination RSVP_HOP Destination RSVP_HOP
A second RSVP_HOP object may follow the originating RSVP_HOP object. A second RSVP_HOP object may follow the originating RSVP_HOP object.
This second RSVP_HOP identifies the destination policy node. This is This second RSVP_HOP identifies the destination policy node. This is
used to ensure the POLICY_DATA object is delivered to targeted used to ensure the POLICY_DATA object is delivered to targeted
policy nodes. It may be used to emulate unicast delivery in policy nodes. It may be used to emulate unicast delivery in
multicast Path messages. It may also help prevent using a policy multicast Path messages. It may also help prevent using a policy
object in other parts of the network (replay attack). object in other parts of the network (replay attack).
On the receiving side, a policy node should ignore any POLCY_DATA On the receiving side, a policy node should ignore any POLICY_DATA
that includes a destination RSVP_HOP that doesn't match its own IP that includes a destination RSVP_HOP that doesn't match its own IP
address. address.
INTEGRITY Object INTEGRITY Object
The INTEGRITY object provides guarantees that the object was not The INTEGRITY object provides guarantees that the object was not
compromised. It follows the rules from [MD5], and is calculated over compromised. It follows the rules from [MD5], and is calculated over
the POLICY_DATA object, the SESSION object, and the message type the POLICY_DATA object, the SESSION object, and the message type
field (byte, padded with zero to 32 bit) as if they formed one field (byte, padded with zero to 32 bit) as if they formed one
continuous in-order message. This concatenation is designed to continuous in-order message. This concatenation is designed to
prevent copy and replay attacks of POLICY_DATA objects from other prevent copy and replay attacks of POLICY_DATA objects from other
sessions, flows, message types or even other network locations. sessions, flows, message types or even other network locations.
2.4 Other Options Policy Refresh TIME_VALUES (PRT)
All options that do not use a valid RSVP object format, should use
the NULL RSVP object format with different C-Type values. This
document defines only one such option, however, several other may be
considered in future versions. (e.g., Fragmentation, NoChange,
etc.).
o Policy Refresh Period (PRP)
The Policy Refresh Period (PRP) option is used slow down policy The Policy Refresh TIME_VALUES (PRT) option is used to slow policy
refresh frequency for policies that have looser timing constraints refresh frequency for policies that have looser timing constraints
compared with RSVP. If the PRP option is present, policy refreshes relative to RSVP. If the PRT option is present, policy refreshes can
can be withheld as long as at least one refresh is sent before the be withheld as long as at least one refresh is sent before the
policy refresh timer expires (PRP must be bigger than R). policy refresh timer expires. A minimal value for PRT is R; lower
values are assumed to be R (neither error nor warning should be
+-------------+-------------+-------------+-------------+ triggered).
| 8 | NULL | 1 |
+-------------+-------------+-------------+-------------+
| Policy Refresh Period (PRP) (in seconds) |
+-------------+-------------+---------------------------+
It is recommended that this infrequent policy refresh would be
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.
In effect, state cleanup rules apply specifically to the POLICY_DATA To simplify RSVP processing, time values are not based directly on
object as if the RSVP refresh period was N*R. the PRT value, but on a Policy Refresh Multiplier N computed as
N=Floor(PRT/R). Refresh and cleanup rules are derived from [RSVP]
Section 3.7 assuming the refresh period for PRT POLICY DATA is R'
computed as R'=N*R. In effect, both the refresh and the state
cleanup are slowed by a factor of N).
Any RSVP update must include the full policy information. For The refresh multiplier applies to no-change periodic refreshes only
example, a policy being refreshed at time T, T+N, T+2N,... may (rather than updates). For example, a policy being refreshed at time
encounter a route change detected at T+X such that T < T+X < T+N. T, T+N, T+2N,... may encounter a route change detected at T+X. In
The update event would force an immediate update of the policy and this case, the event would force an immediate policy update and
change its refresh times to T+X, T+X+N, T+X+2N,... would reset refresh times to T+X, T+X+N, T+X+2N,...
When network nodes restart, it is possible that an RSVP message in When network nodes restart, RSVP messages between PRT policy
between policy refreshes would be rejected since it arrives to a refreshes may be rejected since they arrive without necessary
node that did not receive the original POLICY_DATA object. This POLICY_DATA objects. This error situation would clear with the next
error situation would clear with the next periodic policy refresh or periodic policy refresh or with a policy update triggered by ResvErr
by an update triggered by ResvErr or PathErr messages. or PathErr messages.
This option is especially useful to combine strong (high overhead) This option is especially useful to combine strong (high overhead)
and weak (low overhead) authentication certificates. In such schemes and weak (low overhead) authentication certificates as policy data.
the weak certificate supports admitting a reservation only for a In such schemes the weak certificate can support admitting a
limited time, after which the strong certificate is required. reservation only for a limited time, after which the strong
certificate is required.
This approach may reduce the overhead of POLICY_DATA processing. This approach may reduce the overhead of POLICY_DATA processing.
Strong certificates could be transmitted less frequently, while weak Strong certificates could be transmitted less frequently, while weak
certificates could be included in every RSVP refresh. certificates are included in every RSVP refresh.
2.5 Policy Elements 2.3 Policy Elements
The content of policy elements is opaque to RSVP; their internal The content of policy elements is opaque to RSVP; their internal
format is understood by policy peers e.g. an RSVP Local Decision format is understood by policy peers e.g. an RSVP Local Decision
Point (LDP) or a Policy Decision Point (PDP) [RAP]. A registry of Point (LDP) or a Policy Decision Point (PDP) [RAP]. A registry of
policy element codepoints and their meaning is maintained by [IANA- policy element codepoints and their meaning is maintained by [IANA-
CONSIDERATIONS] (also see Section 4). CONSIDERATIONS] (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) //
| | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
2.4 Purging Policy State
Policy state expires in the granularity of Policy Elements
(POLICY_DATA objects are mere containers and do not expire as such).
Policy elements expire in the exact manner and time as the RSVP
state received in the same message (see [RSVP] Section 3.7). PRT
controlled state expires N times slower (see Section 2.2).
Only one policy element of a certain P-Type can be active at any
given time. Therefore, policy elements are instantaneously replaced
when another policy element of the same P-Type is received from the
same PDP (previous or next policy RSVP_HOP). An empty policy element
of a certain P-Type is used to delete (rather than a replace) all
policy state of the same P-Type.
3 Processing Rules 3 Processing Rules
These sections describe 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 This draft mandates enforcing policy control for Path, Resv,
for Path, Resv, PathErr, and ResvErr. PathTear and ResvTear and PathErr, and ResvErr messages only. PathTear and ResvTear are
assumed not to require policy control based on two assumptions: assumed not to require policy control based on two main
First, that Integrity verification [MD5] guarantee that the Tear is presumptions. First, that Integrity verification [MD5] guarantee
received from the same node that sent the installed reservation, and that the Tear is received from the same node that sent the installed
second, that it is functionally equivalent to that node holding-off reservation, and second, that it is functionally equivalent to that
refreshes for this reservation. node holding-off refreshes for this reservation.
3.2 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 policy edge of an autonomous cloud may traverse intermediate policy
ignorant RSVP nodes (PINs). A PIN is required at a minimum to ignorant RSVP nodes (PINs). A PIN is required at a minimum to
forward the received POLICY_DATA objects in the appropriate outgoing forward the received POLICY_DATA objects in the appropriate outgoing
messages according to the following rules: messages 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 RSVP node should concatenate all of them (as a list of the
with the outgoing (upstream) message. original POLICY_DATA objects) and forward them with 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 same rules apply to unrecognized policies (sub-objects) within
the POLICY_DATA object. However, since this can only occur in a the POLICY_DATA object. However, since this can only occur in a
policy-capable node, it is the responsibility of the PDP and not policy-capable node, it is the responsibility of the PDP and not
RSVP. RSVP.
3.3 Error Signaling 3.3 Error Signaling
Policy errors are reported by either ResvErr or PathErr messages Policy errors are reported by either ResvErr or PathErr messages
with a policy failure error code in the ERROR_SPEC object. Policy with a policy failure error code in the ERROR_SPEC object. Policy
error message must include a POLICY_DATA object; the object contains error message must include a POLICY_DATA object; the object contains
details of the error type and reason in a P-Type specific format. details of the error type and reason in a P-Type specific format
(See Section 2.3).
If a multicast reservation fails due to policy reasons, RSVP should If a multicast reservation fails due to policy reasons, RSVP should
not attempt to discover which reservation caused the failure (as it not attempt to discover which reservation caused the failure (as it
would do for Blockade State). Instead, it should attempt to deliver would do for Blockade State). Instead, it should attempt to deliver
the policy ResvErr to ALL downstream hops, and have the PDP (or LDP) the policy ResvErr to ALL downstream hops, and have the PDP (or LDP)
decide where messages should be sent. This mechanism allows the PDP decide where messages should be sent. This mechanism allows the PDP
to limit the error distribution by deciding which "culprit" next- to limit the error distribution by deciding which "culprit" next-
hops should be informed. It also allows the PDP to prevent further hops should be informed. It also allows the PDP to prevent further
distribution of ResvErr or PathErr messages by performing local distribution of ResvErr or PathErr messages by performing local
repair (e.g. substituting the failed POLICY_DATA object with a repair (e.g. substituting the failed POLICY_DATA object with a
different one). different one).
Error codes are described in Appendix A. Error codes are described in Appendix A.
4 IANA Considerations 4 IANA Considerations
RSVP Policy Elements RSVP Policy Elements (P-Types)
Following the policies outlined in [IANA-CONSIDERATIONS],numbers 0- Following the policies outlined in [IANA-CONSIDERATIONS],numbers 0-
49151 are allocated as standard policy elements by IETF Consensus 49151 are allocated as standard policy elements by IETF Consensus
action, numbers in the range 49152-53247 are allocated as vendor action, numbers in the range 49152-53247 are allocated as vendor
specific (one per vendor) by First Come First Serve, and numbers specific (one per vendor) by First Come First Serve, and numbers
53248-65535 are reserved for private use and are not assigned by 53248-65535 are reserved for private use and are not assigned by
IANA. IANA.
5 Security Considerations 5 Security Considerations
This draft describes the use of POLICY_DATA objects to carry policy- This draft describes the use of POLICY_DATA objects to carry policy-
related information between RSVP nodes. Two security mechanisms can related information between RSVP nodes. Two security mechanisms can
be optionally used to ensure the integrity of the carried be optionally used to ensure the integrity of the carried
information. The first mechanism relies on RSVP integrity [MD5] to information. The first mechanism relies on RSVP integrity [MD5] to
provide a chain of trust when all RSVP nodes are policy capable. The provide a chain of trust when all RSVP nodes are policy capable. The
second mechanism relies on the INTEGRITY object within the second mechanism relies on the INTEGRITY object within the
POLICY_DATA object to guarantee integrity between non-neighboring POLICY_DATA object to guarantee integrity between non-neighboring
RSVP PEPs. (See Section 2.3). RSVP PEPs (see Section 2.2).
6 References 6 References
[RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission
Control",IETF <draft-ietf-rap-framework-02.txt>, Jan., 1999. Control",IETF <draft-ietf-rap-framework-02.txt>, Jan., 1999.
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R.,
Sastry, A., "The COPS (Common Open Policy Service) Protocol", Sastry, A., "The COPS (Common Open Policy Service) Protocol",
IETF <draft-ietf-rap-cops-05.txt>, Jan. 1999. IETF <draft-ietf-rap-cops-05.txt>, Jan. 1999.
[COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R.,
Sastry, A., "COPS Usage for RSVP", IETF <draft-ietf-rap-cops-
rsvp-04.txt>, Feb. 1999.
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
Functional Specification.", IETF RFC 2205, Proposed Standard, Functional Specification.", IETF RFC 2205, Proposed Standard,
Sep. 1997. Sep. 1997.
[MD5] Baker, F., Linden B., Talwar, M. "RSVP Cryptographic [MD5] Baker, F., Lindell B., Talwar, M. "RSVP Cryptographic
Authentication" Internet-Draft, <draft-ietf-rsvp-md5-07.txt>, Authentication" Internet-Draft, <draft-ietf-rsvp-md5-07.txt>,
Nov. 1998. Nov. 1998.
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", RFC 2434, Writing an IANA Considerations Section in RFCs", RFC 2434,
October 1998. October 1998.
7 Acknowledgments 7 Acknowledgments
This document incorporates inputs from Lou Berger, Bob Braden, This document incorporates inputs from Lou Berger, Bob Braden,
skipping to change at page 11, line 5 skipping to change at page 11, line 5
8 Author Information 8 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 Appendix A: Policy Error Codes
This Appendix expends the list of error codes described in Appendix This Appendix extends the list of error codes described in Appendix
B of [RSVP]. B of [RSVP].
Note that Policy Element specific errors are reported as described Note that Policy Element specific errors are reported as described
in Section 3.3 and cannot be reported through RSVP (using this in Section 3.3 and cannot be reported through RSVP (using this
mechanism). However, this mechanism provides a simple, less secure mechanism). However, this mechanism provides a simple, less secure
mechanism for reporting generic policy errors. Most likely the two mechanism for reporting generic policy errors. Most likely the two
would be used in concert such that a generic error code is provided would be used in concert such that a generic error code is provided
by RSVP, while Policy Element specific errors are encapsulated in a by RSVP, while Policy Element specific errors are encapsulated in a
return POLICY_DATA object (as in Section 3.3). return POLICY_DATA object (as in Section 3.3).
 End of changes. 

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