rfc3201.txt

RFC 的详细文档！

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


                     Definitions of Managed Objects
                  for Circuit to Interface Translation

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

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



Steinberger & Nicklass      Standards Track                     [Page 1]

RFC 3201                Circuit to Interface MIB            January 2002


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

1.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   o  An overall architecture, described in RFC 2571 [1].

   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 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].  The
      second version, called SMIv2, is described in STD 58, RFC 2578
      [5], RFC 2579 [6] and RFC 2580 [7].

   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 [8].  A second version of the SNMP
      message protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC
      1906 [10].  The third version of the message protocol is called
      SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
      [12].

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






Steinberger & Nicklass      Standards Track                     [Page 2]

RFC 3201                Circuit to Interface MIB            January 2002


   o  A set of fundamental applications described in RFC 2573 [14] and
      the view-based access control mechanism described in RFC 2575
      [15].

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

   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.

2.  Conventions

   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
   RFC 2119 [21].

3.  Overview

   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 RFC 2819 [23] and RFC 2021 [19]) 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
   (RFC 2021 [19]) 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.



Steinberger & Nicklass      Standards Track                     [Page 3]

RFC 3201                Circuit to Interface MIB            January 2002


3.1.  Circuit Concepts

   There are multiple MIB modules that define circuits.  Three commonly
   used MIB modules are FRAME-RELAY-DTE-MIB (RFC 2115) [20], FRNETSERV-
   MIB (RFC 2954) [18], and ATM-MIB (RFC 2515) [22].  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 (RFC 2863) [17] 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.

3.2.  Theory of Operation

3.2.1.  Creation Process

   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



Steinberger & Nicklass      Standards Track                     [Page 4]

RFC 3201                Circuit to Interface MIB            January 2002


   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) [18].  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) [20].  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) [22].  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.

3.2.2.  Destruction Process

3.2.2.1.  Manual Row Destruction

   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.

3.2.2.2.  Automatic Row Destruction

   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.

3.2.3.  Modification Process

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

3.2.4.  Persistence of Data

   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.




Steinberger & Nicklass      Standards Track                     [Page 5]

RFC 3201                Circuit to Interface MIB            January 2002


4.  Relation to Other MIB Modules

4.1.  Frame Relay DTE MIB

   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.

4.2.  Frame Relay Service MIB

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

4.3.  ATM MIB

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

4.4.  Interfaces Group MIB

4.4.1.  Interfaces Table (ifTable, ifXtable)

   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