<pre>Network Working Group                                     R. Steinberger
Request for Comments: 3201                             Paradyne Networks
Category: Standards Track                                    O. Nicklass
                                            RAD Data Communications Ltd.
                                                            January 2002


                     <span class="h1">Definitions of Managed Objects</span>
                  <span class="h1">for Circuit to Interface Translation</span>

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 (2002).  All Rights Reserved.

Abstract

   This memo defines an extension of the Management Information Base
   (MIB) for use with network management protocols in TCP/IP-based
   internets.  In particular, it defines objects for managing the
   insertion of interesting Circuit Interfaces into the ifTable.  This
   is important for circuits that must be used within other MIB modules
   which require an ifEntry.  It allows for integrated monitoring of
   circuits as well as routing to circuits using unaltered, pre-existing
   MIB modules.

Table of Contents

   <a href="#section-1">1</a>. The SNMP Management Framework ...............................    <a href="#page-2">2</a>
   <a href="#section-2">2</a>. Conventions .................................................    <a href="#page-3">3</a>
   <a href="#section-3">3</a>. Overview ....................................................    <a href="#page-3">3</a>
   <a href="#section-3.1">3.1</a>. Circuit Concepts ..........................................    <a href="#page-4">4</a>
   <a href="#section-3.2">3.2</a>. Theory of Operation .......................................    <a href="#page-4">4</a>
   <a href="#section-3.2.1">3.2.1</a>. Creation Process ........................................    <a href="#page-4">4</a>
   <a href="#section-3.2.2">3.2.2</a>. Destruction Process .....................................    <a href="#page-5">5</a>
   <a href="#section-3.2.2.1">3.2.2.1</a>. Manual Row Destruction ................................    <a href="#page-5">5</a>
   <a href="#section-3.2.2.2">3.2.2.2</a>. Automatic Row Destruction .............................    <a href="#page-5">5</a>
   <a href="#section-3.2.3">3.2.3</a>. Modification Process ....................................    <a href="#page-5">5</a>
   <a href="#section-3.2.4">3.2.4</a>. Persistence of Data .....................................    <a href="#page-5">5</a>
   <a href="#section-4">4</a>. Relation to Other MIB Modules ...............................    <a href="#page-6">6</a>
   <a href="#section-4.1">4.1</a>. Frame Relay DTE MIB .......................................    <a href="#page-6">6</a>



<span class="grey">Steinberger &amp; Nicklass      Standards Track                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


   <a href="#section-4.2">4.2</a>. Frame Relay Service MIB ...................................    <a href="#page-6">6</a>
   <a href="#section-4.3">4.3</a>. ATM MIB ...................................................    <a href="#page-6">6</a>
   <a href="#section-4.4">4.4</a>. Interfaces Group MIB ......................................    <a href="#page-6">6</a>
   <a href="#section-4.4.1">4.4.1</a>. Interfaces Table (ifTable, ifXtable) ....................    <a href="#page-6">6</a>
   <a href="#section-4.4.2">4.4.2</a>. Stack Table (ifStackTable) ..............................    <a href="#page-9">9</a>
   <a href="#section-4.5">4.5</a>. Other MIB Modules .........................................   <a href="#page-11">11</a>
   <a href="#section-5">5</a>. Structure of the MIB Module .................................   <a href="#page-11">11</a>
   <a href="#section-5.1">5.1</a>. ciCircuitTable ............................................   <a href="#page-11">11</a>
   <a href="#section-5.2">5.2</a>. ciIfMapTable ..............................................   <a href="#page-11">11</a>
   <a href="#section-6">6</a>. Object Definitions ..........................................   <a href="#page-11">11</a>
   <a href="#section-7">7</a>. Acknowledgments .............................................   <a href="#page-19">19</a>
   <a href="#section-8">8</a>. References ..................................................   <a href="#page-19">19</a>
   <a href="#section-9">9</a>. Security Considerations .....................................   <a href="#page-21">21</a>
   <a href="#section-10">10</a>. IANA Considerations ........................................   <a href="#page-21">21</a>
   <a href="#section-11">11</a>. Authors' Addresses .........................................   <a href="#page-22">22</a>
   <a href="#section-12">12</a>. Full Copyright Statement ...................................   <a href="#page-23">23</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  The SNMP Management Framework</span>

   The SNMP Management Framework presently consists of five major
   components:

   o  An overall architecture, described in <a href="./rfc2571">RFC 2571</a> [<a href="#ref-1" title="&quot;An Architecture for Describing SNMP Management Frameworks&quot;">1</a>].

   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, <a href="./rfc1155">RFC 1155</a> [<a href="#ref-2" title="&quot;Structure and Identification of Management Information for TCP/IP-based Internets&quot;">2</a>], STD 16, <a href="./rfc1212">RFC 1212</a> [<a href="#ref-3" title="&quot;Concise MIB Definitions&quot;">3</a>] and <a href="./rfc1215">RFC 1215</a> [<a href="#ref-4" title="&quot;A Convention for Defining Traps for use with the SNMP&quot;">4</a>].  The
      second version, called SMIv2, is described in STD 58, <a href="./rfc2578">RFC 2578</a>
      [<a href="#ref-5" title="&quot;Structure of Management Information Version 2 (SMIv2)&quot;">5</a>], <a href="./rfc2579">RFC 2579</a> [<a href="#ref-6" title="&quot;Textual Conventions for SMIv2&quot;">6</a>] and <a href="./rfc2580">RFC 2580</a> [<a href="#ref-7" title="&quot;Conformance Statements for SMIv2&quot;">7</a>].

   o  Message protocols for transferring management information.  The
      first version of the SNMP message protocol is called SNMPv1 and
      described in STD 15, <a href="./rfc1157">RFC 1157</a> [<a href="#ref-8" title="&quot;Simple Network Management Protocol&quot;">8</a>].  A second version of the SNMP
      message protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in <a href="./rfc1901">RFC 1901</a> [<a href="#ref-9" title="&quot;Introduction to Community-based SNMPv2&quot;">9</a>] and <a href="./rfc1906">RFC</a>
      <a href="./rfc1906">1906</a> [<a href="#ref-10" title="&quot;Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)&quot;">10</a>].  The third version of the message protocol is called
      SNMPv3 and described in <a href="./rfc1906">RFC 1906</a> [<a href="#ref-10" title="&quot;Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)&quot;">10</a>], <a href="./rfc2572">RFC 2572</a> [<a href="#ref-11" title="&quot;Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)&quot;">11</a>] and <a href="./rfc2574">RFC 2574</a>
      [<a href="#ref-12" title="&quot;User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)&quot;">12</a>].

   o  Protocol operations for accessing management information.  The
      first set of protocol operations and associated PDU formats is
      described in STD 15, <a href="./rfc1157">RFC 1157</a> [<a href="#ref-8" title="&quot;Simple Network Management Protocol&quot;">8</a>].  A second set of protocol
      operations and associated PDU formats is described in <a href="./rfc1905">RFC 1905</a>
      [<a href="#ref-13" title="&quot;Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)&quot;">13</a>].






<span class="grey">Steinberger &amp; Nicklass      Standards Track                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


   o  A set of fundamental applications described in <a href="./rfc2573">RFC 2573</a> [<a href="#ref-14" title="&quot;SNMPv3 Applications&quot;">14</a>] and
      the view-based access control mechanism described in <a href="./rfc2575">RFC 2575</a>
      [<a href="#ref-15" title="&quot;View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)&quot;">15</a>].

   A more detailed introduction to the current SNMP Management Framework
   can be found in <a href="./rfc2570">RFC 2570</a> [<a href="#ref-16" title="&quot;Introduction to Version 3 of the Internet-standard Network Management Framework&quot;">16</a>].

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

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Conventions</span>

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   <a href="./rfc2119">RFC 2119</a> [<a href="#ref-21" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">21</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Overview</span>

   This MIB module addresses the concept of inserting circuits, which
   are potentially virtual, into the ifTable.  There are multiple
   reasons to allow circuits to be added to the ifTable.  The most
   prevalent of which are the standard routing MIB tables such as the
   ipCidrRouteTable (IP-FORWARD-MIB) and the ipNetToMediaTable (IP-MIB)
   act on the ifIndex and the RMON MIBs (RMON-MIB and RMON2-MIB as
   defined in <a href="./rfc2819">RFC 2819</a> [<a href="#ref-23" title="&quot;Remote Network Monitoring Management Information Base&quot;">23</a>] and <a href="./rfc2021">RFC 2021</a> [<a href="#ref-19" title="&quot;Remote Network Monitoring Management Information Base Version 2 using SMIv2&quot;">19</a>]) require the use of an
   ifIndex a DataSource.

   There is a further need to potentially monitor or manage a circuit
   based on the directional flow of traffic going through it.  For
   instance, monitoring of protocols passed on a circuit using RMON-II
   (<a href="./rfc2021">RFC 2021</a> [<a href="#ref-19" title="&quot;Remote Network Monitoring Management Information Base Version 2 using SMIv2&quot;">19</a>]) does not currently capture the direction of the flow.
   This MIB module provides the capability to define an interface based
   on the specific direction of the flow.

   This section provides an overview and background of how to use this
   MIB module.



<span class="grey">Steinberger &amp; Nicklass      Standards Track                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Circuit Concepts</span>

   There are multiple MIB modules that define circuits.  Three commonly
   used MIB modules are FRAME-RELAY-DTE-MIB (<a href="./rfc2115">RFC 2115</a>) [<a href="#ref-20" title="&quot;Management Information Base for Frame Relay DTEs Using SMIv2&quot;">20</a>], FRNETSERV-
   MIB (<a href="./rfc2954">RFC 2954</a>) [<a href="#ref-18" title="&quot;Definitions of Managed Objects for Frame Relay Service&quot;">18</a>], and ATM-MIB (<a href="./rfc2515">RFC 2515</a>) [<a href="#ref-22" title="&quot;Definitions of Managed Objects for ATM Management&quot;">22</a>].  These define
   management objects for frame relay DTEs, frame relay services, and
   ATM respectively.  Each of these MIB modules contain the ability to
   add or delete circuits;  however, none create a specific ifEntry for
   a circuit.  The reason for this is that there are potentially
   multiple circuits and not every circuit needs to be managed as an
   individual interface.  For example, not every circuit on a device
   needs to be monitored with RMON and not every circuit needs to be
   included as an individual circuit for routing.  Further, the
   Interfaces Group MIB (<a href="./rfc2863">RFC 2863</a>) [<a href="#ref-17" title="&quot;The Interfaces Group MIB&quot;">17</a>] strongly recommends that
   conceptual rows not be added to the ifTable for virtual circuits.

   The rationale for creating conceptual rows in the ifTable for these
   circuits is that there is a need for their use in either management
   of routing or monitoring of data.  Both of these functions require
   mapping to an ifIndex.

   This MIB module is designed such that only those circuits that
   require an ifIndex need be added to the ifTable.  This prevents
   over-populating the ifTable with useless or otherwise unused indices.

   While this document often refers to ATM and frame relay, it is not
   specifically designed for only those types of circuits.  Any circuit
   that is defined in a MIB module but does not have its own ifIndex MAY
   be added with this MIB module.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Theory of Operation</span>

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Creation Process</span>

   In some cases, devices will automatically populate the rows of
   ciCircuitTable as circuits are created or discovered.  However, in
   many cases, it may be necessary for a network manager to manually
   create rows.

   Manual creation of rows requires the following steps:

   1) Locate or create the circuit that is to be added on the device.

   2) Create a row in ciCircuitTable for each flow type that is
      required.

   The first step above requires some knowledge of the circuits that
   exist on a device.  Typically, logical ports have entries in the



<span class="grey">Steinberger &amp; Nicklass      Standards Track                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


   ifTable.  If, for example, the ifType for the logical port is
   frameRelay(32), the circuits can be located in the frCircuitTable of
   the Frame Relay DTE MIB (FRAME-RELAY-DTE-MIB) [<a href="#ref-18" title="&quot;Definitions of Managed Objects for Frame Relay Service&quot;">18</a>].  If, as another
   example, the ifType for the logical port is frameRelayService(44),
   the circuits can be located in the frPVCEndptTable of the Frame Relay
   Service MIB (FRNETSERV-MIB) [<a href="#ref-20" title="&quot;Management Information Base for Frame Relay DTEs Using SMIv2&quot;">20</a>].  If, as a final example, the ifType
   for the logical port is aal5(49), the circuits can be located in the
   aal5VccTable of the ATM MIB (ATM-MIB) [<a href="#ref-22" title="&quot;Definitions of Managed Objects for ATM Management&quot;">22</a>].  An entry describing the
   circuit MUST exist in some table prior to creating a row in
   ciCircuitTable.  The object identifier that MUST be used in the
   circuit definition is the lexicographically smallest accessible OID
   that fully describes the the circuit.

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Destruction Process</span>

<span class="h5"><a class="selflink" id="section-3.2.2.1" href="#section-3.2.2.1">3.2.2.1</a>.  Manual Row Destruction</span>

   Manual row destruction is straight forward.  Any row can be destroyed
   and the resources allocated to it are freed by setting the value of
   its status object (ciCircuitStatus) to destroy(6).  It should be
   noted that when ciCircuitStatus is set to destroy(6) all associated
   rows in the ifTable and in ciIfMapTable will also be destroyed.  This
   process MAY trigger further row destruction in other tables as well.

<span class="h5"><a class="selflink" id="section-3.2.2.2" href="#section-3.2.2.2">3.2.2.2</a>.  Automatic Row Destruction</span>

   Rows in the tables MAY be destroyed automatically based on the
   existence of the circuit on which they rely.  When a circuit no
   longer exists in the device, the data in the tables has no relation
   to anything known on the network.  For this reason, rows MUST be
   removed from this table as soon as it is discovered that the
   associated circuits no longer exist.  The effects of automatic row
   destruction are the same as manual row destruction.

<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>.  Modification Process</span>

   Since no objects in the MIB module can be changed once rows are
   active, there are no modification caveats.

<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>.  Persistence of Data</span>

   Each row in the tables of this MIB module relies on information from
   other MIB modules.  The rules for persistence of the data SHOULD
   follow the same rules as those of the underlying MIB module.  For
   example, if the circuit defined by ciCircuitObject would normally be
   stored in non-volatile memory, then the ciCircuitEntry SHOULD also be
   non-volatile.




<span class="grey">Steinberger &amp; Nicklass      Standards Track                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Relation to Other MIB Modules</span>

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Frame Relay DTE MIB</span>

   There is no required relation to the Frame Relay DTE MIB beyond the
   fact that rows in the frCircuitTable MAY be referenced.  However, if
   frCircuitLogicalIfIndex is being used to represent the same
   information as a ciCircuitEntry with a value of ciCircuitFlow equal
   to both(3), the implementation MAY use the same ifIndex.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Frame Relay Service MIB</span>

   There is no explicit relation to the Frame Relay Service MIB beyond
   the fact that a rows in the frPVCEndptTable MAY be referenced.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  ATM MIB</span>

   There is no explicit relation to the ATM MIB beyond the fact that
   rows in multiple tables may be referenced.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Interfaces Group MIB</span>

<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>.  Interfaces Table (ifTable, ifXtable)</span>

   The following specifies how the Interfaces Group defined in the IF-
   MIB will be used for the management of interfaces created by this MIB
   module.

   Values of specific ifTable objects for circuit interfaces are as
   follows:

   Object Name    Value of Object
   ===========    =====================================================

   ifIndex        Each entry in the circuit table is represented by an
                  ifEntry.  The value of ifIndex is defined by the agent
                  such that it complies with any internal numbering
                  scheme.

   ifType         The value of ifType is specific to the type of circuit
                  desired.  For example, the value for frame relay
                  virtual circuits is frDlciEndPt(193) and the value for
                  ATM virtual circuits is atmVciEndPt(194).  If the
                  circuit is to be used in RMON, propVirtual(53) SHOULD
                  NOT be used.






<span class="grey">Steinberger &amp; Nicklass      Standards Track                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


   ifMtu          Set to the size in octets of the largest packet, frame
                  or PDU supported on the circuit.  If this is not known
                  to the ifMtu object shall be set to zero.  If the
                  circuit is not modeled as a packet-oriented interface,
                  this object SHOULD NOT be supported and result in
                  noSuchInstance.

   ifSpeed        The peak bandwidth in bits per second available for
                  use.  This will equal either the ifSpeed of the
                  logical link if policing is not enforced or the
                  maximum information rate otherwise.  If neither is
                  known, the ifSpeed object shall be set to zero.

   ifPhysAddress  This will always be an octet string of zero length.

   ifInOctets     The number of octets received by the network (ingress)
                  for this circuit.  This counter should count only
                  octets included the header information and user data.
                  If the device does not support statistics on the
                  circuit, this object MUST NOT be supported and result
                  in noSuchInstance.

   ifInUcastPkts  The unerrored number of frames, packets or PDUs
                  received by the network (ingress) for this circuit.
                  If the device does not support statistics on the
                  circuit, this object MUST NOT be supported and result
                  in noSuchInstance.

   ifInDiscards   The number of received frames, packets or PDUs for
                  this circuit discarded due to ingress buffer
                  congestion and traffic policing.  If the device does
                  not support statistics on the circuit, this object
                  MUST NOT be supported and result in noSuchInstance.

   ifInErrors     The number of received frames, packets or PDUs for
                  this circuit that are discarded because of an error.
                  If the device does not support statistics on the
                  circuit, this object MUST NOT be supported and result
                  in noSuchInstance.

   ifOutOctets    The number of octets sent by the network (egress) for
                  this circuit.  This counter should count only octets
                  included the header information and user data.  If the
                  device does not support statistics on the circuit,
                  this object MUST NOT be supported and result in
                  noSuchInstance.





<span class="grey">Steinberger &amp; Nicklass      Standards Track                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


   ifOutUcastpkts The number of unerrored frames, packets or PDUs sent
                  by the network (egress) for this circuit.  If the
                  device does not support statistics on the circuit,
                  this object MUST NOT be supported and result in
                  noSuchInstance.

   ifOutDiscards  The number of frames, packets or PDUs discarded in the
                  egress direction for this circuit.  Possible reasons
                  are as follows: policing, congestion.  If the device
                  does not support statistics on the circuit, this
                  object MUST NOT be supported and result in
                  noSuchInstance.

   ifOutErrors    The number of frames, packets or PDUs discarded for
                  this circuit in the egress direction because of an
                  error.  If the device does not support statistics on
                  the circuit, this object MUST NOT be supported and
                  result in noSuchInstance.

   ifInBroadcastPkts
                  If the device does not support statistics on the
                  circuit, this object MUST NOT be supported and result
                  in noSuchInstance.

   ifOutBroadcastPkts
                  If the device does not support Broadcast packets on
                  the circuit, this object should not be supported and
                  result in noSuchInstance.

   ifLinkUpDownTrapEnable
                  Set to false(2).  Circuits often have a predefined
                  notification mechanism.  In such instances, the number
                  of notification sent would be doubled if this were
                  enabled.

   ifPromiscuousMode
                  Set to false(2).  If the circuit is not modeled as a
                  packet-oriented interface, this object SHOULD NOT be
                  supported and result in noSuchInstance.

   ifConnectorPresent
                  Set to false(2).

   All other values are supported as stated in the IF-MIB documentation.







<span class="grey">Steinberger &amp; Nicklass      Standards Track                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>.  Stack Table (ifStackTable)</span>

   This section describes by example how to use ifStackTable to
   represent the relationship between circuit and logical link
   interfaces.

   Example 1: Circuits (C) on a frame relay logical link.

        +---+  +---+  +---+
        | C |  | C |  | C |
        +-+-+  +-+-+  +-+-+
          |      |      |
      +---+------+------+---+
      | Frame Relay Service |
      +----------+----------+
                 |
      +----------+----------+
      |   Physical Layer    |
      +---------------------+

   The assignment of the index values could for example be (for a V35
   physical interface):

         ifIndex  Description
         =======  ===========
            1     frDlciEndPt       (type 193)
            2     frDlciEndPt       (type 193)
            3     frDlciEndPt       (type 193)
            4     frameRelayService (type 44)
            5     v35               (type 33)

   The ifStackTable is then used to show the relationships between each
   interface.

         HigherLayer   LowerLayer
         ===========   ==========
              0             1
              0             2
              0             3
              1             4
              2             4
              3             4
              4             5
              5             0

   In the above example the frame relay logical link could just as
   easily be of type frameRelay(32) instead.




<span class="grey">Steinberger &amp; Nicklass      Standards Track                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


   Example 2: Circuits (C) on a AAL5 logical link.

           +---+  +---+  +---+
           | C |  | C |  | C |
           +-+-+  +-+-+  +-+-+
             |      |      |
         +---+------+------+---+
         |      AAL5 Layer     |
         +----------+----------+
                    |
         +----------+----------+
         |      ATM Layer      |
         +---------------------+
                    |
         +----------+----------+
         |   Physical Layer    |
         +---------------------+

   The assignment of the index values could for example be (for a DS3
   physical interface):

         ifIndex  Description
         =======  ===========
            1     atmVciEndPt (type 194)
            2     atmVciEndPt (type 194)
            3     atmVciEndPt (type 194)
            4     aal5        (type 49)
            5     atm         (type 37)
            6     ds3         (type 30)

   The ifStackTable is then used to show the relationships between each
   interface.

         HigherLayer   LowerLayer
         ===========   ==========
              0             1
              0             2
              0             3
              1             4
              2             4
              3             4
              4             5
              5             6
              6             0







<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  Other MIB Modules</span>

   There is no explicit relation to any other media specific MIB module
   beyond the fact that rows in multiple tables may be referenced.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Structure of the MIB Module</span>

   The CIRCUIT-IF-MIB consists of the following components:

   o  ciCircuitTable

   o  ciIfMapTable

   Refer to the compliance statement defined within for a definition of
   what objects MUST be implemented.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  ciCircuitTable</span>

   The ciCircuitTable is the central control table for operations of the
   Circuit Interfaces MIB.  It provides a means of mapping a circuit to
   its ifIndex as well as forcing the insertion of an ifIndex into the
   ifTable.  The agent is responsible for managing the ifIndex itself
   such that no device dependent indexing scheme is violated.

   A row in this table MUST exist in order for a row to exist in any
   other table in this MIB module.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  ciIfMapTable</span>

   This table maps the ifIndex back to the circuit that it is associated
   with.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Object Definitions</span>

CIRCUIT-IF-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    mib-2, Gauge32                          FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, RowStatus,
    TimeStamp, RowPointer, StorageType      FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP         FROM SNMPv2-CONF
    ifIndex, InterfaceIndex                 FROM IF-MIB;

    circuitIfMIB MODULE-IDENTITY
        LAST-UPDATED "200201030000Z" -- January 3, 2002
        ORGANIZATION "IETF Frame Relay Service MIB Working Group"
        CONTACT-INFO



<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


          "IETF Frame Relay Service MIB (frnetmib) Working Group

           WG Charter:    <a href="http://www.ietf.org/html.charters/frnetmib-charter.html">http://www.ietf.org/html.charters/</a>
                                 <a href="http://www.ietf.org/html.charters/frnetmib-charter.html">frnetmib-charter.html</a>
           WG-email:      frnetmib@sunroof.eng.sun.com
           Subscribe:     frnetmib-request@sunroof.eng.sun.com
           Email Archive: <a href="ftp://ftp.ietf.org/ietf-mail-archive/frnetmib">ftp://ftp.ietf.org/ietf-mail-archive/frnetmib</a>

           Chair:      Andy Malis
                       Vivace Networks
           Email:      Andy.Malis@vivacenetworks.com

           WG editor:  Robert Steinberger
                       Paradyne Networks and
                       Fujitsu Network Communications
           Email:      robert.steinberger@fnc.fujitsu.com

           Co-author:  Orly Nicklass
                       RAD Data Communications Ltd.
           EMail:      Orly_n@rad.co.il"
        DESCRIPTION
            "The MIB module to allow insertion of selected circuit into
             the ifTable."
        REVISION "200201030000Z" -- January 3, 2002
        DESCRIPTION
            "Initial version, published as <a href="./rfc3201">RFC 3201</a>"
        ::= { mib-2 94 }

    -- Textual Conventions

    CiFlowDirection ::= TEXTUAL-CONVENTION
        STATUS  current
        DESCRIPTION
            "The direction of data flow thru a circuit.

                transmit(1) - Only transmitted data
                receive(2)  - Only received data
                both(3)     - Both transmitted and received data."
        SYNTAX  INTEGER {
                  transmit(1),
                  receive(2),
                  both(3)
                }

    ciObjects      OBJECT IDENTIFIER ::= { circuitIfMIB 1 }
    ciCapabilities OBJECT IDENTIFIER ::= { circuitIfMIB 2 }
    ciConformance  OBJECT IDENTIFIER ::= { circuitIfMIB 3 }




<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


    -- The Circuit Interface Circuit Table
    --
    -- This table is used to define and display the circuits that
    -- are added to the ifTable.  It maps circuits to their respective
    -- ifIndex values.

    ciCircuitTable  OBJECT-TYPE
        SYNTAX      SEQUENCE OF CiCircuitEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "The Circuit Interface Circuit Table."
        ::= { ciObjects 1 }

    ciCircuitEntry OBJECT-TYPE
        SYNTAX      CiCircuitEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "An entry in the Circuit Interface Circuit Table."
        INDEX    { ciCircuitObject, ciCircuitFlow }
        ::= { ciCircuitTable 1 }

    CiCircuitEntry ::=
        SEQUENCE {
            --
            -- Index Control Variables
            --
            ciCircuitObject      RowPointer,
            ciCircuitFlow        CiFlowDirection,
            ciCircuitStatus      RowStatus,
            --
            -- Data variables
            --
            ciCircuitIfIndex     InterfaceIndex,
            ciCircuitCreateTime  TimeStamp,
            --
            -- Data Persistence
            --
            ciCircuitStorageType StorageType
        }

    ciCircuitObject OBJECT-TYPE
        SYNTAX      RowPointer
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "This value contains the RowPointer that uniquely



<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


             describes the circuit that is to be added to this table.
             Any RowPointer that will force the size of OBJECT
             IDENTIFIER of the row to grow beyond the legal limit
             MUST be rejected.

             The purpose of this object is to point a network manager
             to the table in which the circuit was created as well as
             define the circuit on which the interface is defined.

             Valid tables for this object include the frCircuitTable
             from the Frame Relay DTE MIB(FRAME-RELAY-DTE-MIB), the
             frPVCEndptTable from the Frame Relay Service MIB
             (FRNETSERV-MIB), and the aal5VccTable from the ATM MIB
             (ATM MIB).  However, including circuits from other MIB
             tables IS NOT prohibited."
        ::= { ciCircuitEntry 1 }

    ciCircuitFlow OBJECT-TYPE
        SYNTAX      CiFlowDirection
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "The direction of data flow through the circuit for which
             the virtual interface is defined.  The following define
             the information that the virtual interface will report.

                transmit(1) - Only transmitted frames
                receive(2)  - Only received frames
                both(3)     - Both transmitted and received frames.

             It is recommended that the ifDescr of the circuit
             interfaces that are not both(3) SHOULD have text warning
             the operators that the particular interface represents
             only half the traffic on the circuit."
        ::= { ciCircuitEntry 2 }

    ciCircuitStatus OBJECT-TYPE
        SYNTAX      RowStatus
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
            "The status of the current row.  This object is
             used to add, delete, and disable rows in this
             table.  When the status changes to active(1), a row
             will also be added to the interface map table below
             and a row will be added to the ifTable.  These rows
             SHOULD not be removed until the status is changed
             from active(1).  The value of ifIndex for the row that



<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


             is added to the ifTable is determined by the agent
             and MUST follow the rules of the ifTable.  The value
             of ifType for that interface will be frDlciEndPt(193)
             for a frame relay circuit, atmVciEndPt(194) for an
             ATM circuit, or another ifType defining the circuit
             type for any other circuit.

             When this object is set to destroy(6), the associated
             row in the interface map table will be removed and the
             ifIndex will be removed from the ifTable.  Removing
             the ifIndex MAY initiate a chain of events that causes
             changes to other tables as well.

             The rows added to this table MUST have a valid object
             identifier for ciCircuitObject.  This means that the
             referenced object must exist and it must be in a table
             that supports circuits.

             The object referenced by ciCircuitObject MUST exist
             prior to transitioning a row to active(1).  If at any
             point the object referenced by ciCircuitObject does not
             exist or the row containing it is not in the active(1)
             state, the status SHOULD either age out the row or
             report notReady(3).  The effects transitioning from
             active(1) to notReady(3) are the same as those caused
             by setting the status to destroy(6).

             Each row in this table relies on information from other
             MIB modules.  The rules persistence of data SHOULD follow
             the same rules as those of the underlying MIB module.
             For example, if the circuit defined by ciCircuitObject
             would normally be stored in non-volatile memory, then
             the row SHOULD also be non-volatile."
        ::= { ciCircuitEntry 3 }

    ciCircuitIfIndex OBJECT-TYPE
        SYNTAX      InterfaceIndex
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The ifIndex that the agent assigns to this row."
        ::= { ciCircuitEntry 4 }

    ciCircuitCreateTime OBJECT-TYPE
        SYNTAX      TimeStamp
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION



<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


            "This object returns the value of sysUpTime at the time
             the value of ciCircuitStatus last transitioned to
             active(1).  If ciCircuitStatus has never been active(1),
             this object SHOULD return 0."
        ::= { ciCircuitEntry 5 }

    ciCircuitStorageType OBJECT-TYPE
        SYNTAX      StorageType
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
            "The storage type used for this row."
    ::= { ciCircuitEntry 6 }

    -- The Circuit Interface Map Table
    --
    -- This table maps the ifIndex values that are assigned to
    -- rows in the circuit table back to the objects that define
    -- the circuits.

    ciIfMapTable  OBJECT-TYPE
        SYNTAX      SEQUENCE OF CiIfMapEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "The Circuit Interface Map Table."
        ::= { ciObjects 2 }

    ciIfMapEntry OBJECT-TYPE
        SYNTAX      CiIfMapEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "An entry in the Circuit Interface Map Table."
        INDEX    { ifIndex }
        ::= { ciIfMapTable 1 }

    CiIfMapEntry ::=
        SEQUENCE {
            --
            -- Mapped Object Variables
            --
            ciIfMapObject      RowPointer,
            ciIfMapFlow        CiFlowDirection
        }

    ciIfMapObject OBJECT-TYPE
        SYNTAX      RowPointer



<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "This value contains the value of RowPointer that
             corresponds to the current ifIndex."
        ::= { ciIfMapEntry 1 }

    ciIfMapFlow   OBJECT-TYPE
        SYNTAX      CiFlowDirection
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The value contains the value of ciCircuitFlow that
             corresponds to the current ifIndex."
        ::= { ciIfMapEntry 2 }

    -- Change tracking metrics

    ciIfLastChange OBJECT-TYPE
        SYNTAX       TimeStamp
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "The value of sysUpTime at the most recent change to
             ciCircuitStatus for any row in ciCircuitTable."
        ::= { ciObjects 3 }

    ciIfNumActive      OBJECT-TYPE
        SYNTAX         Gauge32
        MAX-ACCESS     read-only
        STATUS         current
        DESCRIPTION
            "The number of active rows in ciCircuitTable."
        ::= { ciObjects 4 }

    -- Conformance Information

    ciMIBGroups      OBJECT IDENTIFIER ::= { ciConformance 1 }
    ciMIBCompliances OBJECT IDENTIFIER ::= { ciConformance 2 }

    --
    -- Compliance Statements
    --

    ciCompliance MODULE-COMPLIANCE
        STATUS  current
        DESCRIPTION
            "The compliance statement for SNMP entities



<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


             which support of the Circuit Interfaces MIB module.
             This group defines the minimum level of support
             required for compliance."
        MODULE -- this module
            MANDATORY-GROUPS { ciCircuitGroup,
                               ciIfMapGroup,
                               ciStatsGroup }

            OBJECT      ciCircuitStatus
            SYNTAX      INTEGER { active(1) } -- subset of RowStatus
            MIN-ACCESS  read-only
            DESCRIPTION
               "Row creation can be done outside of the scope of
                the SNMP protocol.  If this object is implemented with
                max-access of read-only, then the only value that MUST
                be returned is active(1)."

            OBJECT      ciCircuitStorageType
            MIN-ACCESS  read-only
            DESCRIPTION
               "It is legal to support ciCircuitStorageType as read-
                only as long as the value reported in consistent
                with the actual storage mechanism employed within the
                agent."

    ::= { ciMIBCompliances 1 }

    --
    -- Units of Conformance
    --
    ciCircuitGroup  OBJECT-GROUP
       OBJECTS {
            ciCircuitStatus,
            ciCircuitIfIndex,
            ciCircuitCreateTime,
            ciCircuitStorageType
       }
       STATUS  current
       DESCRIPTION
           "A collection of required objects providing
            information from the circuit table."
       ::= { ciMIBGroups 1 }

    ciIfMapGroup OBJECT-GROUP
       OBJECTS {
            ciIfMapObject,
            ciIfMapFlow
       }



<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


       STATUS  current
       DESCRIPTION
           "A collection of required objects providing
            information from the interface map table."
       ::= { ciMIBGroups 2 }

    ciStatsGroup OBJECT-GROUP
       OBJECTS {
            ciIfLastChange,
            ciIfNumActive
       }
       STATUS  current
       DESCRIPTION
           "A collection of statistical metrics used to help manage
            the ciCircuitTable."
       ::= { ciMIBGroups 3 }
END

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Acknowledgments</span>

   This document was produced by the Frame Relay Service MIB Working
   Group.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  References</span>

   [<a id="ref-1">1</a>]  Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
        Describing SNMP Management Frameworks", <a href="./rfc2571">RFC 2571</a>, April 1999.

   [<a id="ref-2">2</a>]  Rose, M. and K. McCloghrie, "Structure and Identification of
        Management Information for TCP/IP-based Internets", STD 16, <a href="./rfc1155">RFC</a>
        <a href="./rfc1155">1155</a>, May 1990.

   [<a id="ref-3">3</a>]  Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
        <a href="./rfc1212">RFC 1212</a>, March 1991.

   [<a id="ref-4">4</a>]  Rose, M., "A Convention for Defining Traps for use with the
        SNMP", <a href="./rfc1215">RFC 1215</a>, March 1991.

   [<a id="ref-5">5</a>]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
        M. and S. Waldbusser, "Structure of Management Information
        Version 2 (SMIv2)", STD 58, <a href="./rfc2578">RFC 2578</a>, April 1999.

   [<a id="ref-6">6</a>]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
        M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
        <a href="./rfc2579">RFC 2579</a>, April 1999.






<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


   [<a id="ref-7">7</a>]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
        M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
        58, <a href="./rfc2580">RFC 2580</a>, April 1999.

   [<a id="ref-8">8</a>]  Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
        Network Management Protocol", STD 15, <a href="./rfc1157">RFC 1157</a>, May 1990.

   [<a id="ref-9">9</a>]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
        "Introduction to Community-based SNMPv2", <a href="./rfc1901">RFC 1901</a>, January
        1996.

   [<a id="ref-10">10</a>] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
        Mappings for Version 2 of the Simple Network Management Protocol
        (SNMPv2)", <a href="./rfc1906">RFC 1906</a>, January 1996.

   [<a id="ref-11">11</a>] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
        Processing and Dispatching for the Simple Network Management
        Protocol (SNMP)", <a href="./rfc2572">RFC 2572</a>, April 1999.

   [<a id="ref-12">12</a>] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
        for version 3 of the Simple Network Management Protocol
        (SNMPv3)", <a href="./rfc2574">RFC 2574</a>, April 1999.

   [<a id="ref-13">13</a>] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
        Operations for Version 2 of the Simple Network Management
        Protocol (SNMPv2)", <a href="./rfc1905">RFC 1905</a>, January 1996.

   [<a id="ref-14">14</a>] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", <a href="./rfc2573">RFC</a>
        <a href="./rfc2573">2573</a>, April 1999.

   [<a id="ref-15">15</a>] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
        Control Model (VACM) for the Simple Network Management Protocol
        (SNMP)", <a href="./rfc2575">RFC 2575</a>, April 1999.

   [<a id="ref-16">16</a>] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
        to Version 3 of the Internet-standard Network Management
        Framework", <a href="./rfc2570">RFC 2570</a>, April 1999.

   [<a id="ref-17">17</a>] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
        <a href="./rfc2863">RFC 2863</a>, June 2000.

   [<a id="ref-18">18</a>] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects for
        Frame Relay Service", <a href="./rfc2954">RFC 2954</a>, October 2000.

   [<a id="ref-19">19</a>] Waldbusser, S., "Remote Network Monitoring Management
        Information Base Version 2 using SMIv2", <a href="./rfc2021">RFC 2021</a>, January 1997.





<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


   [<a id="ref-20">20</a>] Brown, C. and F. Baker, "Management Information Base for Frame
        Relay DTEs Using SMIv2", <a href="./rfc2115">RFC 2115</a>, September 1997.

   [<a id="ref-21">21</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-22">22</a>] Tesink, K., "Definitions of Managed Objects for ATM Management",
        <a href="./rfc2515">RFC 2515</a>, February 1999.

   [<a id="ref-23">23</a>] Waldbusser, S., "Remote Network Monitoring Management
        Information Base", <a href="./rfc2819">RFC 2819</a>, May 2000.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Security Considerations</span>

   There are a number of management objects defined in this MIB that
   have a MAX-ACCESS clause of read-write and/or 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 <a href="./rfc2274">RFC 2274</a> [<a href="#ref-12" title="&quot;User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)&quot;">12</a>] and the View-based
   Access Control Model <a href="./rfc2275">RFC 2275</a> [<a href="#ref-15" title="&quot;View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)&quot;">15</a>] 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.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  IANA Considerations</span>

   New ifTypes defined specifically for use in this MIB module SHOULD be
   in the form of ***EndPt.  This is similar to frDlciEndPt(193) and
   atmVciEndPt(194) which are already defined.









<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Authors' Addresses</span>

   Robert Steinberger
   Fujitsu Network Communications
   2801 Telecom Parkway
   Richardson, TX 75082

   Phone: 1-972-479-4739
   EMail: robert.steinberger@fnc.fujitsu.com


   Orly Nicklass, Ph.D
   RAD Data Communications Ltd.
   12 Hanechoshet Street
   Tel Aviv, Israel 69710

   Phone: 972 3 7659969
   EMail: Orly_n@rad.co.il

































<span class="grey">Steinberger &amp; Nicklass      Standards Track                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc3201">RFC 3201</a>                Circuit to Interface MIB            January 2002</span>


<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  Full Copyright Statement</span>

   Copyright (C) The Internet Society (2002).  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.



















Steinberger &amp; Nicklass      Standards Track                    [Page 23]
</pre>