draft-ietf-rap-cops-rsvp-03.txt   draft-ietf-rap-cops-rsvp-04.txt 
Internet Draft Jim Boyle Internet Draft Jim Boyle
Expiration: August 1999 Level3 Expiration: August 1999 Level3
File: draft-ietf-rap-cops-rsvp-03.txt Ron Cohen File: draft-ietf-rap-cops-rsvp-04.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
February 13, 1999 February 26, 1999
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
2.3 Client Specific Information (ClientSI)..........................4 2.3 Client Specific Information (ClientSI)..........................4
2.4 Decision Object (Decision)......................................5 2.4 Decision Object (Decision)......................................5
3 Operation of COPS for RSVP PEPs....................................6 3 Operation of COPS for RSVP PEPs....................................6
3.1 RSVP flows......................................................6 3.1 RSVP flows......................................................6
3.2 Expected Associations for RSVP Requests.........................6 3.2 Expected Associations for RSVP Requests.........................6
3.3 RSVP's Capacity Admission Control: Commit and Delete............7 3.3 RSVP's Capacity Admission Control: Commit and Delete............7
3.4 Policy Control Over PathTear and ResvTear.......................8 3.4 Policy Control Over PathTear and ResvTear.......................8
3.5 PEP Caching COPS Decisions......................................8 3.5 PEP Caching COPS Decisions......................................8
3.6 Using Multiple Context Flags in a single query..................9 3.6 Using Multiple Context Flags in a single query..................9
3.7 RSVP Error Reporting...........................................10 3.7 RSVP Error Reporting...........................................10
3.8 Security Considerations........................................10 4 Security Considerations...........................................10
4 Illustrative Examples, Using COPS for RSVP........................10 5 Illustrative Examples, Using COPS for RSVP........................11
4.1 Unicast Flow Example...........................................10 5.1 Unicast Flow Example...........................................11
4.2 Shared Multicast Flows.........................................12 5.2 Shared Multicast Flows.........................................13
5 References........................................................16 6 References........................................................16
6 Author Information and Acknowledgments............................16 7 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].
skipping to change at page 4, line 9 skipping to change at page 4, line 9
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)
The M-Type field in the Context Object may have one of the The M-Type field in the Context Object identifies the applicable
Following values that correspond to supported RSVP messages RSVP message type. M-Type values are derived from, and are identical
In COPS: to the values used in the "msg type" field in the RSVP header
[RSVP].
1 = Path The following RSVP message types are supported in COPS:
2 = Resv
3 = PathErr
4 = ResvErr
Note: The PathTear, ResvTear, and the Resv Confirm message types are Path
not supported. Resv
PathErr
ResvErr
Other message types such as PathTear, ResvTear, and Resv Confirm
message types are not supported. The list of supported message types
cannot be expended other than by later versions of RSVP and/or later
version of this document.
2.3 Client Specific Information (ClientSI) 2.3 Client Specific Information (ClientSI)
All objects that were received within an RSVP message are All objects that were received 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
client-specific info missing". If, on the other hand, the PDP client-specific info missing". If, on the other hand, the PDP
detects the absence of optional RSVP objects that are needed to detects the absence of optional RSVP objects that are needed to
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.4 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
RSVPs response to messages. While accepting an RSVP message, PDPs RSVP's response to messages. While accepting an RSVP message, PDPs
may provide preemption priority, trigger warnings, replace RSVP may provide preemption priority, trigger warnings, replace RSVP
objects, and much more, using Decision Commands, Flags and Objects. objects, and much more, using Decision Commands, Flags and Objects.
DECISION COMMANDS DECISION COMMANDS
Only two commands apply to RSVP Only two commands apply to RSVP
Install Install
Positive Response: Positive Response:
skipping to change at page 5, line 39 skipping to change at page 5, line 39
Trigger Error Trigger Error
If this flag is set, RSVP should schedule a PathErr, in response If this flag is set, RSVP should schedule a PathErr, in response
of a Path message, or a ResvErr (in response of a Resv message). of a Path message, or a ResvErr (in response of a Resv message).
STATELESS POLICY DATA STATELESS POLICY DATA
This object may include one or more policy elements (as specified This object may include one or more policy elements (as specified
for 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 clients LDP. The PEP should consider these well understood by the client's LDP. The PEP should consider these
as an addition to the decision already received from the PDP (it can as an addition to the decision already received from the PDP (it can
only add, but cannot override it). only add, but cannot override it).
For example: Given Policy Elements that specify a flows 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.
Stateless objects must be well understood, but not necessarily Stateless objects must be well understood, but not necessarily
supported by all PEPs. For example, assuming a standard policy supported by all PEPs. For example, assuming a standard policy
element for preemption priority, it is perfectly legitimate for some element for preemption priority, it is perfectly legitimate for some
PEPs not to support such preemption and to ignore it. The PDP must PEPs not to support such preemption and to ignore it. The PDP must
be careful when using such objects, especially, it must be prepared be careful when using such objects, especially, it must be prepared
for these objects would be ignored by PEPs. for these objects would be ignored by PEPs.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
POLICY_DATA object in the incoming message. When applied to Resource POLICY_DATA object in the incoming message. When applied to Resource
Allocation it is assumed to have been received on all merged Allocation it is assumed to have been received on all merged
incoming messages. Last, when applied to outgoing message it is incoming messages. Last, when applied to outgoing message it is
assumed to have been received in all messages contributing to the assumed to have been received in all messages contributing to the
outgoing message. outgoing message.
REPLACEMENT DATA REPLACEMENT DATA
The Replacement object may contain multiple RSVP objects to be The Replacement object may contain multiple RSVP objects to be
replaced (from the original RSVP request). Typical replacement is replaced (from the original RSVP request). Typical replacement is
performed on the “Forward Outgoing” request (for instance, replacing performed on the "Forward Outgoing" request (for instance, replacing
outgoing Policy Data), but is not limited, and can also be performed outgoing Policy Data), but is not limited, and can also be performed
on other contexts (such as “Resources-Allocation Request”). In other on other contexts (such as "Resources-Allocation Request"). In other
cases, replacement of the RSVP FlowSpec object may be useful for cases, replacement of the RSVP FlowSpec object may be useful for
controlling resources across a trusted zone (with PIN nodes). controlling resources across a trusted zone (with policy ignorant
Currently, RSVP clients are only required to allow replacement of nodes (PINs). Currently, RSVP clients are only required to allow
three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC, but could replacement of three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC,
optionally support replacement of more objects. but could 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.
skipping to change at page 6, line 57 skipping to change at page 6, line 57
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 straightforward in the common unicast case since the
flow includes one Path state and one Resv state. In multicast cases RSVP flow includes one Path state and one Resv state. In multicast
this correspondence may be more complicated, as the match may be cases this correspondence may be more complicated, as the match may
many to many. The COPS protocol assumes that the PDP is RSVP be 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
skipping to change at page 9, line 44 skipping to change at page 9, line 44
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 5).
3.7 RSVP Error Reporting 3.7 RSVP Error Reporting
RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to
report policy errors. While the contents of the ERROR_SPEC object is report policy errors. While the contents of the ERROR_SPEC object is
defined in [RSVP,RSVP-EXT], the PDP is in the best position to defined in [RSVP,RSVP-EXT], the PDP is in the best position to
provide its contents (sub-codes). This is performed in the following provide its contents (sub-codes). This is performed in the following
manner: First, the PEP (RSVP) queries the PDP before sending a manner: First, the PEP (RSVP) queries the PDP before sending a
PathErr or ResvErr, and then the PDP returns the constructed PathErr or ResvErr, and then the PDP returns the constructed
ERROR_SPEC in the Replacement Data Decision Object. ERROR_SPEC in the Replacement Data Decision Object.
3.8 Security Considerations 4 Security Considerations
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 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 likely deployment scenario calls for PEPs to be deployed only at
network edge (boundary nodes) while PINs are deployed in the core of the network edge (boundary nodes) while the core of the network
the network (backbone). In this case, MD5 trust (authentication) (backbone) constitutes of PIN nodes. In this scenario MD5 trust
must be established between boundary (non-neighboring) PEPs. Such (authentication) is established between boundary (non-neighboring)
PDP-PDP trust can be achieved through internal signing (integrity) PEPs. Such trust can be achieved through internal signing
of the Policy Data object (see [RSVP-EXT]). (integrity) of the Policy Data object itself, which is left
unmodified as it passes through PIN nodes (see [RSVP-EXT]).
4 Illustrative Examples, Using COPS for RSVP 5 Illustrative Examples, Using COPS for RSVP
This section details both typical unicast and multicast scenarios. This section details both typical unicast and multicast scenarios.
4.1 Unicast Flow Example 5.1 Unicast Flow Example
This section details the steps in using COPS for controlling a This section details the steps in using COPS for controlling a
Unicast RSVP flow. It details the contents of the COPS messages Unicast RSVP flow. It details the contents of the COPS messages
with 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 5 skipping to change at page 13, line 5
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 5.2 Shared Multicast Flows
This section details the steps in using COPS for controlling a This section details the steps in using COPS for controlling a
multicast RSVP flow. It details the contents of the COPS messages multicast RSVP flow. It details the contents of the COPS messages
with respect to the following figure. with respect to the following figure.
PEP (router) PEP (router)
+-----------------+ +-----------------+
| | | |
R1-------------+ if1 if3 +--------- S1 R1-------------+ if1 if3 +--------- S1
| | | |
skipping to change at page 16, line 5 skipping to change at page 16, line 5
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 6 References
[RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control",
Internet-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 [RAP] Yavatkar, R., et al., "A Framework for Policy Based
Admission Control", IETF <draft-ietf-rap-framework-02.txt>, Admission Control", IETF <draft-ietf-rap-framework-02.txt>,
Jan., 1999. Jan., 1999.
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, 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 7 Author Information and Acknowledgments
Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs,
Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan, Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan,
and Raj Yavatkar, for their valuable contributions. and Raj Yavatkar, for their valuable contributions.
Jim Boyle Ron Cohen Jim Boyle 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/