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