draft-ietf-rap-cops-rsvp-04.txt   rfc2749.txt 
Internet Draft Jim Boyle Network Working Group S . Herzog, Ed.
Expiration: August 1999 Level3 Request for Comments: 2749 IPHighway
File: draft-ietf-rap-cops-rsvp-04.txt Ron Cohen Category: Standards Track J. Boyle
Cisco Level3
David Durham R. Cohen
Intel Cisco
Shai Herzog D. Durham
IPHighway Intel
Raju Rajan R. Rajan
IBM AT&T
Arun Sastry A. Sastry
Cisco Cisco
January 2000
COPS usage for RSVP COPS usage for RSVP
February 26, 1999
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document specifies an Internet standards track protocol for the
provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Task Official Protocol Standards" (STD 1) for the standardization state
Force (IETF), its areas, and its working groups. Note that other and status of this protocol. Distribution of this memo is unlimited.
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes usage directives for supporting COPS policy This document describes usage directives for supporting COPS policy
services in RSVP environments. services in RSVP environments.
Internet Draft COPS usage for RSVP 26-Feb-99
Table of Contents Table of Contents
Abstract.............................................................1 1 Introduction....................................................2
Table of Contents....................................................2 2 RSVP values for COPS objects....................................2
1 Introduction.......................................................3 2.1 Common Header, client-type...................................2
2 RSVP values for COPS objects.......................................3 2.2 Context Object (Context).....................................3
2.1 Common Header, client-type......................................3 2.3 Client Specific Information (ClientSI).......................4
2.2 Context Object (Context)........................................3 2.4 Decision Object (Decision)...................................4
2.3 Client Specific Information (ClientSI)..........................4 3 Operation of COPS for RSVP PEPs.................................6
2.4 Decision Object (Decision)......................................5 3.1 RSVP flows...................................................6
3 Operation of COPS for RSVP PEPs....................................6 3.2 Expected Associations for RSVP Requests......................6
3.1 RSVP flows......................................................6 3.3 RSVP's Capacity Admission Control: Commit and Delete.........7
3.2 Expected Associations for RSVP Requests.........................6 3.4 Policy Control Over PathTear and ResvTear....................7
3.3 RSVP's Capacity Admission Control: Commit and Delete............7 3.5 PEP Caching COPS Decisions...................................7
3.4 Policy Control Over PathTear and ResvTear.......................8 3.6 Using Multiple Context Flags in a single query...............8
3.5 PEP Caching COPS Decisions......................................8 3.7 RSVP Error Reporting.........................................9
3.6 Using Multiple Context Flags in a single query..................9 4 Security Considerations.........................................9
3.7 RSVP Error Reporting...........................................10 5 Illustrative Examples, Using COPS for RSVP......................9
4 Security Considerations...........................................10 5.1 Unicast Flow Example.........................................9
5 Illustrative Examples, Using COPS for RSVP........................11 5.2 Shared Multicast Flows......................................11
5.1 Unicast Flow Example...........................................11 6 References.....................................................14
5.2 Shared Multicast Flows.........................................13 7 Author Information and Acknowledgments.........................15
6 References........................................................16 8 Full Copyright Statement.......................................17
7 Author Information and Acknowledgments............................16
Internet Draft COPS usage for RSVP 26-Feb-99
1 Introduction 1 Introduction
The Common Open Policy Service (COPS) protocol is a query response The Common Open Policy Service (COPS) protocol is a query response
protocol used to exchange policy information between a network protocol used to exchange policy information between a network policy
policy server and a set of clients [COPS]. COPS is being developed server and a set of clients [COPS]. COPS is being developed within
within the RSVP Admission Policy Working Group (RAP WG) of the IETF, the RSVP Admission Policy Working Group (RAP WG) of the IETF,
primarily for use as a mechanism for providing policy-based primarily for use as a mechanism for providing policy-based admission
admission control over requests for network resources [RAP]. control over requests for network resources [RAP].
This document is based on and assumes prior knowledge of the RAP This document is based on and assumes prior knowledge of the RAP
framework [RAP] and the basic COPS [COPS] protocol. It provides framework [RAP] and the basic COPS [COPS] protocol. It provides
specific usage directives for using COPS in outsourcing policy specific usage directives for using COPS in outsourcing policy
control decisions by RSVP clients (PEPs) to policy servers (PDPs). control decisions by RSVP clients (PEPs) to policy servers (PDPs).
Given the COPS protocol design, RSVP directives are mainly limited Given the COPS protocol design, RSVP directives are mainly limited to
to RSVP applicability, interoperability, usage guidelines, as well RSVP applicability, interoperability and usage guidelines, as well as
as client specific examples. client specific examples.
2 RSVP values for COPS objects 2 RSVP values for COPS objects
The usage of several COPS objects is affected when used for client The usage of several COPS objects is affected when used with the RSVP
type RSVP. This section describes these objects and their usage. client type. This section describes these objects and their usage.
2.1 Common Header, client-type 2.1 Common Header, client-type
RSVP is COPS client-type 1 RSVP is COPS client-type 1
2.2 Context Object (Context) 2.2 Context Object (Context)
The semantics of the Context object for RSVP is as follows: The semantics of the Context object for RSVP is as follows:
R-Type (Request Type Flag) R-Type (Request Type Flag)
Incoming-Message request Incoming-Message request
This context is requested when the PEP receives an incoming This context is used when the PEP receives an incoming RSVP
RSVP message. The PDP may decide to accept or reject the message. The PDP may decide to accept or reject the incoming
incoming message and may also apply other decision object to message and may also apply other decision objects to it. If the
it. If the incoming message is rejected, RSVP should treat it incoming message is rejected, RSVP should treat it as if it
as if it never arrived. never arrived.
Resource-Allocation request Resource-Allocation request
This context is requested when the PEP is about to commit This context is used when the PEP is about to commit local
local resources to an RSVP flow (admission control). This resources to an RSVP flow (admission control). This context
context applies to Resv messages only. The decision whether applies to Resv messages only. The decision whether to commit
to commit local resources is performed for the merge of all local resources is made for the merge of all reservations
reservations associated with an RSVP flow, (which have associated with an RSVP flow (which have arrived on a
arrived on a particular interface, potentially from several particular interface, potentially from several RSVP Next-Hops).
RSVP Next-Hops).
Outgoing-Message request (forwarding an outgoing RSVP message) Outgoing-Message request (forwarding an outgoing RSVP message)
This context is requested when the PEP is about to forward an This context is used when the PEP is about to forward an
outgoing RSVP message. The PDP may decide to allow or deny outgoing RSVP message. The PDP may decide to allow or deny the
outgoing message, as well as provide an outgoing policy data
Internet Draft COPS usage for RSVP 26-Feb-99 object.
the outgoing message, as well as provide an outgoing policy
data object.
M-Type (Message Type) M-Type (Message Type)
The M-Type field in the Context Object identifies the applicable The M-Type field in the Context Object identifies the applicable RSVP
RSVP message type. M-Type values are derived from, and are identical message type. M-Type values are identical to the values used in the
to the values used in the "msg type" field in the RSVP header "msg type" field in the RSVP header [RSVP].
[RSVP].
The following RSVP message types are supported in COPS: The following RSVP message types are supported in COPS:
Path Path
Resv Resv
PathErr PathErr
ResvErr ResvErr
Other message types such as PathTear, ResvTear, and Resv Confirm Other message types such as PathTear, ResvTear, and Resv Confirm are
message types are not supported. The list of supported message types not supported. The list of supported message types can only be
cannot be expended other than by later versions of RSVP and/or later extended in later versions of RSVP and/or later version of this
version of this document. document.
2.3 Client Specific Information (ClientSI) 2.3 Client Specific Information (ClientSI)
All objects that were received within an RSVP message are All objects that were received in an RSVP message are encapsulated
encapsulated inside the Client Specific Information Object (Signaled inside the Client Specific Information Object (Signaled ClientSI)
ClientSI) sent from the PEP to the remote PDP. (See Section 3.1. on sent from the PEP to the remote PDP (see Section 3.1. on multiple
multiple flows packed in a single RSVP message). flows packed in a single RSVP message).
The PEP and PDP share RSVP state and the PDP is assumed to implement The PEP and PDP share RSVP state, and the PDP is assumed to implement
the same RSVP functional specification as the PEP. In the case where the same RSVP functional specification as the PEP. In the case where
a PDP detects the absence of objects required by [RSVP] it should a PDP detects the absence of objects required by [RSVP] it should
return an <Error> in the Decision message indicating "Mandatory return an <Error> in the Decision message indicating "Mandatory
client-specific info missing". If, on the other hand, the PDP client-specific info missing". If, on the other hand, the PDP detects
detects the absence of optional RSVP objects that are needed to the absence of optional RSVP objects that are needed to approve the
approve the Request against current policies, the PDP should return Request against current policies, the PDP should return a negative
a negative <Decision>. <Decision>.
Unlike the Incoming and Outgoing contexts, "Resource Allocation" Unlike the Incoming and Outgoing contexts, "Resource Allocation" is
isn't always directly associated with a specific RSVP message. In a not always directly associated with a specific RSVP message. In a
multicast session, it may represent the merging of multiple incoming multicast session, it may represent the merging of multiple incoming
reservations. Therefore, the ClientSI object should specifically reservations. Therefore, the ClientSI object should specifically
contain the SESSION and STYLE objects along with the merged contain the SESSION and STYLE objects along with the merged FLOWSPEC,
FLOWSPEC, FILTERSPEC list and SCOPE object (whenever relevant). FILTERSPEC list, and SCOPE object (whenever relevant).
Internet Draft COPS usage for RSVP 26-Feb-99
2.4 Decision Object (Decision) 2.4 Decision Object (Decision)
COPS provide the PDP with flexible controls over the PEP using COPS provides the PDP with flexible controls over the PEP using
RSVP's response to messages. While accepting an RSVP message, PDPs RSVP's response to messages. While accepting an RSVP message, PDPs
may provide preemption priority, trigger warnings, replace RSVP may provide preemption priority, trigger warnings, replace RSVP
objects, and much more, using Decision Commands, Flags and Objects. objects, and much more, using Decision Commands, Flags, and Objects.
DECISION COMMANDS DECISION COMMANDS
Only two commands apply to RSVP Only two commands apply to RSVP
Install Install
Positive Response: Positive Response:
Accept/Allow/Admit an RSVP message or local resource allocation. Accept/Allow/Admit an RSVP message or local resource allocation.
skipping to change at page 5, line 35 skipping to change at page 5, line 12
Negative Response: Negative Response:
Deny/Reject/Remove an RSVP message or local resource allocation. Deny/Reject/Remove an RSVP message or local resource allocation.
DECISION FLAGS DECISION FLAGS
The only decision flag that applies to RSVP: The only decision flag that applies to RSVP:
Trigger Error Trigger Error
If this flag is set, RSVP should schedule a PathErr, in response If this flag is set, RSVP should schedule a PathErr, in response
of a Path message, or a ResvErr (in response of a Resv message). to a Path message, or a ResvErr (in response of a Resv message).
STATELESS POLICY DATA STATELESS POLICY DATA
This object may include one or more policy elements (as specified This object may include one or more policy elements (as specified for
for the RSVP Policy Data object [RSVP-EXT]) which are assumed to be the RSVP Policy Data object [RSVP-EXT]) which are assumed to be well
well understood by the client's LDP. The PEP should consider these understood by the client's LPDP. The PEP should consider these as an
as an addition to the decision already received from the PDP (it can addition to the decision already received from the PDP (it can only
only add, but cannot override it). add, but cannot override it).
For example: Given Policy Elements that specify a flow's preemption For example, given Policy Elements that specify a flow's preemption
priority, these elements may be included in an incoming Resv message priority, these elements may be included in an incoming Resv message
or may be also be provided by the PDP responding to a query. or may be provided by the PDP responding to a query.
Stateless objects must be well understood, but not necessarily Stateless objects must be well understood, but not necessarily
supported by all PEPs. For example, assuming a standard policy supported by all PEPs. For example, assuming a standard policy
element for preemption priority, it is perfectly legitimate for some element for preemption priority, it is perfectly legitimate for some
PEPs not to support such preemption and to ignore it. The PDP must PEPs not to support such preemption and to ignore it. The PDP must be
be careful when using such objects, especially, it must be prepared careful when using such objects. In particular, it must be prepared
for these objects would be ignored by PEPs. for these objects to be ignored by PEPs.
Stateless Policy Data may be returned in decisions and apply Stateless Policy Data may be returned in decisions and apply
individually to each of the contexts flagged in REQ messages. When individually to each of the contexts flagged in REQ messages. When
applied to Incoming, it is assumed to have been received as a applied to Incoming, it is assumed to have been received as a
POLICY_DATA object in the incoming message. When applied to Resource POLICY_DATA object in the incoming message. When applied to Resource
Allocation it is assumed to have been received on all merged incoming
Internet Draft COPS usage for RSVP 26-Feb-99 messages. Last, when applied to outgoing messages it is assumed to
have been received in all messages contributing to the outgoing
Allocation it is assumed to have been received on all merged message.
incoming messages. Last, when applied to outgoing message it is
assumed to have been received in all messages contributing to the
outgoing message.
REPLACEMENT DATA REPLACEMENT DATA
The Replacement object may contain multiple RSVP objects to be The Replacement object may contain multiple RSVP objects to be
replaced (from the original RSVP request). Typical replacement is replaced (from the original RSVP request). Typical replacement is
performed on the "Forward Outgoing" request (for instance, replacing performed on the "Forward Outgoing" request (for instance, replacing
outgoing Policy Data), but is not limited, and can also be performed outgoing Policy Data), but is not limited, and can also be performed
on other contexts (such as "Resources-Allocation Request"). In other on other contexts (such as "Resources-Allocation Request"). In other
cases, replacement of the RSVP FlowSpec object may be useful for cases, replacement of the RSVP FlowSpec object may be useful for
controlling resources across a trusted zone (with policy ignorant controlling resources across a trusted zone (with policy ignorant
nodes (PINs). Currently, RSVP clients are only required to allow nodes (PINs). Currently, RSVP clients are only required to allow
replacement of three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC, replacement of three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC,
but could optionally support replacement of more objects. but could optionally support replacement of other objects.
RSVP object replacement is performed in the following manner: RSVP object replacement is performed in the following manner:
If Replacement Data decision doesn't appear in a decision message, If no Replacement Data decision appears in a decision message, all
all signaled objects are processed as if the PDP was not there. When signaled objects are processed as if the PDP was not there. When an
an object of a certain C-Num appears it replaces ALL the instances object of a certain C-Num appears, it replaces ALL the instances of
of C-Num objects in the RSVP message. If it appears empty (with a C-Num objects in the RSVP message. If it appears empty (with a length
length of 4) it simply removes all instances of C-Num objects of 4) it simply removes all instances of C-Num objects without adding
without adding a thing. anything.
3 Operation of COPS for RSVP PEPs 3 Operation of COPS for RSVP PEPs
3.1 RSVP flows 3.1 RSVP flows
Policy Control is performed per RSVP flow, which is defined by the Policy Control is performed per RSVP flow, which is defined by the
atomic unit of RSVP reservation (TC reservation). Reservation styles atomic unit of an RSVP reservation (TC reservation). Reservation
may also impact the definition of flows; a set of senders which are styles may also impact the definition of flows; a set of senders
considered as a single flow for WF reservation are considered as a which are considered as a single flow for WF reservation are
set of individual flows when FF style is used. considered as a set of individual flows when FF style is used.
Multiple FF flows may be packed into a single Resv message. A packed Multiple FF flows may be packed into a single Resv message. A packed
message must be unpack where a separate request is issued for each message must be unpacked where a separate request is issued for each
of the packed flows as if they were individual RSVP messages. Each of the packed flows as if they were individual RSVP messages. Each
COPS Request should include the associated POLICY_DATA objects, COPS Request should include the associated POLICY_DATA objects, which
which are, by default, all POLICY_DATA objects in the packed are, by default, all POLICY_DATA objects in the packed message.
message. Sophisticated PEPs, capable of looking inside policy Sophisticated PEPs, capable of looking inside policy objects, may
objects, may examine the POLICY_DATA or SCOPE object to narrow down examine the POLICY_DATA or SCOPE object to narrow down the list of
the list of associated flows (as optimization). associated flows (as an optimization).
Please note that the rules governing Packed RSVP message apply Please note that the rules governing Packed RSVP message apply
equally to Incoming as well as Outgoing REQ context. equally to the Incoming as well as the Outgoing REQ context.
3.2 Expected Associations for RSVP Requests 3.2 Expected Associations for RSVP Requests
When making a policy decision, the PDP may consider both Resv as When making a policy decision, the PDP may consider both Resv as well
well as its matching Path state (associated state). State as its matching Path state (associated state). State association is
association is straightforward in the common unicast case since the straightforward in the common unicast case since the RSVP flow
RSVP flow includes one Path state and one Resv state. In multicast includes one Path state and one Resv state. In multicast cases this
correspondence may be more complicated, as the match may be many-to-
Internet Draft COPS usage for RSVP 26-Feb-99 many. The COPS protocol assumes that the PDP is RSVP knowledgeable
and capable of determining these associations based on the contents
cases this correspondence may be more complicated, as the match may of the Client REQ message and especially the ClientSI object.
be many to many. The COPS protocol assumes that the PDP is RSVP
knowledgeable and capable of determining these associations based on
the contents of the Client REQ message and especially the ClientSI
object.
For example, the PDP should be able to recognize activation and For example, the PDP should be able to recognize activation and
deactivation of RSVP blockade state following discrete events like deactivation of RSVP blockade state following discrete events like
the arrival of a ResvErr message (activate the blockade state) as the arrival of a ResvErr message (activate the blockade state) as
well as the change in the outgoing Resv message. well as the change in the outgoing Resv message.
3.3 RSVP's Capacity Admission Control: Commit and Delete 3.3 RSVP's Capacity Admission Control: Commit and Delete
In RSVP, the admission of a new reservation requires both an In RSVP, the admission of a new reservation requires both an
administrative approval (policy control) and capacity admission administrative approval (policy control) and capacity admission
control. After being approved by both, and after the reservation was control. After being approved by both, and after the reservation was
successfully installed, the PEP notifies the remote PDP by sending a successfully installed, the PEP notifies the remote PDP by sending a
report message specifying the Commit type. The Commit type report report message specifying the Commit type. The Commit type report
message signals when billing should effectively begin and performing message signals when billing should effectively begin and performing
heavier delayed operations (e.g., debiting a credit card) is heavier delayed operations (e.g., debiting a credit card) is
permissible by the PDP. permissible by the PDP.
If instead a PDP approved reservation fails admission due to lack of If, instead, a PDP approved reservation fails admission due to lack
resources, the PEP must issue a no-commit report and fold back and of resources, the PEP must issue a no-commit report and fold back and
send an updated request to its previous state (previously installed send an updated request to its previous state (previously installed
reservation). If no state was previously installed, the PEP should reservation). If no state was previously installed, the PEP should
issue a delete (DRQ). issue a delete (DRQ).
Internet Draft COPS usage for RSVP 26-Feb-99
3.4 Policy Control Over PathTear and ResvTear 3.4 Policy Control Over PathTear and ResvTear
PathTear and ResvTear messages are not controlled by this policy PathTear and ResvTear messages are not controlled by this policy
architecture. This relies on two assumptions: First, that MD-5 architecture. This relies on two assumptions: First, that MD-5
authentication verifies that the Tear is received from the same node authentication verifies that the Tear is received from the same node
that sent the initial reservation, and second, that it is that sent the initial reservation, and second, that it is
functionally equivalent to that node holding-off refreshes for this functionally equivalent to that node holding off refreshes for this
reservation. When a ResvTear or PathTear is received at the PEP, all reservation. When a ResvTear or PathTear is received at the PEP, all
affected states installed on the PDP should either be deleted or affected states installed on the PDP should either be deleted or
updated by the PEP. updated by the PEP.
3.5 PEP Caching COPS Decisions 3.5 PEP Caching COPS Decisions
Because COPS is a stateful protocol, refreshes for RSVP Path and Because COPS is a stateful protocol, refreshes for RSVP Path and Resv
Resv messages need not be constantly sent to the remote PDP. Once a messages need not be constantly sent to the remote PDP. Once a
decision has been returned for a request, the PEP can cache that decision has been returned for a request, the PEP can cache that
decision and apply it to future refreshes. When the PEP detects a decision and apply it to future refreshes. When the PEP detects a
change in the corresponding Resv or Path message, it should update change in the corresponding Resv or Path message, it should update
the PDP with the new request-state. PEPs may continue to use the the PDP with the new request-state. PEPs may continue to use the
cached state until receiving the PDP response. This case is very cached state until receiving the PDP response. This case is very
different from initial admission of a flow; given that valid different from initial admission of a flow; given that valid
credentials and authentication have already been established, the credentials and authentication have already been established, the
relative long RSVP refresh period, and the short PEP-PDP response relatively long RSVP refresh period, and the short PEP-PDP response
time, the tradeoff between expedient updates and attack prevention time, the tradeoff between expedient updates and attack prevention
leans toward expediency. However, this is really a PEP choice, and leans toward expediency. However, this is really a PEP choice, and is
is irrelevant to PDPs. irrelevant to PDPs.
If the connection is lost between the PEP and the PDP, the cached If the connection is lost between the PEP and the PDP, the cached
RSVP state may be retained for the RSVP timeout period to be used RSVP state may be retained for the RSVP timeout period to be used for
for previously admitted flows (but cannot be applied to new or previously admitted flows (but cannot be applied to new or updated
updated state). If connection can not be reestablished with the PDP state). If the connection can not be reestablished with the PDP or a
or a backup PDP after the timeout period, the PEP is expected to backup PDP after the timeout period, the PEP is expected to purge all
purge all its cached decisions. Without applicable cached decision, its cached decisions. Without applicable cached decision, the PEP
the PEP must either reject the flow or resort to its LDP (if must either reject the flow or resort to its LPDP (if available) for
available) for decisions. decisions.
Once a connection is reestablished to a new (or the original) PDP Once a connection is reestablished to a new (or the original) PDP the
the PDP may issue a SSQ request. In this case, the PEP must reissue PDP may issue a SSQ request. In this case, the PEP must reissue
requests that correspond to the current RSVP state (as if all the requests that correspond to the current RSVP state (as if all the
state has been updated recently). It should also include as LDP the state has been updated recently). It should also include in its
current (cached) decision regarding each such state. LPDPDecision the current (cached) decision regarding each such state.
Internet Draft COPS usage for RSVP 26-Feb-99
3.6 Using Multiple Context Flags in a single query 3.6 Using Multiple Context Flags in a single query
RSVP is a store-and-forward control protocol where messages are RSVP is a store-and-forward control protocol where messages are
processed in three distinctive steps (input, resource allocation, processed in three distinctive steps (input, resource allocation, and
and output). Each step requires a separate policy decision as output). Each step requires a separate policy decision as indicated
indicated by context flags (see Section 2.2). In many cases, setting by context flags (see Section 2.2). In many cases, setting multiple
multiple context flags for bundling two or three operations together context flags for bundling two or three operations together in one
in one request may significantly optimize protocol operations. request may significantly optimize protocol operations.
The following rules apply for setting multiple Context flags: The following rules apply for setting multiple Context flags:
a. Multiple context flags can be set only in two generic cases which a. Multiple context flags can be set only in two generic cases, which
are guaranteed not to cause ambiguity and represent substantial represent a substantial portion of expected COPS transactions, and
portion of expected COPS transactions. can be guaranteed not to cause ambiguity.
Unicast FF: Unicast FF:
[Incoming + Allocation + Outgoing] [Incoming + Allocation + Outgoing]
Multicast with only one Resv message received on the interface Multicast with only one Resv message received on the interface
[Incoming + Allocation] [Incoming + Allocation]
b. Context events are ordered by time since every message processing b. Context events are ordered by time since every message must first
must first be processed as Incoming, then as Resource allocation be processed as Incoming, then as Resource allocation and only
and only then as Outgoing. When multiple context flags are set, then as Outgoing. When multiple context flags are set, all
all ClientSI objects included in the request are assumed to be ClientSI objects included in the request are assumed to be
processed to the latest flag. This rule applies both to request processed according to the latest flag. This rule applies both to
(REQ) context as well as to decision (DEC) context. the request (REQ) context as well as to the decision (DEC)
context.
For example: when combining Incoming + Allocation for an incoming For example, when combining Incoming + Allocation for an incoming
Resv message, the flowspec included in the ClientSI would be the Resv message, the flowspec included in the ClientSI would be the
one corresponding to the Resource-Allocation context (TC). one corresponding to the Resource-Allocation context (TC).
c. Each decision is bound to a context object, which determines c. Each decision is bound to a context object, which determines which
which portion of the request context it applies to. When portion of the request context it applies to. When individual
different decisions apply to different sub-groups of context the decisions apply to different sub-groups of the context, the PDP
PDP should send each group of decision objects encapsulated or should send each group of decision objects encapsulated by the
separated by the context flags object with the context flags context flags object with the context flags applicable to these
applicable to these objects set. (See the examples in Section 5). objects set (see the examples in Section 5).
Internet Draft COPS usage for RSVP 26-Feb-99
3.7 RSVP Error Reporting 3.7 RSVP Error Reporting
RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to
report policy errors. While the contents of the ERROR_SPEC object is report policy errors. While the contents of the ERROR_SPEC object are
defined in [RSVP,RSVP-EXT], the PDP is in the best position to defined in [RSVP,RSVP-EXT], the PDP is in the best position to
provide its contents (sub-codes). This is performed in the following provide its contents (sub-codes). This is performed in the following
manner: First, the PEP (RSVP) queries the PDP before sending a manner: First, the PEP (RSVP) queries the PDP before sending a
PathErr or ResvErr, and then the PDP returns the constructed PathErr or ResvErr, and then the PDP returns the constructed
ERROR_SPEC in the Replacement Data Decision Object. ERROR_SPEC in the Replacement Data Decision Object.
4 Security Considerations 4 Security Considerations
This document relies on COPS for its signaling and its security. This document relies on COPS for its signaling and its security.
Please refer to section "Security Considerations" in [COPS]. Please refer to section "Security Considerations" in [COPS].
Security for RSVP messages is provided by inter-router MD5
authentication [MD5], assuming a chain-of-trust model.
A likely deployment scenario calls for PEPs to be deployed only at
the network edge (boundary nodes) while the core of the network
(backbone) constitutes of PIN nodes. In this scenario MD5 trust
(authentication) is established between boundary (non-neighboring)
PEPs. Such trust can be achieved through internal signing
(integrity) of the Policy Data object itself, which is left
unmodified as it passes through PIN nodes (see [RSVP-EXT]).
Internet Draft COPS usage for RSVP 26-Feb-99 Security for RSVP messages is provided by inter-router MD5
authentication [MD5], assuming a chain-of-trust model. A likely
deployment scenario calls for PEPs to be deployed only at the network
edge (boundary nodes) while the core of the network (backbone)
consists of PIN nodes. In this scenario MD5 trust (authentication) is
established between boundary (non-neighboring) PEPs. Such trust can
be achieved through internal signing (integrity) of the Policy Data
object itself, which is left unmodified as it passes through PIN
nodes (see [RSVP-EXT]).
5 Illustrative Examples, Using COPS for RSVP 5 Illustrative Examples, Using COPS for RSVP
This section details both typical unicast and multicast scenarios. This section details both typical unicast and multicast scenarios.
5.1 Unicast Flow Example 5.1 Unicast Flow Example
This section details the steps in using COPS for controlling a This section details the steps in using COPS for controlling a
Unicast RSVP flow. It details the contents of the COPS messages Unicast RSVP flow. It details the contents of the COPS messages with
with respect to the following figure. respect to Figure 1.
PEP (router) PEP (router)
+-----------------+ +-----------------+
| | | |
R1 ------------+if1 if2+------------ S1 R1 ------------+if1 if2+------------ S1
| | | |
+-----------------+ +-----------------+
Figure 1: Unicast Example: a single PEP view Figure 1: Unicast Example: a single PEP view
The PEP router has two interfaces (if1, if2). Sender S1 sends to The PEP router has two interfaces (if1, if2). Sender S1 sends to
receiver R1. receiver R1.
A Path message arrives from S1: A Path message arrives from S1:
PEP --> PDP REQ := <Handle A> <Context: in & out, Path> PEP --> PDP REQ := <Handle A> <Context: in & out, Path>
<In-Interface if2> <Out-Interface if1> <In-Interface if2> <Out-Interface if1>
<ClientSI: all objects in Path message> <ClientSI: all objects in Path message>
skipping to change at page 12, line 5 skipping to change at page 11, line 7
<Decision: replacement, POLICY-DATA1> <Decision: replacement, POLICY-DATA1>
PEP --> PDP RPT := <Handle B> PEP --> PDP RPT := <Handle B>
<Report type: commit> <Report type: commit>
Notice that the Decision was split because of the need to specify Notice that the Decision was split because of the need to specify
different decision objects for different context flags. different decision objects for different context flags.
Time Passes, the PDP changes its decision: Time Passes, the PDP changes its decision:
Internet Draft COPS usage for RSVP 26-Feb-99
PDP --> PEP DEC := <Handle B> PDP --> PEP DEC := <Handle B>
<Context: allocation, Resv> <Context: allocation, Resv>
<Decision: command, Install> <Decision: command, Install>
<Decision: Stateless, Priority=3> <Decision: Stateless, Priority=3>
Because the priority is too low, the PEP preempts the flow: Because the priority is too low, the PEP preempts the flow:
PEP --> PDP DRQ := <Handle B> PEP --> PDP DRQ := <Handle B>
<Reason Code: Preempted> <Reason Code: Preempted>
Time Passes, the sender S1 ceases to send Path messages: Time Passes, the sender S1 ceases to send Path messages:
PEP --> PDP DRQ := <Handle A> PEP --> PDP DRQ := <Handle A>
<Reason: Timeout> <Reason: Timeout>
Internet Draft COPS usage for RSVP 26-Feb-99
5.2 Shared Multicast Flows 5.2 Shared Multicast Flows
This section details the steps in using COPS for controlling a This section details the steps in using COPS for controlling a
multicast RSVP flow. It details the contents of the COPS messages multicast RSVP flow. It details the contents of the COPS messages
with respect to the following figure. with respect to Figure 2.
PEP (router) PEP (router)
+-----------------+ +-----------------+
| | | |
R1-------------+ if1 if3 +--------- S1 R1-------------+ if1 if3 +--------- S1
| | | |
R2----+ | | R2----+ | |
| | | | | |
+--------+ if2 if4 +--------- S2 +--------+ if2 if4 +--------- S2
| | | | | |
R3----+ +-----------------+ R3----+ +-----------------+
Figure 2: Multicast example: a single PEP view Figure 2: Multicast example: a single PEP view
Figure 2 shows an RSVP PEP (router) which has two senders (S1, S2) Figure 2 shows an RSVP PEP (router) which has two senders (S1, S2)
and three receivers (R1, R2, R3) for the same multicast session. and three receivers (R1, R2, R3) for the same multicast session.
Interface if2 is connected to a shared media. Interface if2 is connected to a shared media. In this example, we
In this example, we assume that the multicast membership is already assume that the multicast membership is already in place. No previous
in place. No previous RSVP messages were received, and the first to RSVP messages were received, and the first to arrive is a Path
arrive is a Path message on interface if3 from sender S1: message on interface if3 from sender S1:
PEP --> PDP REQ := <Handle A> <Context: in, Path> PEP --> PDP REQ := <Handle A> <Context: in, Path>
<In-interface if3> <In-interface if3>
<ClientSI: all objects in incoming Path> <ClientSI: all objects in incoming Path>
PDP --> PEP DEC := <Handle A> <Context: in, Path> PDP --> PEP DEC := <Handle A> <Context: in, Path>
<Decision: command, Install> <Decision: command, Install>
The PEP consults its forwarding table, and finds two outgoing The PEP consults its forwarding table, and finds two outgoing
interface for the path (if1, if2). The exchange below is for interface for the path (if1, if2). The exchange below is for
skipping to change at page 14, line 5 skipping to change at page 12, line 22
PEP --> PDP REQ := <Handle B1> <Context: out, Path> PEP --> PDP REQ := <Handle B1> <Context: out, Path>
<Out-interface if1> <Out-interface if1>
<clientSI: all objects in outgoing Path> <clientSI: all objects in outgoing Path>
PDP --> PEP DEC := <Handle B1> PDP --> PEP DEC := <Handle B1>
<Context: out, Path> <Context: out, Path>
<Decision: command, Install> <Decision: command, Install>
<Decision: Replacement, POLICY-DATA1> <Decision: Replacement, POLICY-DATA1>
Internet Draft COPS usage for RSVP 26-Feb-99 Here, the PDP decided to allow the forwarding of the Path message and
provided the appropriate policy-data object for interface if1.
Here, the PDP decided to allow the forwarding of the Path message
and provided the appropriate policy-data object for interface if1.
Next, a WF Resv message from receiver R2 arrives on interface if2. Next, a WF Resv message from receiver R2 arrives on interface if2.
PEP --> PDP REQ := <Handle C> <Context: in & allocation, Resv> PEP --> PDP REQ := <Handle C> <Context: in & allocation, Resv>
<In-interface if2> <In-interface if2>
<ClientSI: all objects in Resv message <ClientSI: all objects in Resv message
including RSpec1 > including RSpec1 >
PDP --> PEP DEC := <Handle C> PDP --> PEP DEC := <Handle C>
<Context: in, Resv> <Context: in, Resv>
skipping to change at page 14, line 43 skipping to change at page 13, line 13
<Client info: all objects in outgoing Resv> <Client info: all objects in outgoing Resv>
PDP --> PEP DEC := <Handle E> PDP --> PEP DEC := <Handle E>
<Context: out, Resv> <Context: out, Resv>
<Decision: command, Install> <Decision: command, Install>
<Decision: replacement, POLICY-DATA2> <Decision: replacement, POLICY-DATA2>
Note: The Context object is part of this DEC message even though it Note: The Context object is part of this DEC message even though it
may look redundant since the REQ specified only one context flag. may look redundant since the REQ specified only one context flag.
Next, a new WF Resv message from receiver R3 arrives on interface Next, a new WF Resv message from receiver R3 arrives on interface if2
if2 with a higher RSpec (Rspec2). Given two reservations arrived on with a higher RSpec (Rspec2). Given two reservations arrived on if2,
if2, it cannot perform a request with multiple context flags, and it cannot perform a request with multiple context flags, and must
must issue them separately. issue them separately.
Internet Draft COPS usage for RSVP 26-Feb-99
The PEP re-issues an updated handle C REQ with a new context object The PEP re-issues an updated handle C REQ with a new context object
<Context: in , Resv>, and receives a DEC for handle C. <Context: in , Resv>, and receives a DEC for handle C.
PEP --> PDP REQ := <Handle F> <Context: in , Resv> PEP --> PDP REQ := <Handle F> <Context: in , Resv>
<In-interface if2> <In-interface if2>
<ClientSI: all objects in Resv message <ClientSI: all objects in Resv message
including RSpec2 > including RSpec2 >
PDP --> PEP DEC := <Handle F> <Context: in , Resv> PDP --> PEP DEC := <Handle F> <Context: in , Resv>
skipping to change at page 15, line 30 skipping to change at page 13, line 41
<ClientSI: all objects in merged Resv <ClientSI: all objects in merged Resv
including RSpec2 > including RSpec2 >
PDP --> PEP DEC := <Handle G> PDP --> PEP DEC := <Handle G>
<Context: allocation, Resv> <Context: allocation, Resv>
<Decision: command, Install> <Decision: command, Install>
<Decision: Stateless, Priority=5> <Decision: Stateless, Priority=5>
PEP --> PDP RPT := <handle G> <Commit> PEP --> PDP RPT := <handle G> <Commit>
Given the change in incoming reservations, the PEP needs to forward Given the change in incoming reservations, the PEP needs to forward a
a new outgoing Resv message upstream toward S1. This repeats exactly new outgoing Resv message upstream toward S1. This repeats exactly
the previous interaction of Handle E, except that the ClientSI the previous interaction of Handle E, except that the ClientSI
objects now reflect the merging of two reservations. objects now reflect the merging of two reservations.
If an ResvErr arrives from S1, the PEP maps it to R3 only (because If an ResvErr arrives from S1, the PEP maps it to R3 only (because it
it has a higher flowspec: Rspec2) the following takes place: has a higher flowspec: Rspec2) the following takes place:
PEP --> PDP REQ := <Handle H> <Context: in, ResvErr> PEP --> PDP REQ := <Handle H> <Context: in, ResvErr>
<In-interface if3> <In-interface if3>
<ClientSI: all objects in incoming ResvErr> <ClientSI: all objects in incoming ResvErr>
PDP --> PEP DEC := <Handle H> <Context: in, ResvErr> PDP --> PEP DEC := <Handle H> <Context: in, ResvErr>
<Decision: command, Install> <Decision: command, Install>
PEP --> PDP REQ := <Handle I> <Context: out, ResvErr> PEP --> PDP REQ := <Handle I> <Context: out, ResvErr>
<Out-interface if2> <Out-interface if2>
skipping to change at page 16, line 5 skipping to change at page 14, line 21
PDP --> PEP DEC := <Handle I> PDP --> PEP DEC := <Handle I>
<Context: out, ResvErr> <Context: out, ResvErr>
<Decision: command, Install> <Decision: command, Install>
<Decision: Replacement, POLICY-DATA3> <Decision: Replacement, POLICY-DATA3>
When S2 joins the session by sending a Path message, incoming and When S2 joins the session by sending a Path message, incoming and
outgoing Path requests are issued for the new Path. A new outgoing outgoing Path requests are issued for the new Path. A new outgoing
Resv request would be sent to S2. Resv request would be sent to S2.
Internet Draft COPS usage for RSVP 26-Feb-99
6 References 6 References
[RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", [RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC
Internet-Draft, draft-ietf-rap-rsvp-ext-02.txt, Jan. 1999. 2750, January 2000.
[RAP] Yavatkar, R., et al., "A Framework for Policy Based [RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
Admission Control", IETF <draft-ietf-rap-framework-02.txt>, for Policy Based Admission Control", RFC 2753, January
Jan., 1999. 2000.
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and
Sastry, A., "The COPS (Common Open Policy Service) Protocol", A. Sastry, "The COPS (Common Open Policy Service)
IETF <draft-ietf-rap-cops-05.txt>, Jan. 1999. Protocol", RFC 2748, January 2000.
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Functional Specification.", IETF RFC 2205, Proposed Standard, Jamin, "Resource ReSerVation Protocol (RSVP) - Functional
Sep. 1997. Specification", RFC 2205, September 1997.
7 Author Information and Acknowledgments 7 Author Information and Acknowledgments
Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs,
Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan, Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan,
and Raj Yavatkar, for their valuable contributions. and Raj Yavatkar, for their valuable contributions.
Jim Boyle Ron Cohen Jim Boyle
Level 3 Communications CISCO Systems Level 3 Communications
1450 Infinite Drive13 Hasadna St. 1025 Eldorado Boulevard
Louisville, CO 80027 Ra'anana 43650 Israel Broomfield, CO 80021
303.926.3100 972.9.7462020
email: jboyle@l3.net ronc@cisco.com
David Durham Raju Rajan Phone: 720.888.1192
Intel IBM T.J. Watson Research Cntr EMail: jboyle@Level3.net
2111 NE 25th Avenue P.O. Box 704
Hillsboro, OR 97124 Yorktown Heights, NY 10598
503.264.6232 914.784.7260
David_Durham@mail.intel.com raju@watson.ibm.com
Shai Herzog Arun Sastry Ron Cohen
IPHighway Cisco Systems CISCO Systems
400 Kelby St., Suite 1500 506210 W Tasman Drive 4 Maskit St.
Fort-Lee, NJ 07024 San Jose, CA 95134 Herzeliya Pituach 46766 Israel
201.585.0800 408.526.7685
herzog@iphighway.com asastry@cisco.com Phone: 972.9.9700064
EMail: ronc@cisco.com
David Durham
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: 503.264.6232
EMail: David.Durham@intel.com
Raju Rajan
AT&T Labs Research
180 Park Ave., P.O. Box 971
Florham Park, NJ 07932
Phone: 973.360.7229
EMail: raju@research.att.com
Shai Herzog
IPHighway, Inc.
55 New York Avenue
Framingham, MA 01701
Phone: 508.620.1141
EMail: herzog@iphighway.com
Arun Sastry
Cisco Systems
4 The Square
Stockley Park
Uxbridge, Middlesex UB11 1BN
UK
Phone: +44-208-756-8693
EMail: asastry@cisco.com
8 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 74 change blocks. 
287 lines changed or deleted 237 lines changed or added

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