GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2940

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: +1 408 579 2821
       Email: ah_smith@pacbell.net
              Mark Stevens (WG co-chair)
       Phone: +1 978 287 9102
       Email: markstevens@lucent.com
       Editor: Andrew Smith
       Phone: +1 408 579 2821
       Email: ah_smith@pacbell.net
       Editor: David Partain
       Phone: +46 13 28 41 44
       Email: David.Partain@ericsson.com
       Editor: John Seligson
       Phone: +1 408 495 2992
       Email: jseligso@nortelnetworks.com"
  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."
  ::= { copsClientCapabilitiesGroup 1 }

– ————————————————————-

copsClientStatusGroup OBJECT IDENTIFIER ::= { copsClientMIBObjects 2 }

– ————————————————————- – – Current status of COPS server connections, all read-only. –

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

copsClientServerCurrentTable OBJECT-TYPE

  SYNTAX      SEQUENCE OF CopsClientServerCurrentEntry
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "A table of information regarding COPS servers as seen from the
      point of view of a COPS client. This table contains entries
      for both statically-configured and dynamically-learned servers
      (from a PDP Redirect operation). One entry exists in this table
      for each COPS Client-Type served by the COPS server. In addition,
      an entry will exist with copsClientServerClientType 0 (zero)
      representing information about the underlying connection itself:
      this is consistent with the COPS specification which reserves
      this value for this purpose."
  ::= { copsClientStatusGroup 1 }

copsClientServerCurrentEntry OBJECT-TYPE

  SYNTAX      CopsClientServerCurrentEntry
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "A set of information regarding a single COPS server serving
      a single COPS Client-Type from the point of view of a COPS
      client."
  INDEX { copsClientServerAddressType, copsClientServerAddress,
          copsClientServerClientType }
  ::= { copsClientServerCurrentTable 1 }

CopsClientServerCurrentEntry ::=

  SEQUENCE {
      copsClientServerAddressType         InetAddressType,
      copsClientServerAddress             InetAddress,
      copsClientServerClientType          INTEGER,
      copsClientServerTcpPort             CopsTcpPort,
      copsClientServerType                CopsServerEntryType,
      copsClientServerAuthType            CopsAuthType,
      copsClientServerLastConnAttempt     TimeStamp,
      copsClientState                     CopsClientState,
      copsClientServerKeepaliveTime       TimeInterval,
      copsClientServerAccountingTime      TimeInterval,
      copsClientInPkts                    Counter32,
      copsClientOutPkts                   Counter32,
      copsClientInErrs                    Counter32,
      copsClientLastError                 CopsErrorCode,
      copsClientTcpConnectAttempts        Counter32,
      copsClientTcpConnectFailures        Counter32,
      copsClientOpenAttempts              Counter32,

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

      copsClientOpenFailures              Counter32,
      copsClientErrUnsupportClienttype    Counter32,
      copsClientErrUnsupportedVersion     Counter32,
      copsClientErrLengthMismatch         Counter32,
      copsClientErrUnknownOpcode          Counter32,
      copsClientErrUnknownCnum            Counter32,
      copsClientErrBadCtype               Counter32,
      copsClientErrBadSends               Counter32,
      copsClientErrWrongObjects           Counter32,
      copsClientErrWrongOpcode            Counter32,
      copsClientKaTimedoutClients         Counter32,
      copsClientErrAuthFailures           Counter32,
      copsClientErrAuthMissing            Counter32
  }

copsClientServerAddressType OBJECT-TYPE

  SYNTAX      InetAddressType
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "The type of address in copsClientServerAddress."
  ::= { copsClientServerCurrentEntry 1 }

copsClientServerAddress OBJECT-TYPE

  SYNTAX      InetAddress
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "The IPv4, IPv6 or DNS address of a COPS Server. Note that,
      since this is an index to the table, the DNS name must be
      short enough to fit into the maximum length of indices allowed
      by the management protocol in use."
  REFERENCE
      "RFC 2748 section 2.3"
  ::= { copsClientServerCurrentEntry 2 }

copsClientServerClientType OBJECT-TYPE

  SYNTAX      INTEGER (0..65535)
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "The COPS protocol Client-Type for which this entry
      applies. Multiple Client-Types can be served by a single
      COPS server. The value 0 (zero) indicates that this
      entry contains information about the underlying connection
      itself."
  REFERENCE
      "RFC 2748 section 6, IANA"

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

  ::= { copsClientServerCurrentEntry 3 }

copsClientServerTcpPort OBJECT-TYPE

  SYNTAX      CopsTcpPort
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "The TCP port number on the COPS server to which the
      client should connect/is connected."
  ::= { copsClientServerCurrentEntry 4 }

copsClientServerType OBJECT-TYPE

  SYNTAX      CopsServerEntryType
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "Indicator of the source of this COPS server information.
      COPS servers may be configured by network management
      into copsClientServerConfigTable and appear in this entry
      with type copsServerStatic(1). Alternatively, the may be
      notified from another COPS server by means of the COPS
      PDP-Redirect mechanism and appear as copsServerRedirect(2)."
  ::= { copsClientServerCurrentEntry 5 }

copsClientServerAuthType OBJECT-TYPE

  SYNTAX      CopsAuthType
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "Indicator of the current security mode in use between
      client and this COPS server."
  ::= { copsClientServerCurrentEntry 6 }

copsClientServerLastConnAttempt OBJECT-TYPE

  SYNTAX      TimeStamp
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "Timestamp of the last time that this client attempted to
      connect to this COPS server."
  ::= { copsClientServerCurrentEntry 7 }

copsClientState OBJECT-TYPE

  SYNTAX      CopsClientState
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "The state of the connection and COPS protocol with respect

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

      to this COPS server."
  ::= { copsClientServerCurrentEntry 8 }

copsClientServerKeepaliveTime OBJECT-TYPE

  SYNTAX      TimeInterval
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "The value of the COPS protocol Keepalive timeout, in
      centiseconds, currently in use by this client, as
      specified by this COPS server in the Client-Accept operation.
      A value of zero indicates no keepalive activity is expected."
  REFERENCE
      "RFC 2748 section 3.7, 4.4"
  ::= { copsClientServerCurrentEntry 9 }

copsClientServerAccountingTime OBJECT-TYPE

  SYNTAX      TimeInterval
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "The value of the COPS protocol Accounting timeout, in
      centiseconds, currently in use by this client, as specified
      by the COPS server in the Client-Accept operation. A value
      of zero indicates no accounting activity is to be performed."
  REFERENCE
      "RFC 2748 section 3.7"
  ::= { copsClientServerCurrentEntry 10 }

copsClientInPkts OBJECT-TYPE

  SYNTAX      Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      has received from this COPS server marked for this Client-Type.
      This value is cumulative since agent restart and is not zeroed
      on new connections."
  ::= { copsClientServerCurrentEntry 11 }

copsClientOutPkts OBJECT-TYPE

  SYNTAX      Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      has sent to this COPS server marked for this Client-Type. This
      value is cumulative since agent restart and is not zeroed on new

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

      connections."
  ::= { copsClientServerCurrentEntry 12 }

copsClientInErrs OBJECT-TYPE

  SYNTAX      Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      has received from this COPS server marked for this Client-Type
      that contained errors in syntax. This value is cumulative since
      agent restart and is not zeroed on new connections."
  ::= { copsClientServerCurrentEntry 13 }

copsClientLastError OBJECT-TYPE

  SYNTAX      CopsErrorCode
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "The code contained in the last COPS protocol Error Object
      received by this client from this COPS server marked for this
      Client-Type. This value is not zeroed on COPS Client-Open
      operations."
  REFERENCE
      "RFC 2748 section 2.2.8"
  ::= { copsClientServerCurrentEntry 14 }

copsClientTcpConnectAttempts OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the number of times that this COPS client has tried
      (successfully or otherwise) to open an TCP connection to a COPS
      server. This value is cumulative  since agent restart and is not
      zeroed on new connections. This value is not incremented for
      entries representing a non-zero Client-Type."
  ::= { copsClientServerCurrentEntry 15 }

copsClientTcpConnectFailures OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the number of times that this COPS client has failed
      to open an TCP connection to a COPS server. This value is
      cumulative since agent restart and is not zeroed on new
      connections. This value is not incremented for

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

      entries representing a non-zero Client-Type."
  ::= { copsClientServerCurrentEntry 16 }

copsClientOpenAttempts OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the number of times that this COPS client has tried
      to perform a COPS Client-Open to a COPS server for this
      Client-Type. This value is cumulative since agent restart and is
      not zeroed on new connections."
  ::= { copsClientServerCurrentEntry 17 }

copsClientOpenFailures OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the number of times that this COPS client has failed
      to perform a COPS Client-Open to a COPS server for this
      Client-Type. This value is cumulative since agent restart and is
      not zeroed on new connections."
  ::= { copsClientServerCurrentEntry 18 }

copsClientErrUnsupportClienttype OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      has received from COPS servers that referred to Client-Types
      that are unsupported by this client. This value is cumulative
      since agent restart and is not zeroed on new connections. This
      value is not incremented for entries representing a non-zero
      Client-Type."
  ::= { copsClientServerCurrentEntry 19 }

copsClientErrUnsupportedVersion OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      has received from COPS servers marked for this Client-Type that
      had a COPS protocol Version number that is unsupported by this
      client. This value is cumulative since agent restart and is not
      zeroed on new connections."

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

  ::= { copsClientServerCurrentEntry 20 }

copsClientErrLengthMismatch OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      has received from COPS servers marked for this Client-Type that
      had a COPS protocol Message Length that did not match the actual
      received message. This value is cumulative since agent restart
      and is not zeroed on new connections."
  ::= { copsClientServerCurrentEntry 21 }

copsClientErrUnknownOpcode OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      has received from COPS servers marked for this Client-Type that
      had a COPS protocol Op Code that was unrecognised by this
      client. This value is cumulative since agent restart and is not
      zeroed on new connections."
  ::= { copsClientServerCurrentEntry 22 }

copsClientErrUnknownCnum OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      has received from COPS servers marked for this Client-Type that
      contained a COPS protocol object C-Num that was unrecognised by
      this client. This value is cumulative since agent restart and is
      not zeroed on new connections."
  ::= { copsClientServerCurrentEntry 23 }

copsClientErrBadCtype OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      has received from COPS servers marked for this Client-Type that
      contained a COPS protocol object C-Type that was not defined for
      the C-Nums known by this client. This value is cumulative since
      agent restart and is not zeroed on new connections."

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

  ::= { copsClientServerCurrentEntry 24 }

copsClientErrBadSends OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      attempted to send to COPS servers marked for this Client-Type
      that resulted in a transmit error. This value is cumulative
      since agent restart and is not zeroed on new connections."
  ::= { copsClientServerCurrentEntry 25 }

copsClientErrWrongObjects OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      has received from COPS servers marked for this Client-Type that
      did not contain a permitted set of COPS protocol objects. This
      value is cumulative since agent restart and is not zeroed on new
      connections."
  ::= { copsClientServerCurrentEntry 26 }

copsClientErrWrongOpcode OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of COPS messages that this client
      has received from COPS servers marked for this Client-Type that
      had a COPS protocol Op Code that should not have been sent to a
      COPS client e.g. Open-Requests. This value is cumulative since
      agent restart and is not zeroed on new connections."
  ::= { copsClientServerCurrentEntry 27 }

copsClientKaTimedoutClients OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of times that this client has
      been shut down for this Client-Type by COPS servers that had
      detected a COPS protocol Keepalive timeout. This value is
      cumulative since agent restart and is not zeroed on new
      connections."
  ::= { copsClientServerCurrentEntry 28 }

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

copsClientErrAuthFailures OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of times that this client has
      received a COPS message marked for this Client-Type which
      could not be authenticated using the authentication mechanism
      used by this client."
  ::= { copsClientServerCurrentEntry 29 }

copsClientErrAuthMissing OBJECT-TYPE

  SYNTAX     Counter32
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A count of the total number of times that this client has
      received a COPS message marked for this Client-Type which did not
      contain authentication information."
  ::= { copsClientServerCurrentEntry 30 }

– ————————————————————-

copsClientConfigGroup OBJECT IDENTIFIER ::= { copsClientMIBObjects 3 }

– ————————————————————-

copsClientServerConfigTable OBJECT-TYPE

   SYNTAX      SEQUENCE OF CopsClientServerConfigEntry
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "Table of possible COPS servers to try to connect to in order
      of copsClientServerConfigPriority. There may be multiple
      entries in this table for the same server and client-type which
      specify different security mechanisms: these mechanisms will
      be attempted by the client in the priority order given. Note
      that a server learned by means of PDPRedirect always takes
      priority over any of these configured entries."
  ::= { copsClientConfigGroup 1 }

copsClientServerConfigEntry OBJECT-TYPE

  SYNTAX      CopsClientServerConfigEntry
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "A set of configuration information regarding a single

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

      COPS server from the point of view of a COPS client."
  INDEX { copsClientServerConfigAddrType,
          copsClientServerConfigAddress,
          copsClientServerConfigClientType,
          copsClientServerConfigAuthType }
  ::= { copsClientServerConfigTable 1 }

CopsClientServerConfigEntry ::=

  SEQUENCE {
      copsClientServerConfigAddrType      InetAddressType,
      copsClientServerConfigAddress       InetAddress,
      copsClientServerConfigClientType    INTEGER,
      copsClientServerConfigAuthType      CopsAuthType,
      copsClientServerConfigTcpPort       CopsTcpPort,
      copsClientServerConfigPriority      Integer32,
      copsClientServerConfigRowStatus     RowStatus
  }

copsClientServerConfigAddrType OBJECT-TYPE

  SYNTAX      InetAddressType
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "The type of address in copsClientServerConfigAddress."
  ::= { copsClientServerConfigEntry 1 }

copsClientServerConfigAddress OBJECT-TYPE

  SYNTAX      InetAddress
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "The IPv4, IPv6 or DNS address of a COPS Server. Note that,
      since this is an index to the table, the DNS name must be
      short enough to fit into the maximum length of indices allowed
      by the management protocol in use."
  REFERENCE
      "RFC 2748 section 2.3"
  ::= { copsClientServerConfigEntry 2 }

copsClientServerConfigClientType OBJECT-TYPE

  SYNTAX      INTEGER (0..65535)
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "The COPS protocol Client-Type for which this entry
      applies and for which this COPS server is capable
      of serving. Multiple Client-Types can be served by a
      single COPS server."

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

  REFERENCE
      "RFC 2748 section 6, IANA"
  ::= { copsClientServerConfigEntry 3 }

copsClientServerConfigAuthType OBJECT-TYPE

  SYNTAX      CopsAuthType
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "The type of authentication mechanism for this COPS client
      to request when negotiating security at the start of a
      connection to a COPS server."
  REFERENCE
      "RFC 2748 section 4."
  ::= { copsClientServerConfigEntry 4 }

copsClientServerConfigTcpPort OBJECT-TYPE

  SYNTAX      CopsTcpPort
  MAX-ACCESS  read-create
  STATUS      current
  DESCRIPTION
      "The TCP port number on the COPS server to which the
      client should connect."
  ::= { copsClientServerConfigEntry 5 }

copsClientServerConfigPriority OBJECT-TYPE

  SYNTAX      Integer32
  MAX-ACCESS  read-create
  STATUS      current
  DESCRIPTION
      "The priority of this entry relative to other entries.
      COPS client will attempt to contact COPS servers for the
      appropriate Client-Type. Higher numbers are tried first. The
      order to be used amongst server entries with the same priority
      is undefined. COPS servers that are notified to the client using
      the COPS protocol PDP-Redirect mechanism are always used in
      preference to any entries in this table."
  ::= { copsClientServerConfigEntry 6 }

copsClientServerConfigRowStatus OBJECT-TYPE

  SYNTAX      RowStatus
  MAX-ACCESS  read-create
  STATUS      current
  DESCRIPTION
      "State of this entry in the table."
  ::= { copsClientServerConfigEntry 7 }

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

copsClientServerConfigRetryAlgrm OBJECT-TYPE

  SYNTAX      INTEGER {
                  other(1),
                  sequential(2),
                  roundRobin(3)
              }
  MAX-ACCESS  read-write
  STATUS      current
  DESCRIPTION
      "The algorithm by which the client should retry when it
       fails to connect to a COPS server."
  DEFVAL { sequential }
  ::= { copsClientConfigGroup 2 }

copsClientServerConfigRetryCount OBJECT-TYPE

  SYNTAX      Unsigned32
  MAX-ACCESS  read-write
  STATUS      current
  DESCRIPTION
      "A retry count for use by the retry algorithm.  Each retry
       algorithm needs to specify how it uses this value.
       For the 'sequential(2)' algorithm, this value is the
       number of times the client should retry to connect
       to one COPS server before moving on to another.
       For the 'roundRobin(3)' algorithm, this value is not used."
  DEFVAL { 1 }
  ::= { copsClientConfigGroup 3 }

copsClientServerConfigRetryIntvl OBJECT-TYPE

  SYNTAX      TimeInterval
  UNITS       "centi-seconds"
  MAX-ACCESS  read-write
  STATUS      current
  DESCRIPTION
      "A retry interval for use by the retry algorithm.  Each retry
       algorithm needs to specify how it uses this value.
       For the 'sequential(2)' algorithm, this value is the time to
       wait between retries of a connection to the same COPS server.
       For the 'roundRobin(3)' algorithm, the client always attempts
       to connect to each Server in turn, until one succeeds or they
       all fail; if they all fail, then the client waits for the value
       of this interval before restarting the algorithm."
  DEFVAL { 1000 }
  ::= { copsClientConfigGroup 4 }

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

– ————————————————————- – Conformance Information – ————————————————————-

copsClientConformance OBJECT IDENTIFIER ::= { copsClientMIB 2 }

copsClientGroups OBJECT IDENTIFIER ::= { copsClientConformance 1 } copsClientCompliances OBJECT IDENTIFIER ::= { copsClientConformance 2 }

– ————————————————————- – units of conformance – ————————————————————-

copsDeviceStatusGroup OBJECT-GROUP

  OBJECTS {
      copsClientCapabilities,
      copsClientServerTcpPort, copsClientServerType,
      copsClientServerAuthType, copsClientServerLastConnAttempt,
      copsClientState, copsClientServerKeepaliveTime,
      copsClientServerAccountingTime, copsClientInPkts,
      copsClientOutPkts, copsClientInErrs, copsClientLastError,
      copsClientTcpConnectAttempts, copsClientTcpConnectFailures,
      copsClientOpenAttempts, copsClientOpenFailures,
      copsClientErrUnsupportClienttype,
      copsClientErrUnsupportedVersion, copsClientErrLengthMismatch,
      copsClientErrUnknownOpcode, copsClientErrUnknownCnum,
      copsClientErrBadCtype, copsClientErrBadSends,
      copsClientErrWrongObjects, copsClientErrWrongOpcode,
      copsClientKaTimedoutClients, copsClientErrAuthFailures,
      copsClientErrAuthMissing
  }
  STATUS      current
  DESCRIPTION
      "A collection of objects for monitoring the status of
      connections to COPS servers and statistics for a COPS client."
  ::= { copsClientGroups 1 }

copsDeviceConfigGroup OBJECT-GROUP

  OBJECTS {
      copsClientServerConfigTcpPort, copsClientServerConfigPriority,
      copsClientServerConfigRowStatus,
      copsClientServerConfigRetryAlgrm,
      copsClientServerConfigRetryCount,
      copsClientServerConfigRetryIntvl
  }
  STATUS      current
  DESCRIPTION
      "A collection of objects for configuring COPS server

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

      information."
  ::= { copsClientGroups 2 }

– ————————————————————- – compliance statements – ————————————————————-

copsClientCompliance MODULE-COMPLIANCE

  STATUS  current
  DESCRIPTION
      "The compliance statement for device support of
      management of the COPS client."
  MODULE
      MANDATORY-GROUPS {
          copsDeviceStatusGroup, copsDeviceConfigGroup
      }
      OBJECT      copsClientServerConfigTcpPort
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is required only if the device supports the
          configuration of COPS server information."
      OBJECT      copsClientServerConfigPriority
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is required only if the device supports the
          configuration of COPS server information."
      OBJECT      copsClientServerConfigRowStatus
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is required only if the device supports the
          configuration of COPS server information."
      OBJECT      copsClientServerConfigRetryAlgrm
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is required only if the device supports the
          configuration of COPS server information."
      OBJECT      copsClientServerConfigRetryCount
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is required only if the device supports the
          configuration of COPS server information."

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

      OBJECT      copsClientServerConfigRetryIntvl
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is required only if the device supports the
          configuration of COPS server information."
     ::= { copsClientCompliances 1 }

END

5. Acknowledgments

 This document describes instrumentation for the client side of the
 COPS protocol which was defined by the RSVP Admission Policy (rap)
 Working Group, now known as the Resource Allocation Protocol (rap)
 Working Group.

6. Security Considerations

 There are a number of management objects defined in this MIB that
 have a MAX-ACCESS clause of read-create.  Such objects may be
 considered sensitive or vulnerable in some network environments.  The
 support for SET operations in a non-secure environment without proper
 protection can have a negative effect on network operations.
 SNMPv1 by itself is not a secure environment.  Even if the network
 itself is secure (for example by using IPSec), even then, there is no
 control as to who on the secure network is allowed to access and
 GET/SET (read/change/create/delete) the objects in this MIB.
 It is recommended that the implementers consider the security
 features as provided by the SNMPv3 framework.  Specifically, the use
 of the User-based Security Model [USM] and the View-based Access
 Control Model [VACM] is recommended.
 It is then a customer/user responsibility to ensure that the SNMP
 entity giving access to an instance of this MIB, is properly
 configured to give access to the objects only to those principals
 (users) that have legitimate rights to indeed GET or SET
 (change/create/delete) them.

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

7. References

 [ARCH]        Harrington, D., Presuhn, R. and B. Wijnen, "An
               Architecture for Describing SNMP Management
               Frameworks", RFC 2571, April 1999.
 [V1PROTO]     Case, J., Fedor, M., Schoffstall, M. and J. Davin,
               "Simple Network Management Protocol", STD 15, RFC 1157,
               May 1990.
 [V1SMI]       Rose, M. and K. McCloghrie, "Structure and
               Identification of Management Information for TCP/IP-
               based Internets", STD 16, RFC 1155, May 1990.
 [V1CONCISE]   Rose, M. and K. McCloghrie, "Concise MIB Definitions",
               STD 16, RFC 1212, March 1991.
 [V1TRAPS]     Rose, M., "A Convention for Defining Traps for use with
               the SNMP", RFC 1215, March 1991.
 [V2SMI]       McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
               J., Rose, M. and S. Waldbusser, "Structure of
               Management Information Version 2 (SMIv2)", STD 58, RFC
               2578, April 1999.
 [V2TC]        McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
               J., Rose, M. and S. Waldbusser, "Textual Conventions
               for SMIv2", STD 58, RFC 2579, April 1999.
 [V2CONFORM]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
               J., Rose, M. and S. Waldbusser, "Conformance Statements
               for SMIv2", STD 58, RFC 2580, April 1999.
 [V2COMMUNITY] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
               "Introduction to Community-based SNMPv2", RFC 1901,
               January 1996.
 [V2TRANS]     Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
               "Transport Mappings for Version 2 of the Simple Network
               Management Protocol (SNMPv2)", RFC 1906, January 1996.
 [V2PROTO]     Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
               "Protocol Operations for Version 2 of the Simple
               Network Management Protocol (SNMPv2)", RFC 1905,
               January 1996.

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

 [V3INTRO]     Case, J., Mundy, R., Partain, D. and B. Stewart,
               "Introduction to Version 3 of the Internet-standard
               Network Management Framework", RFC 2570, April 1999.
 [V3MPC]       Case, J., Harrington D., Presuhn R. and B. Wijnen,
               "Message Processing and Dispatching for the Simple
               Network Management Protocol (SNMP)", RFC 2572, April
               1999.
 [V3USM]       Blumenthal, U. and B. Wijnen, "The User-Based Security
               Model (USM) for Version 3 of the Simple Network
               Management Protocol (SNMPv3)", RFC 2574, April 1999.
 [V3APPS]      Levi, D., Meyer, P. and B. Stewart, "SNMP
               Applications", RFC 2573, April 1999.
 [V3VACM]      Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model for the Simple Network Management
               Protocol (SNMP)", RFC 2575, April 1999.
 [MIB2]        McCloghrie K. and M. Rose, "Management Information Base
               for Network Management of TCP/IP-based internets", STD
               17, RFC 1213, March 1991.
 [FRAMEWORK]   Yavatkar, R., Pendarakis, D. and Guerin, R., "A
               Framework for Policy-based Admission Control", RFC
               2753, January 2000.
 [COPS]        Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
               and A. Sastry, "The COPS (Common Open Policy Service)
               Protocol", RFC 2748, January 2000.
 [RSVP]        Braden, R. ed., Zhang, L., Berson, S., Herzog, S. and
               S.  Jamin, "Resource ReSerVation Protocol (RSVP)
               Version 1 - Functional Specification", RFC 2205,
               September 1997.
 [COPSRSVP]    Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
               and A. Sastry, "COPS Usage for RSVP", RFC 2749, January
               2000.
 [SRVLOC]      Guttman, E., Perkins, C., Veizades, J. and M. Day,
               "Service Location Protocol, Version 2", RFC 2608, June
               1999.
 [ADDRESSMIB]  Daniele, M., Haberman, B., Routhier, S. and J.
               Schoenwaelder, "Textual Conventions for Internet
               Network Addresses", RFC 2851, June 2000.

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

 [PROCESS]     Bradner, S., "The Internet Standards Process --
               Revision 3", BCP 9, RFC 2026, October 1996.

8. Authors' Addresses

 Andrew Smith
 Fax:  +1 415 345 1827
 Email: ah_smith@pacbell.net
 David Partain
 Ericsson Radio Systems
 Research and Innovation
 P.O. Box 1248
 SE-581 12 Linkoping
 Sweden
 Phone: +46 13 28 41 44
 EMail: David.Partain@ericsson.com
 John Seligson
 Nortel Networks, Inc.
 4401 Great America Parkway
 Santa Clara, CA 95054
 USA
 Phone: +1 408 495 2992
 EMail: jseligso@nortelnetworks.com

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

9. Notices

 The IETF takes no position regarding the validity or scope of any
 intellectual property or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; neither does it represent that it
 has made any effort to identify any such rights.  Information on the
 IETF's procedures with respect to rights in standards-track and
 standards-related documentation can be found in BCP-11.  Copies of
 claims of rights made available for publication and any assurances of
 licenses to be made available, or the result of an attempt made to
 obtain a general license or permission for the use of such
 proprietary rights by implementors or users of this specification can
 be obtained from the IETF Secretariat.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights which may cover technology that may be required to practice
 this standard.  Please address the information to the IETF Executive
 Director.

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

10. Full Copyright Statement

 Copyright (C) The Internet Society (2000).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Smith Standards Track [Page 27]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2940.txt · Last modified: 2000/10/05 16:40 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki