draft-ietf-rap-cops-rsvp-02.txt   draft-ietf-rap-cops-rsvp-03.txt 
Internet Draft Jim Boyle Internet Draft Jim Boyle
Expiration: July 1999 Level3 Expiration: August 1999 Level3
File: draft-ietf-rap-cops-rsvp-02.txt Ron Cohen File: draft-ietf-rap-cops-rsvp-03.txt Ron Cohen
Cisco Cisco
David Durham David Durham
Intel Intel
Shai Herzog Shai Herzog
IPHighway IPHighway
Raju Rajan Raju Rajan
IBM IBM
Arun Sastry Arun Sastry
Cisco Cisco
COPS usage for RSVP COPS usage for RSVP
Last Updated: January 22, 1999 February 13, 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 and is in full conformance with all
documents of the Internet Engineering Task Force (IETF), its Areas, provisions of Section 10 of RFC2026.
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet-Drafts are working documents of the Internet Engineering Task
months. Internet Drafts may be updated, replaced, or obsoleted by Force (IETF), its areas, and its working groups. Note that other
other documents at any time. It is not appropriate to use Internet groups may also distribute working documents as Internet-Drafts.
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the Internet-Drafts are draft documents valid for a maximum of six months
1id-abstracts.txt listing contained in the Internet-Drafts Shadow and may be updated, replaced, or obsoleted by other documents at any
Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or time. It is inappropriate to use Internet-Drafts as reference material
munnari.oz.au. or to cite them other than as "work in progress."
A revised version of this draft document will be submitted to the The list of current Internet-Drafts can be accessed at
RFC editor as a Proposed Standard for the Internet Community. http://www.ietf.org/ietf/1id-abstracts.txt
Discussion and suggestions for improvement are requested. This
document will expire at the expiration date listed above. The list of Internet-Draft Shadow Directories can be accessed at
Distribution of this draft is unlimited. 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.
Table of Contents Table of Contents
Abstract.............................................................2 Abstract.............................................................1
Table of Contents....................................................2 Table of Contents....................................................2
1.Introduction.......................................................3 1 Introduction.......................................................3
2.RSVP values for COPS objects.......................................3 2 RSVP values for COPS objects.......................................3
2.1.Context Object (Context).........................................3 2.1 Common Header, client-type......................................3
2.2.Client Specific Information (ClientSI)...........................4 2.2 Context Object (Context)........................................3
2.3.Decision Object (Decision).......................................5 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..........................7 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........................8 3.3 RSVP's Capacity Admission Control: Commit and Delete............7
3.5.PEP Caching COPS Decisions.......................................8 3.4 Policy Control Over PathTear and ResvTear.......................8
3.6.Using Multiple Context Flags in a single query...................9 3.5 PEP Caching COPS Decisions......................................8
3.7.Trusted zones and secure policy tunneling.......................10 3.6 Using Multiple Context Flags in a single query..................9
4.Illustrative Examples, Using COPS for RSVP........................10 3.7 RSVP Error Reporting...........................................10
4.1.Unicast Flow Example............................................10 3.8 Security Considerations........................................10
4.2.Shared Multicast Flows..........................................12 4 Illustrative Examples, Using COPS for RSVP........................10
5.References........................................................16 4.1 Unicast Flow Example...........................................10
6.Author Information and Acknowledgments............................16 4.2 Shared Multicast Flows.........................................12
5 References........................................................16
6 Author Information and Acknowledgments............................16
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 server and a set of clients [COPS]. COPS is being developed policy server and a set of clients [COPS]. COPS is being developed
within the RSVP Admission Policy Working Group (RAP WG) of the IETF, within 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 control over requests for network resources [RAP]. admission 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 RSVP applicability, interoperability, usage guidelines, as well to RSVP applicability, interoperability, usage guidelines, as well
as client specific examples. as client specific examples.
2. RSVP values for COPS objects 2 RSVP values for COPS objects
The format and usage of several COPS objects is affected when used The usage of several COPS objects is affected when used for client
for client type RSVP. This section describes these objects and the type RSVP. This section describes these objects and their usage.
usage.
2.1. Context Object (Context) 2.1 Common Header, client-type
RSVP is COPS client-type 1
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 requested when the PEP receives an incoming
RSVP message. The PDP may decide to accept or reject the RSVP message. The PDP may decide to accept or reject the
incoming message and may also apply other decision object to incoming message and may also apply other decision object to
it. If the incoming message is rejected, RSVP should treat it it. If the incoming message is rejected, RSVP should treat it
as if it never arrived. as if it never arrived.
Resource-Allocation request Resource-Allocation request
This context is requested when the PEP is about to commit This context is requested when the PEP is about to commit
local resources to an RSVP flow (admission control). This local resources to an RSVP flow (admission control). This
context applies to Resv messages only. The decision whether context applies to Resv messages only. The decision whether
to commit local resources is performed for the merge of all to commit local resources is performed for the merge of all
reservations associated with an RSVP flow (which have arrived reservations associated with an RSVP flow, (which have
on a particular interface, potentially from several RSVP arrived on a particular interface, potentially from several
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 requested 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 the outgoing message, as well as provide an outgoing policy
data object. data object.
M-Type (Message Type) M-Type (Message Type)
skipping to change at page 4, line 26 skipping to change at page 4, line 21
In COPS: In COPS:
1 = Path 1 = Path
2 = Resv 2 = Resv
3 = PathErr 3 = PathErr
4 = ResvErr 4 = ResvErr
Note: The PathTear, ResvTear, and the Resv Confirm message types are Note: The PathTear, ResvTear, and the Resv Confirm message types are
not supported. not supported.
2.2. 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 within an RSVP message are
encapsulated inside the Client Specific Information Object (Signaled encapsulated inside the Client Specific Information Object (Signaled
ClientSI) sent from the PEP to the remote PDP. (See Section 3.1. on ClientSI) sent from the PEP to the remote PDP. (See Section 3.1. on
multiple flows packed in a single RSVP message). multiple 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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
approve the Request against current policies, the PDP should return approve the Request against current policies, the PDP should return
a negative <Decision>. a negative <Decision>.
Unlike the Incoming and Outgoing contexts, “Resource Allocation” Unlike the Incoming and Outgoing contexts, “Resource Allocation”
isn’t always directly associated with a specific RSVP message. In a isn’t 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, FILTERSPEC list and SCOPE object (whenever relevant). FLOWSPEC, FILTERSPEC list and SCOPE object (whenever relevant).
2.3. Decision Object (Decision) 2.4 Decision Object (Decision)
COPS provide the PDP with flexible controls over the PEP using COPS provide 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
skipping to change at page 6, line 28 skipping to change at page 6, line 19
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 PIN nodes). controlling resources across a trusted zone (with PIN nodes).
Currently, RSVP clients are only required to allow replacement of Currently, RSVP clients are only required to allow replacement of
two objects: Policy Data and FlowSpec, but could optionally support three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC, but could
replacement of more objects. optionally support replacement of more 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 Replacement Data decision doesn't appear in a decision message,
all signaled objects are processed as if the PDP was not there. When all signaled objects are processed as if the PDP was not there. When
an object of a certain C-Num appears it replaces ALL the instances an object of a certain C-Num appears it replaces ALL the instances
of C-Num objects in the RSVP message. If it appears empty (with a of C-Num objects in the RSVP message. If it appears empty (with a
length of 4) it simply removes all instances of C-Num objects length of 4) it simply removes all instances of C-Num objects
without adding a thing. without adding a thing.
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 RSVP reservation (TC reservation). Reservation styles
may also impact the definition of flows; a set of senders which are may also impact the definition of flows; a set of senders which are
considered as a single flow for WF reservation are considered as a considered as a single flow for WF reservation are considered as a
set of individual flows when FF style is used. 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 unpack 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 are, by default, all POLICY_DATA objects in the packed which are, by default, all POLICY_DATA objects in the packed
message. Sophisticated PEPs, capable of looking inside policy message. Sophisticated PEPs, capable of looking inside policy
objects, may examine the POLICY_DATA or SCOPE object to narrow down objects, may examine the POLICY_DATA or SCOPE object to narrow down
the list of associated flows (as optimization). the list of associated flows (as 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 Incoming as well as 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 as its matching Path state (associated state). State well as its matching Path state (associated state). State
association is trivial in the common unicast case since the RSVP association is trivial in the common unicast case since the RSVP
flow includes one Path state and one Resv state. In multicast cases flow includes one Path state and one Resv state. In multicast cases
this correspondence may be more complicated, as the match may be this correspondence may be more complicated, as the match may be
many to many. The COPS protocol assumes that the PDP is RSVP many to many. The COPS protocol assumes that the PDP is RSVP
knowledgeable and capable of determining these associations based on knowledgeable and capable of determining these associations based on
the contents of the Client REQ message and especially the ClientSI the contents of the Client REQ message and especially the ClientSI
object. 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 of
resources, the PEP must issue a no-commit report and fold back and 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).
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 messages need not be constantly sent to the remote PDP. Once a Resv 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
skipping to change at page 9, line 5 skipping to change at page 9, line 5
purge all its cached decisions. Without applicable cached decision, purge all its cached decisions. Without applicable cached decision,
the PEP must either reject the flow or resort to its LDP (if the PEP must either reject the flow or resort to its LDP (if
available) for decisions. available) for 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 PDP may issue a SSQ request. In this case, the PEP must reissue the 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 as LDP the
current (cached) decision regarding each such state. current (cached) decision regarding each such state.
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 output). Each step requires a separate policy decision as and output). Each step requires a separate policy decision as
indicated by context flags (see Section 2.1). In many cases, setting indicated by context flags (see Section 2.2). In many cases, setting
multiple context flags for bundling two or three operations together multiple context flags for bundling two or three operations together
in one request may significantly optimize protocol operations. in one 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 are guaranteed not to cause ambiguity and represent substantial
portion of expected COPS transactions. portion of expected COPS transactions.
Unicast FF: Unicast FF:
skipping to change at page 9, line 36 skipping to change at page 9, line 36
[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 processing
must first be processed as Incoming, then as Resource allocation must first be processed as Incoming, then as Resource allocation
and only then as Outgoing. When multiple context flags are set, and only then as Outgoing. When multiple context flags are set,
all ClientSI objects included in the request are assumed to be all ClientSI objects included in the request are assumed to be
processed to the latest flag. This rule applies both to request processed to the latest flag. This rule applies both to request
(REQ) context as well as to decision (DEC) context. (REQ) context as well as to 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 portion of the request context it applies to. When which portion of the request context it applies to. When
different decisions apply to different sub-groups of context the different decisions apply to different sub-groups of context the
PDP should send each group of decision objects encapsulated or PDP should send each group of decision objects encapsulated or
separated by the context flags object with the context flags separated by the context flags object with the context flags
applicable to these objects set. (See the examples in Section 4). applicable to these objects set. (See the examples in Section 4).
3.7. Trusted zones and secure policy tunneling 3.7 RSVP Error Reporting
RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to
report policy errors. While the contents of the ERROR_SPEC object is
defined in [RSVP,RSVP-EXT], the PDP is in the best position to
provide its contents (sub-codes). This is performed in the following
manner: First, the PEP (RSVP) queries the PDP before sending a
PathErr or ResvErr, and then the PDP returns the constructed
ERROR_SPEC in the Replacement Data Decision Object.
3.8 Security Considerations
Security for RSVP messages is provided by inter-router MD5 Security for RSVP messages is provided by inter-router MD5
authentication [MD5], assuming a chain-of-trust model. authentication [MD5], assuming a chain-of-trust model.
A possible deployment scenario calls for PEPs to be deployed at the A possible deployment scenario calls for PEPs to be deployed at the
network edge (boundary nodes) while PINs are deployed in the core of network edge (boundary nodes) while PINs are deployed in the core of
the network (backbone). In this case, MD5 trust (authentication) must the network (backbone). In this case, MD5 trust (authentication)
be established between boundary (non-neighboring) PEPs. Such PDP-PDP must be established between boundary (non-neighboring) PEPs. Such
trust can be achieved through internal signing (integrity) of the PDP-PDP trust can be achieved through internal signing (integrity)
Policy Data object (see [RSVP-EXT]). of the Policy Data object (see [RSVP-EXT]).
4. Illustrative Examples, Using COPS for RSVP 4 Illustrative Examples, Using COPS for RSVP
This section details both typical unicast and multicast scenarios. This section details both typical unicast and multicast scenarios.
4.1. Unicast Flow Example 4.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 respect to the following figure. with respect to the following figure.
PEP (router) PEP (router)
+-----------------+ +-----------------+
| | | |
R1 ------------+if1 if2+------------ S1 R1 ------------+if1 if2+------------ S1
| | | |
skipping to change at page 12, line 4 skipping to change at page 12, line 4
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>
4.2. Shared Multicast Flows
4.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 the following figure.
PEP (router) PEP (router)
+-----------------+ +-----------------+
| | | |
R1-------------+ if1 if3 +--------- S1 R1-------------+ if1 if3 +--------- S1
| | | |
skipping to change at page 15, line 17 skipping to change at page 15, line 17
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>
<clientSI: all objects in outgoing ResvErr> <ClientSI: all objects in outgoing ResvErr>
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.
5. References 5 References
[RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", Internet- [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control",
Draft, draft-ietf-rap-rsvp-ext-02.txt, Jan. 1999. Internet-Draft, draft-ietf-rap-rsvp-ext-02.txt, Jan. 1999.
[RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission [RAP] Yavatkar, R., et al., "A Framework for Policy Based
Control",IETF <draft-ietf-rap-framework-02.txt>, Jan., 1999. Admission 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, 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.
[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.
6. Author Information and Acknowledgments 6 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 Ron Cohen
Level 3 Communications CISCO Systems Level 3 Communications CISCO Systems
1450 Infinite Drive13 Hasadna St. 1450 Infinite Drive13 Hasadna St.
Louisville, CO 80027 Ra'anana 43650 Israel Louisville, CO 80027 Ra'anana 43650 Israel
303.926.3100 972.9.7462020 303.926.3100 972.9.7462020
 End of changes. 

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