rfc2515.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2515                 ATM Management Objects            February 1999


3.3.4.  Service Category

   Replacing QoS Class, VPLs and VCLs are qualified in terms of their
   service category (atmServiceCategory). When properly configured, VCLs
   (or VPLs) concatenated to form a VCC (or VPC) will all have the same
   service category class as that of the VCC (or VPC).

3.4.  Max Active and Max Current VPI and VCI Bits

   A manager may wish to configure the maximum number of VPI and VCI
   bits that can be used to identify VPIs and VCIs on a given ATM
   interface.  This value can be less than or equal to the maximum
   number of bits supported by the interface hardware, and is referred
   to in the MIB as the Max Active VPI Bits and Max Active VCI Bits.

   However, a manager may not be able to configure the Max Active Bits
   on both ends of an ATM link.  For example, the manager may not be
   allowed write access to the peer's MIB, or there may be hardware
   limitations on the peer device.  Therefore, the two ATM devices may
   use ILMI to negotiate "Max Current" VPI and VCI bits, which is the
   maximum number of bits that both interfaces are willing to support.
   This is illustrated in Figure 5. The relationship between the
   different parameters is illustrated in Figure 6.  Note that if ILMI
   negotiation is not supported, then the devices have no choice but to
   use the configured Max Active bits, and assume that it has been
   configured to the same value on both ends of the link.


     +--------+              +--------+              +--------+
     |  ATM   | IF a    IF b |  ATM   | IF c    IF d |  ATM   |
     | Device |--------------| Device |--------------| Device |
     +--------+              +--------+              +--------+

         IF a:  Max Active VPI Bits =  6  (configured)
                Max Current VPI Bits = 6  (negotiated)

         IF b:  Max Active VPI Bits =  8  (configured)
                Max Current VPI Bits = 6  (negotiated)

         IF c:  Max Active VPI Bits =  8  (configured)
                Max Current VPI Bits = 8  (negotiated)

         IF d:  Max Active VPI Bits =  8  (configured)
                Max Current VPI Bits = 8  (negotiated)







Tesink                      Standards Track                     [Page 7]

RFC 2515                 ATM Management Objects            February 1999


         (between IF a and IF b, the minimum of the two configured
          "Max Active VPI Bits" is 6, so both interfaces set their
          "Max Current VPI Bits" to 6.  Since IF c and IF d both
          are configured with "Max Active VPI Bits" of 8, they
          set their "Max Current VPI Bits" to 8.)

                                  Figure 5


       MSB                                                   LSB
         +----------------------------------------------------+
         |         |         |                |               |
         +----------------------------------------------------+
         ^         ^         ^                ^
         |         |         |                |
    Max bits    Max Bits    Max              Max
    supported   supported   Active (config.) current (negotiated)
    by MIB      by h/w      Bits             Bits

                                  Figure 6

4.  Overview

   ATM management objects are used to manage ATM interfaces, ATM virtual
   links,  ATM cross-connects, AAL5 entities and AAL5 connections
   supported by ATM hosts, ATM switches and ATM networks.  This section
   provides an overview and background of how to use this MIB and other
   potential MIBs for this purpose.

   The purpose of this memo is primarily to manage ATM PVCs.  ATM SVCs
   are also represented by the management information in this MIB.
   However, full management of SVCs may require additional capabilities
   which are beyond the scope of this memo.

4.1.  Background

   In addition to the MIB module defined in this memo, other MIB modules
   are necessary to manage ATM interfaces, links and cross-connects.
   Examples include MIB II for general system and interface management
   [16][17], the DS3 or SONET MIBs for management of physical
   interfaces, and, as appropriate, MIB modules for applications that
   make use of ATM, such as SMDS.  These MIB modules are outside the
   scope of this specification.

   The current specification of this ATM MIB is based on SNMPv2-SMI.






Tesink                      Standards Track                     [Page 8]

RFC 2515                 ATM Management Objects            February 1999


4.2.  Structure of the MIB

   The managed ATM objects are arranged into the following tables:

         (1) ATM interface configuration table
         (2) ATM interface DS3 PLCP  and TC sublayer tables
         (3) ATM traffic parameter table
         (4) ATM interface virtual link (VPL/VCL) configuration
             tables
         (5) ATM VP/VC cross-connect tables
         (6) AAL5 connection performance statistics table

   Note that, managed objects for activation/deactivation of OAM cell
   flows and ATM traps notifying virtual connection or virtual link
   failures are outside the scope of this memo.

4.3.  ATM Interface Configuration Table

   This table contains information on ATM cell layer configuration of
   local ATM interfaces on an ATM device in addition to the information
   on such interfaces contained in the ifTable.

4.4.  ATM Interface DS3 PLCP and TC Layer Tables

   These tables provide performance statistics of the DS3 PLCP and TC
   sublayer of local ATM interfaces on a managed ATM device.  DS3 PLCP
   and TC sublayer are currently used to carry ATM cells respectively
   over DS3 and SONET transmission paths.

4.5.  ATM Virtual Link and Cross-Connect Tables

   ATM virtual link and cross-connect tables model bi-directional ATM
   virtual links and ATM cross-connects.  The ATM VP/VC link tables are
   implemented in an ATM host, ATM switch and ATM network.  The ATM
   switch and ATM network also implement the ATM VP/VC cross-connect
   tables.  Both link and cross-connect tables are implemented in a
   carrier's network for Customer Network Management (CNM) purposes.

   The ATM virtual link tables are used to create, delete or modify ATM
   virtual links in an ATM host, ATM switch and ATM network.  ATM
   virtual link tables along with the cross-connect tables are used to
   create, delete or modify ATM cross-connects in an ATM switch or ATM
   network (e.g., for CNM purposes).

   For a PVC, the cross-connect between two VPLs is represented in the
   atmVpCrossConnectTable of the ATM-MIB, indexed by the
   atmVplCrossConnectIdentifier values for the two VPLs, and the cross-




Tesink                      Standards Track                     [Page 9]

RFC 2515                 ATM Management Objects            February 1999


   rconnect between two VCLs is represented in the
   atmVcCrossConnectTable of the ATM-MIB, indexed by the
   atmVclCrossConnectIdentifier values for the two VCLs.

   For an SVC or Soft PVC the VPL and VCL tables defined in this memo
   are used. Hoewever, for an SVC or Soft PVC the cross-connect between
   two VPLs is represented in the atmSvcVpCrossConnectTable of the
   ATM2-MIB, indexed by the atmVplCrossConnectIdentifier values for the
   two VPLs, and the cross-connect between two VCLs is represented in
   the atmSvcVcCrossConnectTable of the ATM2-MIB, indexed by the
   atmVclCrossConnectIdentifier values for the two VCLs.

   Note: The ATM2-MIB module was being defined in a separate memo at the
   time of this publication. Please consult the RFC directory for an
   exact reference.

5.  Application of MIB II to ATM

5.1.  The System Group

   For the purposes of the sysServices object in the System Group of MIB
   II [16], ATM is a data link layer protocol.  Thus, for ATM switches
   and ATM networks, sysServices will have the value "2".

5.2.  The Interface Group

   The Interfaces Group of MIB II defines generic managed objects for
   managing interfaces.  This memo contains the media-specific
   extensions to the Interfaces Group for managing ATM interfaces.

   This memo assumes the interpretation of the Interfaces Group to be in
   accordance with [17] which states that the interfaces table (ifTable)
   contains information on the managed resource's interfaces and that
   each sub-layer below the internetwork layer of a network interface is
   considered an interface.  Thus, the ATM cell layer interface is
   represented as an entry in the ifTable.  This entry is concerned with
   the ATM cell layer as a whole, and not with individual virtual
   connections which are managed via the ATM-specific managed objects
   specified in this memo.  The inter-relation of entries in the ifTable
   is defined by Interfaces Stack Group defined in [17].

5.2.1.  Support of the ATM Cell Layer by ifTable

   Some specific interpretations of ifTable for the ATM cell layer
   follow.






Tesink                      Standards Track                    [Page 10]

RFC 2515                 ATM Management Objects            February 1999


   Object     Use for the generic ATM layer
   ======     =============================

   ifIndex    Each ATM port is represented by an ifEntry.

   ifDescr    Description of the ATM interface.

   ifType     The value that is allocated for ATM is 37.

   ifSpeed    The total bandwidth in bits per second
              for use by the ATM layer.

   ifPhysAddress  The interface's address at the ATM protocol
              sublayer; the ATM address which would be used as the value
              of the Called Party Address Information Element (IE) of a
              signalling message for a connection which either:
              - would terminate at this interface, or
              - for which the Called Party Address IE
                would need to be replaced by the Called Party SubAddress
                IE before the message was forwarded to any other
                interface.
              For an interface on which signalling is not supported,
              then the interface does not necessarily have an address,
              but if it does, then ifPhysAddress is the address which
              would be used as above in the event that signalling were
              supported.  If the interface has multiple such addresses,
              then ifPhysAddress is its primary address. If the
              interface has no addresses, then ifPhysAddress is an octet
              string of zero length.  Address encoding is as per [20].
              Note that addresses assigned for purposes other than those
              listed above (e.g., an address associated with the service
              provider side of a public network UNI) may be represented
              through atmInterfaceSubscrAddress.

   ifAdminStatus  See [17].

   ifOperStatus   Assumes the value down(2) if the ATM cell
              layer is down.

   ifLastChange   See [17].

   ifInOctets     The number of received octets over the
              interface, i.e., the number of received, assigned cells
              multiplied by 53.

   ifOutOctets    The number of transmitted octets over the interface,
              i.e., the number of transmitted, assigned cells multiplied
              by 53.



Tesink                      Standards Track                    [Page 11]

RFC 2515                 ATM Management Objects            February 1999


   ifInErrors     The number of cells dropped due to uncorrectable HEC
              errors.

   ifInUnknownProtos The number of received cells discarded during cell
              header validation, including cells with unrecognized
              VPI/VCI values, and cells with invalid cell header
              patterns.  If cells with undefined PTI values are
              discarded, they are also counted here.

   ifOutErrors    See [17].

   ifName     Textual name (unique on this system) of the
              interface or an octet string of zero length.

   ifLinkUpDownTrapEnable  Default is disabled (2).

   ifConnectorPresent      Set to false (2).

   ifHighSpeed    See [17].

   ifHCInOctets   The 64-bit version of ifInOctets; supported
              if required by the compliance statements in [17].

   ifHCOutOctets  The 64-bit version of ifOutOctets; supported
              if required by the compliance statements in [17].

   ifAlias        The non-volatile 'alias' name for the interface
              as specified by a network manager.

6.  Support of the AAL3/4 Based Interfaces

   For the management of AAL3/4 CPCS layer, see [18].

7.  Support of the AAL5 Managed Objects

   Support of AAL5 managed objects in an ATM switch and ATM host are
   described below.

7.1.  Managing AAL5 in a Switch

   Managing AAL5 in a switch involves:

        (1) performance management of an AAL5 entity as
            an internal resource in a switch

        (2) performance management of AAL5 per virtual connection





Tesink                      Standards Track                    [Page 12]

RFC 2515                 ATM Management Objects            February 1999