draft-ietf-rap-cops-rsvp-01.txt   draft-ietf-rap-cops-rsvp-02.txt 
Internet Draft Jim Boyle Internet Draft Jim Boyle
Expiration: Apr. 1999 Level3 Expiration: July 1999 Level3
File: draft-ietf-rap-cops-rsvp-01.txt Ron Cohen File: draft-ietf-rap-cops-rsvp-02.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: November 18, 1998 Last Updated: January 22, 1999
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
skipping to change at page 2, line 7 skipping to change at page 2, line 12
document will expire at the expiration date listed above. document will expire at the expiration date listed above.
Distribution of this draft is unlimited. Distribution of this draft is unlimited.
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.............................................................1 Abstract.............................................................2
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.Context Object (Context).........................................3
2.2.Client Specific Information (ClientSI)...........................4 2.2.Client Specific Information (ClientSI)...........................4
2.3.Decision Object (Decision).......................................4 2.3.Decision Object (Decision).......................................5
3.Operation of COPS for Policy Control Over RSVP.....................5 3.Operation of COPS for RSVP PEPs....................................6
3.1.RSVP flows.......................................................5 3.1.RSVP flows.......................................................6
3.2.Expected Associations for RSVP Requests..........................5 3.2.Expected Associations for RSVP Requests..........................7
3.3.RSVP's Capacity Admission Control: Commit and Delete.............6 3.3.RSVP's Capacity Admission Control: Commit and Delete.............7
3.4.Policy Control Over PathTear and ResvTear........................6 3.4.Policy Control Over PathTear and ResvTear........................8
3.5.PEP Caching COPS Decisions.......................................6 3.5.PEP Caching COPS Decisions.......................................8
3.6.Using Multiple Context Flags in a single query...................7 3.6.Using Multiple Context Flags in a single query...................9
3.7.Trusted zones and secure policy tunneling........................7 3.7.Trusted zones and secure policy tunneling.......................10
4.Illustrative Examples, Using COPS for RSVP.........................8 4.Illustrative Examples, Using COPS for RSVP........................10
4.1.Unicast Flow Example.............................................8 4.1.Unicast Flow Example............................................10
4.2.Shared Multicast Flows...........................................9 4.2.Shared Multicast Flows..........................................12
5.References........................................................13 5.References........................................................16
6.Author Information and Acknowledgments............................13 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 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, client specific functionality is Given the COPS protocol design, RSVP directives are mainly limited
mainly limited to interoperability usage guidelines as well as to RSVP applicability, interoperability, usage guidelines, as well
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 format and usage of several COPS objects is affected when used
for client type RSVP. This section describes these objects and the for client type RSVP. This section describes these objects and the
usage. usage.
2.1. Context Object (Context) 2.1. 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)
0x01 = Incoming-Message request Incoming-Message request
The arrival of an incoming RSVP message
Allows processing of incoming policy information as well as This context is requested when the PEP receives an incoming
the decision whether to accept an incoming message. If It is RSVP message. The PDP may decide to accept or reject the
rejected, the message is treated as if it never Arrived. incoming message and may also apply other decision object to
it. If the incoming message is rejected, RSVP should treat it
as if it never arrived.
0x02 = Resource-Allocation request Resource-Allocation request
Applies only for Resv messages.
The decision whether to admit a reservation and commit local This context is requested when the PEP is about to commit
resources to it is performed for the merge of all local resources to an RSVP flow (admission control). This
reservations that arrived on a particular interface context applies to Resv messages only. The decision whether
(potentially from several RSVP Next-Hops). to commit local resources is performed for the merge of all
reservations associated with an RSVP flow (which have arrived
on a particular interface, potentially from several RSVP
Next-Hops).
0x04 = Outgoing-Message request Outgoing-Message request (forwarding an outgoing RSVP message)
The forwarding of an outgoing RSVP message.
The Decision whether to allow the forwarding of an outgoing This context is requested when the PEP is about to forward an
RSVP message as well as providing the relevant outgoing outgoing RSVP message. The PDP may decide to allow or deny
policy information. 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 may have one of the The M-Type field in the Context Object may have one of the
Following values that correspond to supported RSVP messages Following values that correspond to supported RSVP messages
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.2. Client Specific Information (ClientSI)
All objects that were received within an RSVP message that are All objects that were received within an RSVP message are
associated with the RSVP flow are encapsulated inside the Client encapsulated inside the Client Specific Information Object (Signaled
Specific Information Object without alteration. (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). These RSVP objects multiple flows packed in a single RSVP message).
are simply contained within a single Signaled Client Specific
Information Object (RSVP ClientSI) exchanged between the PEP and The PEP and PDP share RSVP state and the PDP is assumed to implement
remote PDP. the same RSVP functional specification as the PEP. In the case where
a PDP detects the absence of objects required by [RSVP] it should
return an <Error> in the Decision message indicating "Mandatory
client-specific info missing". If, on the other hand, the PDP
detects the absence of optional RSVP objects that are needed to
approve the Request against current policies, the PDP should return
a negative <Decision>.
Unlike the Incoming and Outgoing contexts, “Resource Allocation”
isn’t always directly associated with a specific RSVP message. In a
multicast session, it may represent the merging of multiple incoming
reservations. Therefore, the ClientSI object should specifically
contain the SESSION and STYLE objects along with the merged
FLOWSPEC, FILTERSPEC list and SCOPE object (whenever relevant).
2.3. Decision Object (Decision) 2.3. Decision Object (Decision)
COPS allows PDP to control RSVP’s response to messages. Beyond COPS provide the PDP with flexible controls over the PEP using
traditional accept/deny, PDPs may use the Trigger Error flag to RSVP’s response to messages. While accepting an RSVP message, PDPs
allow a request yet trigger a warning at the same time. To allow may provide preemption priority, trigger warnings, replace RSVP
resource allocation yet deny forwarding of a message, etc. objects, and much more, using Decision Commands, Flags and Objects.
Decision Flags DECISION COMMANDS
The following decision flags apply to RSVP: Only two commands apply to RSVP
0x01 = Signaled (RSVP) accept (deny if set) Install
This flag should be interpreted with the decision context Positive Response:
flag to figure out what it applies to. Accept/Allow/Admit an RSVP message or local resource allocation.
0x08 = Trigger Error (PathErr for Path query, or ResvErr for Resv) Remove
Client Specific Policy Information Negative Response:
Deny/Reject/Remove an RSVP message or local resource allocation.
DECISION FLAGS
The only decision flag that applies to RSVP:
Trigger Error
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).
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 the RSVP Policy Data object [RSVP-EXT] which are assumed to be for the RSVP Policy Data object [RSVP-EXT]) which are assumed to be
well understood by the client’s LDP. The PEP should consider these well understood by the client’s LDP. The PEP should consider these
as if they arrived in the message Policy Data object. as an addition to the decision already received from the PDP (it can
only 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 also be provided by the PDP responding to a query.
Replacement Data Stateless objects must be well understood, but not necessarily
supported by all PEPs. For example, assuming a standard policy
element for preemption priority, it is perfectly legitimate for some
PEPs not to support such preemption and to ignore it. The PDP must
be careful when using such objects, especially, it must be prepared
for these objects would be ignored by PEPs.
Stateless Policy Data may be returned in decisions and apply
individually to each of the contexts flagged in REQ messages. When
applied to Incoming, it is assumed to have been received as a
POLICY_DATA object in the incoming message. When applied to Resource
Allocation it is assumed to have been received on all merged
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
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 “Allocate Resources”). Other examples, on other contexts (such as “Resources-Allocation Request”). In other
may require replacement of the RSVP FlowSpec object for controlling cases, replacement of the RSVP FlowSpec object may be useful for
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. two objects: Policy Data and FlowSpec, but could optionally support
replacement of more objects.
RSVP object replacement is performed in the following manner:
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 passed as if the PDP was not there. When an all signaled objects are processed as if the PDP was not there. When
object of a certain C-Num appears it replaces ALL the instances of an object of a certain C-Num appears it replaces ALL the instances
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 Policy Control Over RSVP 3. Operation of COPS for RSVP PEPs
3.1. RSVP flows 3.1. RSVP flows
Policy Control is performed per RSVP flow. An RSVP flow corresponds Policy Control is performed per RSVP flow, which is defined by the
to an atomic unit of reservation as identified by RSVP (TC atomic unit of RSVP reservation (TC reservation). Reservation styles
reservation). It should be noted that RSVP allows multiple flows to may also impact the definition of flows; a set of senders which are
be packed (which is different from merged) into a single FF Resv considered as a single flow for WF reservation are considered as a
message. To support such messages a separate COPS request must be set of individual flows when FF style is used.
issued for each of the packed flows as if they were individual RSVP
messages. 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
of the packed flows as if they were individual RSVP messages. Each
COPS Request should include the associated POLICY_DATA objects,
which are, by default, all POLICY_DATA objects in the packed
message. Sophisticated PEPs, capable of looking inside policy
objects, may examine the POLICY_DATA or SCOPE object to narrow down
the list of associated flows (as optimization).
Please note that the rules governing Packed RSVP message apply
equally to Incoming as well as Outgoing REQ context.
3.2. Expected Associations for RSVP Requests 3.2. Expected Associations for RSVP Requests
RSVP signaling requires the participation of both senders and When making a policy decision, the PDP may consider both Resv as
receivers. RSVP processing rules define what is the subset of the well as its matching Path state (associated state). State
Path state that matches each Resv state. In the common unicast case, association is trivial in the common unicast case since the RSVP
the RSVP session includes one Path state and one Resv state. In flow includes one Path state and one Resv state. In multicast cases
multicast cases the correspondence might be many to many. Since the this correspondence may be more complicated, as the match may be
decision to admit a reservation for a session may depend on many to many. The COPS protocol assumes that the PDP is RSVP
information carried both in Path and Resv messages, we term the Path knowledgeable and capable of determining these associations based on
States that match with a single Resv state as its associated states. the contents of the Client REQ message and especially the ClientSI
It is assumed that the PDP is capable of determining these object.
associations based on the RSVP message processing rules given the
RSVP objects expressed in the COPS Client Specific Information
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. Once local admission control accepts the reservation, the control. After being approved by both, and after the reservation was
PEP notifies the remote PDP by sending a report message specifying successfully installed, the PEP notifies the remote PDP by sending a
the Commit type. The Commit type report message is to be used to report message specifying the Commit type. The Commit type report
signify when billing should effectively begin, and performing message signals when billing should effectively begin and performing
heavier operations (e.g., debiting a credit card) is permissible. heavier delayed operations (e.g., debiting a credit card) is
permissible by the PDP.
If instead a reservation approved by the PDP fails admission due to If instead a PDP approved reservation fails admission due to lack of
lack of resources, the PEP must issue a no-commit report and fold resources, the PEP must issue a no-commit report and fold back and
back and send an updated request to its previous state (previously send an updated request to its previous state (previously installed
installed reservation). If no state was previously installed, the reservation). If no state was previously installed, the PEP should
PEP should issue a delete. 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. The PEP is only decision and apply it to future refreshes. When the PEP detects a
responsible for updating a request state if there is a change change in the corresponding Resv or Path message, it should update
detected in the corresponding Resv or Path message. the PDP with the new request-state. PEPs may continue to use the
cached state until receiving the PDP response. This case is very
different from initial admission of a flow; given that valid
credentials and authentication have already been established, the
relative long RSVP refresh period, and the short PEP-PDP response
time, the tradeoff between expedient updates and attack prevention
leans toward expediency. However, this is really a PEP choice, and
is 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. If no RSVP state may be retained for the RSVP timeout period to be used
connection can be reestablished with the PDP or a backup PDP after for previously admitted flows (but cannot be applied to new or
the timeout period, the RSVP PEP is expected to default back to updated state). If connection can not be reestablished with the PDP
using its LDP results. Additionally, the LDP is to be used for the or a backup PDP after the timeout period, the PEP is expected to
admission control of any new RSVP messages that may have arrived purge all its cached decisions. Without applicable cached decision,
while connectivity was lost. the PEP must either reject the flow or resort to its LDP (if
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
skipping to change at page 8, line 4 skipping to change at page 10, line 6
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. Trusted zones and secure policy tunneling
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) must
be established between boundary (non-neighboring) PEPs, which is be established between boundary (non-neighboring) PEPs. Such PDP-PDP
achieved through internal signing of the Policy Data object. [RSVP- trust can be achieved through internal signing (integrity) of the
EXT]. 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.
skipping to change at page 8, line 42 skipping to change at page 10, line 45
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>
PDP --> PEP DEC := <Handle A> <Context: in & out, Path> PDP --> PEP DEC := <Handle A> <Context: in & out, Path>
<Decision flags: Accept> <Decision: Command, Install>
A Resv message arrives from R1: A Resv message arrives from R1:
PEP --> PDP REQ := <Handle B> PEP --> PDP REQ := <Handle B>
<Context: in & allocation & out, Resv> <Context: in & allocation & out, Resv>
<In-Interface if1> <Out-Interface if2> <In-Interface if1> <Out-Interface if2>
<ClientSI: all objects in Resv message> <ClientSI: all objects in Resv message>
PDP --> PEP DEC := <Handle B> PDP --> PEP DEC := <Handle B>
<Context: in, Resv> <Context: in, Resv>
<Decision flags: accept> <Decision: command, Install>
<Context: allocation, Resv> <Context: allocation, Resv>
<Decision flags: accept> <Decision: command, Install>
<Decision: ClientSI, Priority=7> <Decision: Stateless, Priority=7>
<Context: out, Resv> <Context: out, Resv>
<Decision flags: accept> <Decision: command, Install>
<Decision replace: 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:
PDP --> PEP DEC := <Handle B> PDP --> PEP DEC := <Handle B>
<Context: allocation, Resv> <Context: allocation, Resv>
<Decision flags: accept> <Decision: command, Install>
<Decision: ClientSI, 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>
skipping to change at page 10, line 4 skipping to change at page 12, line 20
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 assume that the multicast membership is already In this example, we assume that the multicast membership is already
in place, no previous RSVP messages were received, and the first to in place. No previous RSVP messages were received, and the first to
arrive is a Path message on interface if3 from sender S1: arrive is a Path 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 flags: accept> <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
interface if1, another exchange would likewise be completed for if2 interface if1, another exchange would likewise be completed for if2
using the new handle B2. using the new handle B2.
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 flags: accept> <Decision: command, Install>
<Decision Replacement: POLICY-DATA1> <Decision: Replacement, POLICY-DATA1>
Here, the PDP decided to allow the forwarding of the Path message Here, the PDP decided to allow the forwarding of the Path message
and provided the appropriate policy-data object for interface if1. 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>
<Decision flags: accept> <Decision: command, Install>
<Context: allocation, Resv> <Context: allocation, Resv>
<Decision flags: accept> <Decision: command, Install>
<Decision ClientSI: priority=5> <Decision: Stateless, priority=5>
PEP --> PDP RPT := <handle C> <Commit> PEP --> PDP RPT := <handle C> <Commit>
Here, the PDP approves the reservation and assigned it preemption Here, the PDP approves the reservation and assigned it preemption
priority of 5. The PEP responded with a commit report. priority of 5. The PEP responded with a commit report.
The PEP needs to forward the Resv message upstream toward S1: The PEP needs to forward the Resv message upstream toward S1:
PEP --> PDP REQ := <Handle E> <Context: out, Resv> PEP --> PDP REQ := <Handle E> <Context: out, Resv>
<out-interface if3> <out-interface if3>
<Client info: all objects in outgoing Resv> <Client info: all objects in outgoing Resv>
PDP --> PEP DEC := <Handle E> PDP --> PEP DEC := <Handle E>
skipping to change at page 11, line 15 skipping to change at page 13, line 44
priority of 5. The PEP responded with a commit report. priority of 5. The PEP responded with a commit report.
The PEP needs to forward the Resv message upstream toward S1: The PEP needs to forward the Resv message upstream toward S1:
PEP --> PDP REQ := <Handle E> <Context: out, Resv> PEP --> PDP REQ := <Handle E> <Context: out, Resv>
<out-interface if3> <out-interface if3>
<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 flags: accept> <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 with a higher RSpec (Rspec2). Given two reservations arrived on if2 with a higher RSpec (Rspec2). Given two reservations arrived on
if2, it cannot perform a request with multiple context flags, and if2, it cannot perform a request with multiple context flags, and
must issue them separately. must issue them separately.
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>
<Decision flags: accept> <Decision: command, Install>
PEP --> PDP REQ := <Handle G> <Context: allocation, Resv> PEP --> PDP REQ := <Handle G> <Context: allocation, Resv>
<In-interface if2> <In-interface if2>
<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 flags: accept> <Decision: command, Install>
<Decision ClientSI: 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 new outgoing Resv message upstream toward S1. This repeats exactly a 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 has a higher flowspec: Rspec2) the following takes place: it 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 flags: accept> <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 flags: accept> <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", [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", Internet-
Internet-Draft, draft-ietf-rap-rsvp-ext-00.txt, Apr. 1998. 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 Admission
Control",IETF <draft-ietf-rap-framework-00.txt>, November, Control",IETF <draft-ietf-rap-framework-02.txt>, Jan., 1999.
1997.
[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-02.txt>, Aug. 1998. IETF <draft-ietf-rap-cops-05.txt>, Jan. 1999.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
"Resource Reservation Protocol (RSVP) Version 1 Functional Functional Specification.", IETF RFC 2205, Proposed Standard,
Specification", IETF RFC 2205, Proposed Standard, September Sep. 1997.
1997.
6. Author Information and Acknowledgments 6. Author Information and Acknowledgments
Special thanks to Timothy O'Malley our WG Chair, Raj Yavatkar, Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs,
Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan, Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan,
and Dimitrios Pendarakis 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
email: jboyle@l3.net ronc@cisco.com email: jboyle@l3.net ronc@cisco.com
David Durham Raju Rajan David Durham Raju Rajan
Intel IBM T.J. Watson Research Cntr Intel IBM T.J. Watson Research Cntr
 End of changes. 

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