rfc2749.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页

Network Working Group                                    S . Herzog, Ed.
Request for Comments: 2749                                     IPHighway
Category: Standards Track                                       J. Boyle
                                                                  Level3
                                                                R. Cohen
                                                                   Cisco
                                                               D. Durham
                                                                   Intel
                                                                R. Rajan
                                                                    AT&T
                                                               A. Sastry
                                                                   Cisco
                                                            January 2000


                          COPS usage for RSVP


Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document describes usage directives for supporting COPS policy
   services in RSVP environments.

Table of Contents

   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  Introduction

   The Common Open Policy Service (COPS) protocol is a query response
   protocol used to exchange policy information between a network policy
   server and a set of clients [COPS]. COPS is being developed within
   the RSVP Admission Policy Working Group (RAP WG) of the IETF,
   primarily for use as a mechanism for providing policy-based admission
   control over requests for network resources [RAP].

   This document is based on and assumes prior knowledge of the RAP
   framework [RAP] and the basic COPS [COPS] protocol. It provides
   specific usage directives for using COPS in outsourcing policy
   control decisions by RSVP clients (PEPs) to policy servers (PDPs).

   Given the COPS protocol design, RSVP directives are mainly limited to
   RSVP applicability, interoperability and usage guidelines, as well as
   client specific examples.

2  RSVP values for COPS objects

   The usage of several COPS objects is affected when used with the RSVP
   client type. This section describes these objects and their usage.

2.1 Common Header, client-type

   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 request

         This context is used when the PEP receives an incoming RSVP
         message. The PDP may decide to accept or reject the incoming
         message and may also apply other decision objects to it. If the
         incoming message is rejected, RSVP should treat it as if it
         never arrived.

   Resource-Allocation request

         This context is used when the PEP is about to commit local
         resources to an RSVP flow (admission control). This context
         applies to Resv messages only. The decision whether to commit
         local resources is made for the merge of all reservations
         associated with an RSVP flow (which have arrived on a
         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 an
         outgoing RSVP message. The PDP may decide to allow or deny the
         outgoing message, as well as provide an outgoing policy data
         object.

   M-Type (Message Type)

   The M-Type field in the Context Object identifies the applicable RSVP
   message type. M-Type values are identical to the values used in the
   "msg type" field in the RSVP header [RSVP].

   The following RSVP message types are supported in COPS:

   Path
   Resv
   PathErr
   ResvErr

   Other message types such as PathTear, ResvTear, and Resv Confirm are
   not supported. The list of supported message types can only be
   extended in later versions of RSVP and/or later version of this
   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 encapsulated
   inside the Client Specific Information Object (Signaled ClientSI)
   sent from the PEP to the remote PDP (see Section 3.1. on multiple
   flows packed in a single RSVP message).

   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
   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" is
   not 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.4 Decision Object (Decision)

   COPS provides the PDP with flexible controls over the PEP using
   RSVP's response to messages. While accepting an RSVP message, PDPs
   may provide preemption priority, trigger warnings, replace RSVP
   objects, and much more, using Decision Commands, Flags, and Objects.

   DECISION COMMANDS

   Only two commands apply to RSVP

   Install

     Positive Response:
     Accept/Allow/Admit an RSVP message or local resource allocation.

   Remove

     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 FLAGS

   The only decision flag that applies to RSVP:

   Trigger Error

     If this flag is set, RSVP should schedule a PathErr, in response
     to 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 for
   the RSVP Policy Data object [RSVP-EXT]) which are assumed to be well
   understood by the client's LPDP. The PEP should consider these 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
   priority, these elements may be included in an incoming Resv message
   or may be provided by the PDP responding to a query.

   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. In particular, it must be prepared
   for these objects to 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 messages 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
   replaced (from the original RSVP request). Typical replacement is
   performed on the "Forward Outgoing" request (for instance, replacing
   outgoing Policy Data), but is not limited, and can also be performed
   on other contexts (such as "Resources-Allocation Request"). In other
   cases, replacement of the RSVP FlowSpec object may be useful for
   controlling resources across a trusted zone (with policy ignorant





Herzog, et al.              Standards Track                     [Page 5]

RFC 2749                  COPS usage for RSVP               January 2000


   nodes (PINs). Currently, RSVP clients are only required to allow
   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, 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 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 without adding
   anything.

3  Operation of COPS for RSVP PEPs

3.1 RSVP flows

   Policy Control is performed per RSVP flow, which is defined by the
   atomic unit of an RSVP reservation (TC reservation). Reservation
   styles 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 set of individual flows when FF style is used.

   Multiple FF flows may be packed into a single Resv message. A packed
   message must be unpacked 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 an optimization).

   Please note that the rules governing Packed RSVP message apply