rfc2940.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,516 行 · 第 1/4 页

Network Working Group                                            A. Smith
Request for Comments: 2940                                     Consultant
Category: Standards Track                                      D. Partain
                                                                 Ericsson
                                                              J. Seligson
                                                          Nortel Networks
                                                             October 2000


  Definitions of Managed Objects for Common Open Policy Service (COPS)
                            Protocol Clients

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 memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP based internets.
   In particular it defines objects for managing a client of the Common
   Open Policy Service (COPS) protocol.

   This memo includes a MIB module in a manner that is compliant to the
   SMIv2 [V2SMI].


















Smith                       Standards Track                     [Page 1]

RFC 2940                    COPS Client MIB                 October 2000


1.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

      o  An overall architecture, described in an Architecture for
         Describing SNMP Management Frameworks [ARCH].

      o  Mechanisms for describing and naming objects and events for the
         purpose of management.  The first version of this Structure of
         Management Information (SMI) is called SMIv1 and described in
         STD 16, RFC 1155 [V1SMI], STD 16, RFC 1212 [V1CONCISE] and RFC
         1215 [V1TRAPS].  The second version, called SMIv2, is described
         in STD 58, RFC 2578 [V2SMI], STD 58, RFC 2579 [V2TC] and STD
         58, RFC 2580 [V2CONFORM].

      o  Message protocols for transferring management information.  The
         first version of the SNMP message protocol is called SNMPv1 and
         described in STD 15, RFC 1157 [V1PROTO].  A second version of
         the SNMP message protocol, which is not an Internet standards
         track protocol, is called SNMPv2c and described in RFC 1901
         [V2COMMUNITY] and RFC 1906 [V2TRANS].  The third version of the
         message protocol is called SNMPv3 and described in RFC1906
         [V2TRANS], Message Processing and Dispatching [V3MPC] and
         User-based Security Model [V3USM].

      o  Protocol operations for accessing management information.  The
         first set of protocol operations and associated PDU formats is
         described in STD 15, RFC 1157 [V1PROTO].  A second set of
         protocol operations and associated PDU formats is described in
         RFC 1905 [V2PROTO].

      o  A set of fundamental applications described in SNMPv3
         Applications [V3APPS] and the view-based access control
         mechanism described in View-based Access Control Model
         [V3VACM].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [V3INTRO].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no



Smith                       Standards Track                     [Page 2]

RFC 2940                    COPS Client MIB                 October 2000


   translation is possible (use of Counter64).  Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

2.  Overview

   The COPS protocol [COPS] is a client-server protocol intended for the
   communication of policy requests and decisions between a Policy
   Enforcement Point (PEP) and a Policy Decision Point (PDP).  The PEP
   acts as a COPS client in this scenario.  The model for policy out-
   sourcing, of which the COPS protocol provides one part, is described
   in [FRAMEWORK].

2.1.  Scope

   This MIB is intended to provide management of the important features
   of a COPS protocol client module. It does not provide management for
   a COPS server - this is outside the scope of the current memo.  It
   provides for monitoring of status and protocol statistics, as well as
   for configuration of the client, in particular for telling it where
   to locate its servers.  Other mechanisms for achieving this function
   without SNMP configuration might include use of the Service Location
   Protocol [SRVLOC] although this is outside the scope of this memo and
   are not specified by the COPS protocol itself.

   This MIB also does not provide management of specific COPS client-
   types e.g., for use with the RSVP protocol [RSVP][COPSRSVP].

3.  Structure of COPS Client MIB

   Objects in this MIB are arranged into groups.  Each group is
   organized as a set of related objects. The overall structure is
   described below.

3.1.  copsClientCapabilitiesGroup

   This group contains objects that represent COPS protocol capabilities
   implemented by this COPS client.

3.2.  copsClientStatusGroup

   This group contains objects that indicate the current status of
   connection(s) to COPS servers, including per-server protocol
   statistics.  It maintains last-known statistics for all of the
   servers with which the client has ever been connected since agent
   restart.



Smith                       Standards Track                     [Page 3]

RFC 2940                    COPS Client MIB                 October 2000


3.3.  copsConfigGroup

   This group contains objects that allow for configuration of COPS
   server addresses and the order to which connections should be
   attempted.  It contains a table of per-server objects as well as
   scalars for configuration of the retry algorithm to be used by a
   client to obtain a connection to an appropriate server.

3.4.  Textual Conventions

   The datatypes CopsClientState, CopsServerEntryType, CopsErrorCode,
   CopsTcpPort and CopsAuthType are used as textual conventions in this
   document.  These textual conventions have NO effect on either the
   syntax nor the semantics of any managed object.  Objects defined
   using these conventions are always encoded by means of the rules that
   define their primitive type.  Hence, no changes to the SMI or the
   SNMP are necessary to accommodate these textual conventions which are
   adopted merely for the convenience of readers.

3.5.  Relationship to Other MIBs

3.5.1.  Relationship to the 'system' group

   This MIB contains definitions for a single COPS protocol client
   represented by a single SNMP agent and instance of the MIB-2 system
   group [MIB2].  It does not address the case of multiple co-located
   COPS protocol clients.

4.  Definitions for COPS Client MIB

COPS-CLIENT-MIB DEFINITIONS ::= BEGIN

-- -------------------------------------------------------------
-- -------------------------------------------------------------

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32,
    Unsigned32, mib-2
        FROM SNMPv2-SMI
    TimeStamp, TimeInterval, RowStatus, TEXTUAL-CONVENTION
        FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP
        FROM SNMPv2-CONF
    InetAddressType, InetAddress
        FROM INET-ADDRESS-MIB;


--    REFERENCE



Smith                       Standards Track                     [Page 4]

RFC 2940                    COPS Client MIB                 October 2000


--        "The COPS (Common Open Policy Service) Protocol RFC 2748

copsClientMIB MODULE-IDENTITY
    LAST-UPDATED "200009280000Z"
    ORGANIZATION "IETF RSVP Admission Policy Working Group"
    CONTACT-INFO
        "       Andrew Smith (WG co-chair)
         Phone: [phone]
         Email: [e-mail]

                Mark Stevens (WG co-chair)
         Phone: [phone]
         Email: [e-mail]

         Editor: Andrew Smith
         Phone: [phone]
         Email: [e-mail]

         Editor: David Partain
         Phone: [phone]
         Email: [e-mail]

         Editor: John Seligson
         Phone: [phone]
         Email: [e-mail]"

    DESCRIPTION
        "The COPS Client MIB module"

    REVISION    "200009280000Z"
    DESCRIPTION "This version published as RFC 2940"

    ::= { mib-2 89 }

copsClientMIBObjects OBJECT IDENTIFIER ::= { copsClientMIB 1 }

-- -------------------------------------------------------------
-- Textual Conventions
-- -------------------------------------------------------------

CopsClientState ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "A value indicating the state of a COPS client."
    SYNTAX      INTEGER {
            copsClientInvalid(1),      -- default state.
            copsClientTcpconnected(2), -- TCP connection up but COPS
                                       -- not yet open.



Smith                       Standards Track                     [Page 5]

RFC 2940                    COPS Client MIB                 October 2000


            copsClientAuthenticating(3), -- TCP connection up but still
                                         -- authenticating.
            copsClientSecAccepted(4),  -- connection authenticated.
            copsClientAccepted(5),     -- COPS server accepted client.
            copsClientTimingout(6)     -- Keepalive timer has expired,
                                       -- client is in process of
                                       -- tearing down connection.
    }

CopsServerEntryType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "A value indicating how a COPS server entry came into existence."
    SYNTAX      INTEGER {
            copsServerStatic(1),        -- configured by manager
            copsServerRedirect(2)       -- notified by COPS server
    }

CopsErrorCode ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "A value describing a COPS protocol error. Codes are identical
         to those used by the COPS protocol itself."
    SYNTAX      INTEGER {
            errorOther(0),             -- none of the below
            errorBadHandle(1),
            errorInvalidHandleReference(2),
            errorBadMessageFormat(3),
            errorUnableToProcess(4),
            errorMandatoryClientSiMissing(5),
            errorUnsupportedClientType(6),
            errorMandatoryCopsObjectMissing(7),
            errorClientFailure(8),
            errorCommunicationFailure(9),
            errorUnspecified(10),        -- client-type specific subcode
            errorShuttingDown(11),
            errorRedirectToPreferredServer(12),
            errorUnknownCopsObject(13),
            errorAuthenticationFailure(14),
            errorAuthenticationMissing(15)
    }
--  REFERENCE
--      "RFC 2748 section 2.2.8"

CopsTcpPort ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "A value indicating a TCP protocol port number."



Smith                       Standards Track                     [Page 6]

RFC 2940                    COPS Client MIB                 October 2000


    SYNTAX      INTEGER (0..65535)

CopsAuthType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "A value indicating a type of security authentication mechanism."
    SYNTAX      INTEGER {
        authNone(0),
        authOther(1),
        authIpSecAh(2),
        authIpSecEsp(3),
        authTls(4),
        authCopsIntegrity(5)
    }

-- -------------------------------------------------------------

copsClientCapabilitiesGroup OBJECT IDENTIFIER
                            ::= { copsClientMIBObjects 1 }

-- -------------------------------------------------------------
--
-- Capabilities of the COPS client to connect to a COPS server:
--
copsClientCapabilities OBJECT-TYPE
    SYNTAX      BITS {
        copsClientVersion1(0),     -- supports version1 of COPS protocol
        copsClientAuthIpSecAh(1) , -- supports IP-SEC Authentication
        copsClientAuthIpSecEsp(2), -- supports IP-SEC Encryption
        copsClientAuthTls(3),      -- supports Transport-Layer Security
        copsClientAuthInteg(4)     -- supports COPS Integrity
    }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "A list of the optional capabilities that this COPS client
        supports."