Requirements for Addresses Registration
draft-jiang-6man-addr-registration-req-02

Internet Draft                                            Jim Boyle
Expiration: December 1999                                  Level3
File: draft-ietf-rap-cops-rsvp-05.txt                    Ron Cohen
                                                            Cisco
                                                          David Durham
                                                            Intel
                                                          Shai Herzog
                                                            IPHighway
                                                          Raju Rajan
                                                            AT&T
                                                          Arun Sastry
                                                            Cisco

                          COPS usage for RSVP

                            June 14, 1999

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

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

Internet Draft          Expires December 1999                [Page 1]

Internet Draft              COPS usage for RSVP              14-Jun-99

Table of Contents

Abstract.............................................................1
Table of Contents....................................................2
1 Introduction.......................................................3
2 RSVP values for COPS objects.......................................3
2.1  Common Header, client-type......................................3
2.2  Context Object (Context)........................................3
2.3  Client Specific Information (ClientSI)..........................4
2.4  Decision Object (Decision)......................................5
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
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........................10
5.1  Unicast Flow Example...........................................10
5.2  Shared Multicast Flows.........................................12
6 References........................................................15
7 Author Information and Acknowledgments............................15

Shai Herzog            Expires December 1999                [Page 2]

Internet Draft              COPS usage for RSVP              14-Jun-99

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 the RSVP
  client type. This section describes these objects and their usage.

2.1 Common Header, client-type

  RSVP is COPS client-type 1

2.2 Context Object (Context)

  The semantics of the Context object for RSVP is as follows:

  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

Shai Herzog            Expires December 1999                [Page 3]

Internet Draft              COPS usage for RSVP              14-Jun-99

          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.

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).

Shai Herzog            Expires December 1999                [Page 4]

Internet Draft              COPS usage for RSVP              14-Jun-99

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.

  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 LDP. 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&draft-jiang-6man-addr-registration-req-01.txt