tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 1695


Pages: 73
Top     in Index     Prev     Next
 

Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2

Part 1 of 3, p. 1 to 17
None       Next RFC Part

Obsoleted by:    2515


Top       ToC       Page 1 
Network Working Group                                           M. Ahmed
Request for Comments: 1695                                     K. Tesink
Category: Standards Track                                        Editors
                                            Bell Communications Research
                                                             August 1994


                     Definitions of Managed Objects
                     for ATM Management Version 8.0
                              using SMIv2

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.

Table of Contents

   1. Introduction .............................................    2
   2. The SNMPv2 Network Management Framework ..................    2
   3. Object Definitions .......................................    2
   4. ATM Terminology ..........................................    3
   4.1 VCL/VPL and VCC/VPC .....................................    3
   4.2 PVC and SVC .............................................    5
   4.3 Traffic Management Parameters ...........................    5
   4.3.1 Traffic Policing and Traffic Shaping  Parameters ......    5
   4.3.2 Cell Loss Priority ....................................    6
   4.3.3 QoS Class .............................................    6
   5. Overview .................................................    7
   5.1 Background ..............................................    7
   5.2 Structure of the MIB ....................................    7
   5.3 ATM Interface Configuration Group .......................    7
   5.4 ATM Interface DS3 PLCP and TC Layer Groups ..............    8
   5.5 ATM Virtual Link and Cross-Connect Groups ...............    8
   6. Application of MIB II to ATM .............................    8
   6.1 The System Group ........................................    8
   6.2 The Interface Group .....................................    8
   6.2.1 Support of the ATM Cell Layer by ifTable ..............    9
   7. Support of the AAL3/4 Based Interfaces ...................   10
   8. Support of the AAL5 Managed Objects ......................   10
   8.1 Managing AAL5 in a Switch ...............................   11
   8.2 Managing AAL5 in a Host .................................   12
   8.3 Support of AAL5 by ifTable ..............................   13
   8.4 Support of Proprietary Virtual Interface  by  ifT-able ..   14
   8.5 AAL5 Connection Performance Statistics Group ............   15

Top      ToC       Page 2 
   9. ILMI MIB and the ATM Managed Objects .....................   15
   10. Definitions .............................................   18
   11. Acknowledgments .........................................   72
   12. References ..............................................   72
   13. Security Considerations .................................   73
   14. Authors' Addresses ......................................   73

1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes objects used for managing ATM-based
   interfaces, devices, networks and services.

   This memo specifies a MIB module in a manner that is both compliant
   to the SNMPv2 SMI, and semantically identical to the peer SNMPv1
   definitions.

2.  The SNMPv2 Network Management Framework

   The SNMPv2 Network Management Framework consists of four major
   components.  They are:

      0    RFC 1442 [1] which defines the SMI, the mechanisms used
           for describing and naming objects for the purpose of
           management.

      0    STD 17, RFC 1213 [2] defines MIB-II, the core set of
           managed objects for the Internet suite of protocols.

      0    RFC 1445 [3] which defines the administrative and other
           architectural aspects of the framework.

      0    RFC 1448 [4] which defines the protocol used for network
           access to managed objects.

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

3.  Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1)
   defined in the SMI.  In particular, each object type is named by an
   OBJECT IDENTIFIER, an administratively assigned name.  The object
   type together with an object instance serves to uniquely identify a
   specific instantiation of the object.  For human convenience, we

Top      ToC       Page 3 
   often use a textual string, termed the descriptor, to also refer to
   the object type.

4.  ATM Terminology

   Some basic ATM terminologies are described in this section to
   facilitate defining the ATM managed objects.

4.1.  VCL/VPL and VCC/VPC

   There are two distinct types of ATM virtual connections: Virtual
   Channel Connections (VCCs) and Virtual Path Connection (VPCs).  As
   shown in Figures 1 and 2, ATM virtual connections consist of
   concatenated series of virtual links which forms a path between two
   end points, with each concatenation occurring at an ATM switch.
   Virtual links of VCCs are called Virtual Channel Links (VCLs).
   Virtual links of VPCs are called Virtual Path Links (VPLs). The VCI
   and VPI fields in the ATM cell header associate each cell of a VCC
   with a particular VCL over a given physical link.  The VPI field in
   the ATM cell header associates each cell of a VPC with a particular
   VPL over a given physical link.  Switches route cells between VCLs
   (or VPLs) via a cross-connect function according to the cells'
   VCI/VPI (or VPI) values.

            <-----------------------VCC-------------------------->
                      ------------             -----------
                      |ATM       |             |ATM       |
                      |X-Connect |             |X-Connect |
               VCL1   |Point     |    VCL2     |Point     |  VCL3
            O---------|----X-----|-------|-----|----X-----|-------O
                      |          |             |          |
                      ------------             ------------
                       ATM Switch               ATM Switch


            Figure 1: Virtual Channel Links and
                      Virtual Channel Connection

Top      ToC       Page 4 
            <-----------------------VPC-------------------------->
                      ------------             -----------
                      |ATM       |             |ATM       |
                      |X-Connect |             |X-Connect |
               VPL1   |Point     |    VPL2     |Point     |  VPL3
            O---------|----X-----|-------|-----|----X-----|-------O
                      |          |             |          |
                      ------------             ------------
                       ATM Switch               ATM Switch


            Figure 2: Virtual Path Links and
                      Virtual Path Connection

   A single ATM end-system or switch does not support the whole end-to-
   end span of a VCC (or VPC).  Rather, multiple ATM end- systems and/or
   switches each support one piece of the VCC (or VPC).   That is, each
   ATM end-system at one end of the VCC/VPC supports its end of the
   VCC/VPC  plus the VCLs or VPLs on its external interfaces, and each
   switch through which the VCC/VPC passes, supports the multiple
   VCLs/VPLs on that switch's external interfaces and the cross-
   connection of those VCLs/VPLs through that switch.  Thus, the end-
   to-end management of a VCC or VPC is achieved only by appropriate
   management of its individual pieces in combination.

   Note that for management purposes, an ATM network may be viewed as a
   large distributed switch by hiding all the network's internal
   connectivity as being internal to the distributed switch (as shown in
   Figure 2a).  This model may for example be used for Customer Network
   Management (CNM) purposes.

Top      ToC       Page 5 
            <---------------------VCC--------------------------->
                    --------------------------------------
                    |                                    |
                    | ----------              ---------- |
                    | | ATM    |              | ATM    | |
               VCL1 | | Switch |              | Switch | | VCL3
            O-------|-|--------|------/-------|--------|-|------O
                    | |        |              |        | |
                    | ----------              ---------- |
                    |                                    |
                    |             ATM Network            |
                    --------------------------------------



            Figure 2a: ATM Network modeled as a large distributed
                       switch

   A VCC has a set of traffic characteristics (i.e., bandwidth
   parameters, QoS Class parameters, etc.).  VCLs inherit their traffic
   characteristics from the VCC of which they are a part.  VCCs are bi-
   directional by definition.  However, the traffic parameters in the
   two directions of a connection can be symmetric or asymmetric, i.e.,
   the two directions can have the same or different traffic flows.  A
   uni-directional traffic flow across a VCC is achieved by assigning a
   zero bandwidth in one direction.  Note that in addition to the
   bandwidth required by the user traffic flow, bandwidth is also
   required for OAM cell flows, even for the zero-bandwidth direction of
   a uni-directional connection.  These same principles apply to VPCs.

4.2.  PVC and SVC

   A Permanent Virtual Connection (PVC) is a provisioned VCC or VPC.  A
   Switched Virtual Connection (SVC) is a switched VCC or VPC that is
   set up in real-time via call set-up signaling procedures.  A PVC (or
   an SVC) can be a point-to-point, point-to-multipoint, or multipoint-
   to-multipoint VCC or VPC.

4.3.  Traffic Management Parameters

4.3.1.  Traffic Policing and Traffic Shaping Parameters

   In order to allocate resources fairly among different users, some
   networks police traffic at resource access points.  The traffic
   enforcement or policing taken at a UNI is called Usage Parameter
   Control (UPC) and is activated on an incoming VCL or VPL as shown in
   Figure 3.  The use of the traffic enforcer at the ingress of the
   connection is to make sure that the user traffic does not exceed the

Top      ToC       Page 6 
   negotiated traffic parameters such as the peak cell rate associated
   with a specific traffic descriptor type.


                     ----------             ----------
              UNI    |  ATM   |    NNI      |  ATM   |     UNI
               |     | switch |     |       | switch |      |
          O<---|---->X(UPC)   |<----|------>|   (UPC)X<-----|--->O
               | VCL |        |     | VCL   |        |  VCL |
                     ----------             ----------


                         Figure 3: An Example of a UPC

   In addition, traffic shaping may be performed on an outgoing VPL or
   VCL at a given ATM interface.  The function of the ATM traffic shaper
   either at the source or an egress point of the connection is to
   smooth the outgoing cell traffic inter-arrival time.  If policing or
   shaping is not performed then the policing or shaping algorithm is
   not activated.  ATM Forum has specified seven traffic descriptor
   types including one for the best effort traffic [9].

4.3.2.  Cell Loss Priority

   To prioritize traffic during resource congestion, ATM cells are
   assigned one of the two types of Cell Loss Priority (CLP), CLP=0 and
   CLP=1.  ATM cells with CLP=0 have a higher priority in regard to cell
   loss than ATM cells with CLP=1.  Therefore, during resource
   congestions, CLP=1 cells are dropped before any CLP=0 cell is
   dropped.

4.3.3.  QoS Class

   A VCC or VPC is associated with one of a number of Quality of Service
   (QoS) classes.  The following service classes have been specified:

      Service Class A: Constant bit rate video and Circuit
                       emulation
      Service Class B: Variable bit rate video/audio
      Service Class C: Connection-oriented data
      Service Class D: Connectionless data

   Four QoS classes numbered 1, 2, 3, and 4 have been specified with the
   aim of supporting service classes A, B, C, and D respectively.  The
   VCLs (or VPLs) concatenated to form a VCC (or VPC) will all have the
   same QoS class as that of the VCC (or VPC).  The Cell Loss Ratio
   (CLR), Cell Delay Variation (CDV), and end-to-end Cell Delay (CD)
   parameters are defined as part of QoS Class definition.  In addition,

Top      ToC       Page 7 
   an unspecified QoS Class numbered 0 is specified for best effort
   traffic.

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

5.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
   (RFC 1213 and RFC 1573), 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.

5.2.  Structure of the MIB

   The managed ATM objects are arranged into the following groups:

                (1) ATM interface configuration group
                (2) ATM interface DS3 PLCP group
                (3) ATM interface TC Sublayer group
                (4) ATM interface virtual link (VPL/VCL) configuration
                    groups
                (5) ATM VP/VC cross-connect groups
                (6) AAL5 connection performance statistics group

   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.

5.3.  ATM Interface Configuration Group

   This group contains information on ATM cell layer configuration of
   local ATM interfaces on an ATM device in addition to the information

Top      ToC       Page 8 
   on such interfaces contained in the ifTable.

5.4.  ATM Interface DS3 PLCP and TC Layer Groups

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

5.5.  ATM Virtual Link and Cross-Connect Groups

   ATM virtual link and cross-connect groups model bi-directional ATM
   virtual links and ATM cross-connects.  The ATM VP/VC link groups 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
   groups.  Both link and cross-connect groups are implemented in a
   carrier's network for Customer Network Management (CNM) purposes.

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

6.  Application of MIB II to ATM

6.1.  The System Group

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

6.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 [5] 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 [5].

Top      ToC       Page 9 
6.2.1.  Support of the ATM Cell Layer by ifTable

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

          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 [9].  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 atmInterfaceAdminAddress.

          ifAdminStatus  See [5].

          ifOperStatus   Assumes the value down(2) if the ATM cell
                     layer or any layer below that layer is down.

Top      ToC       Page 10 
          ifLastChange   See [5].

          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.

          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 [5].

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

          ifPromiscuousMode       Set to false(2).

          ifHighSpeed    See [5].

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

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

7.  Support of the AAL3/4 Based Interfaces

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

8.  Support of the AAL5 Managed Objects

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

Top      ToC       Page 11 
8.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

   AAL5 in a switch is modeled as shown in Figures 4 and 5.  AAL5 will
   be managed in a switch for only those virtual connections that carry
   AAL5 and are terminated at the AAL5 entity in the switch.  Note that,
   the virtual channels within the ATM UNIs carrying AAL5 will be
   switched by the ATM switching fabric (termed as ATM Entity in the
   figure) to the virtual channels on a proprietary internal interface
   associated with the AAL5 process (termed as AAL5 Entity in the
   figure). Therefore, performance management of the AAL5 resource in
   the switch will be modeled using the ifTable through an internal
   (pseudo-ATM) virtual interface and the AAL5 performance management
   per virtual connection will be supported using an additional AAL5
   connection table in the ATM MIB.  The association between the AAL5
   virtual link at the proprietary virtual, internal interface and the
   ATM virtual link at the ATM interface will be derived from the
   virtual channel cross-connect table and the virtual channel link
   table in the ATM MIB.

                        ___________________________
                        |                         |
                        |     =============       |
                        |     |    AAL5   |       |
                        |     |   Entity  |       |
                        |     =============       |
                        |           |             |
                        |         -----Prop. Virtual Interface
                        |           |             |
                        |     =============       |
                        |     |   ATM     |       |
                        |     |  Entity   |       |
                        |     =============       |
                        |_____|__|__|__|__|_______|
                              |  |  |  |  |
                             ---------------- ATM UNIs
                              |  |  |  |  |
                              |  |  |  |  |
                              v  v  v  v  v

                Figure 4 : Model of an AAL5 Entity in a Switch

Top      ToC       Page 12 
                            __________________
                            |                |
                            |   AAL5         |
                            |________________|
                            |                |
                            | Prop. Virtual  |
                            |  Interface     |
                            |________________|

               Figure 5 : AAL5 Entity's Interface Stack in a Switch

8.2.  Managing AAL5 in a Host

   Managing AAL5 in a host involves managing the AAL5 sublayer interface
   as shown in Figures 6 and 7.  The AAL5 sublayer is stacked directly
   over the ATM sublayer.  The ifTable is applied to the AAL5 sublayer
   as defined in Section 8.3.

                        ___________________________
                        |                         |
                        |     =============       |
                        |     |    AAL5   |       |
                        |     |   Entity  |       |
                        |     =============       |
                        |     |   ATM     |       |
                        |     |  Entity   |       |
                        |     =============       |
                        |___________|_____________|
                                    |
                                  __|__ ATM UNI
                                    |
                                    |
                                    v

                Figure 6 : Model of an AAL5 Entity in a Host


                            __________________
                            |                |
                            |   AAL5         |
                            |________________|
                            |                |
                            |   ATM Layer    |
                            |________________|
                            |                |
                            |  Physical Layer|
                            |________________|

Top      ToC       Page 13 
                 Figure 7 : AAL5 Entity's Interface Stack in a Host

8.3.  Support of AAL5 by ifTable

   The AAL5 entity in an ATM device (e.g., switch or host) is managed
   using the ifTable.  There are additional counters specified for AAL5
   than those specified in the ATM B-ICI document [10].  Specific
   interpretations of ifTable for the AAL5 CPCS layer are as follows.

          Object   Use for AAL5 CPCS layer entity
          ======   ==============================

          ifIndex  Each AAL5 entity is represented by an ifEntry.

          ifDescr  Description of the AAL5 entity.

          ifType   The value that is allocated for AAL5 is 49.

          ifMtu    Set to the largest PDU size for the
                   AAL5 CPCS layer that can be processed
                   by the AAL5 entity.

          ifSpeed  Set to 0.

          ifPhysAddress   An octet string of zero length.

          ifAdminStatus   See [5].

          ifOperStatus    Assumes the value down(2) if the AAL5 or
                   any layer below that layer is down.

          ifLastChange    See [5].

          ifInOctets      The number of received AAL5 CPCS PDU octets.

          ifOutOctets     The number of AAL5 CPCS PDU octets
                   transmitted.

          ifInUcastPkts   The number of received AAL5 CPCS PDUs passed
                   to a higher-layer.

          ifOutUcastPkts  The number of AAL5 CPCS PDUs received from a
                   higher-layer for transmission.
                   [Note:  The number of AAL5 PDUs actually
                   transmitted is the number received from a
                   higher-layer for transmission minus any which
                   are counted by ifOutErrors and ifOutDiscards.]

Top      ToC       Page 14 
          ifInErrors      Number of errored AAL5 CPCS PDUs received.
                   The types of errors counted include  CRC-32 errors,
                   SAR time-out errors, and oversized SDU errors.

          ifInUnknownProtos Set to 0.

          ifInDiscards    Number of received AAL5 CPCS PDUs discarded.
                   Possible reason may be input buffer overflow.

          ifOutErrors     Number of AAL5 CPCS PDUs that could not
                   be transmitted due to errors.

          ifOutDiscards   Number of AAL5 CPCS PDUs received for
                   transmission that are discarded.
                   Possible reason may be output buffer
                   overflow.

          ifInMulticastPkts  Set to 0.

          ifInBroadcastPkts  Set to 0.

          ifOutMulticastPkts Set to 0.

          ifOutBroadcastPkts Set to 0.

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

          ifHighSpeed       Set to 0.

          ifConnectorPresent Set to false (2).

          ifPromiscuousMode Set to false(2).

          ifLinkUpDownTrapEnable     Default is disabled (2).

8.4.  Support of Proprietary Virtual Interface by ifTable

   Specific interpretations of ifTable for the proprietary virtual,
   internal interface associated with an AAL5 entity in an ATM switch
   are as follows.

          Object   Use for proprietary virtual, internal interface
                   associated with AAL entities
          ======   ===============================================

          ifIndex  Each proprietary virtual, internal interface
                   associated with AAL entities is represented by an

Top      ToC       Page 15 
                   ifEntry.

          ifDescr  Description of the proprietary virtual, internal
                   interface associated with AAL entities.

          ifType   The value that is allocated for proprietary
                   virtual, internal interface is 53.

          ifSpeed  See [5].  Set to 0 if the speed is not
                   known.

          ifPhysAddress   See [5]. An octet string of zero length
                   if no address is used for this interface.

          ifAdminStatus   See [5].

          ifOperStatus    See [5].

          ifLastChange    See [5].

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

          ifHighSpeed     See [5]. Set to 0 if the speed is not known.

          ifConnectorPresent  Set to false (2).

          ifLinkUpDownTrapEnable     Default is disabled (2).

8.5.  AAL5 Connection Performance Statistics Group

   An AAL5 connection table is used to provide AAL5 performance
   information for each AAL5 virtual connection that is terminated at
   the AAL5 entity contained within an ATM switch or host.

9.  ILMI MIB and the ATM Managed Objects

   The ILMI MIB is specified by the ATM Forum in UNI specification [9],
   to manage local ATM UNIs.  The support of the ATM management
   functions by the ILMI MIB and those contained in this memo are
   compared in Table 1.  In this table, "yes" in the "ILMI MIB"  column
   indicates that the management functions are supported by the ILMI
   MIB.  The MIB groups in the "This memo" column are the groups listed
   in Section 5.2.

   For that subset of management information which the ILMI MIB and this
   memo have in common, every effort has been made to retain identical
   semantics and syntax, even though the MIB objects are identified

Top      ToC       Page 16 
   using different OBJECT IDENTIFIERs.

                       Table 1 - Structuring of ATM Managed Objects

          ______________________________________________________________
                        |                                 |This   |ILMI|
          ATM Mgmt.Inf. |ATM Managed Objects              |memo   |MIB |
          ______________|_________________________________|_______|____|

          Local Interface Information:
          _____________________________________________________________
          ATM interface:| (1) port identifier             |ATM MIB|    |
          physical layer| (2) physical transmission types |  gr.1*|yes*|
          configuration | (3) operational status          |MIB II |    |
                        | (4) administrative status       |       |    |
                        | (5) last change status          |       |    |
          _____________________________________________________________
          ATM interface:| (1) active VPI/VCI fields       |ATM MIB|    |
          cell layer    | (2) maximum number of VPCs/VCCs |  gr.1 |yes |
          configuration | (3) configured VPCs/VCCs        |       | ** |
                        | (4) ILMI VPI/VCI values         |       |    |
                        | (5) ATM address type            |       |    |
                        | (6) ATM administrative address  |       |    |
          _____________________________________________________________
          ATM interface:|(1) received/transmitted cells   |       |    |
          cell layer    |(2) cells with HEC error         |MIB II |yes |
          performance   |(3) cell header validation errors|       |    |
          _____________________________________________________________
          ATM interface:|(1)DS3 PLCP severely errored     |ATM MIB|    |
          PLCP & TC     |   framing seconds               | gr.2,3|    |
          layer         |(2)DS3 PLCP unavailable seconds  |       |no  |
          performance   |(3)DS3 PLCP alarm state          |       |    |
                        |(4)out of cell delineation events|       |    |
                        |(5)TC alarm state                |       |    |
          _____________________________________________________________
          VP/VC link:   |(1)VPI or VPI/VCI value          |ATM MIB|    |
          configuration |(2)VCL or VPL operational status |  gr. 4|yes |
                        |(3)VCL/VPL administrative status |       |*** |
                        |(4)VCL/VPL last change status    |       |    |
                        |(5)transmit/receive traffic/QoS  |       |    |
                        |   parameters                    |       |    |
                        |(6)AAL type                      |       |    |
                        |(7)transmit/receive AAL5 SDU size|       |    |
                        |(8)AAL5 encapsulation type       |       |    |
          _____________________________________________________________

Top      ToC       Page 17 
          _____________________________________________________________
          VP/VC         |(1)cross-connect identifier      |       |    |
          Cross-connect:|(2)port identifier of one        |       |    |
          configuration |   end                           |       |    |
                        |(3)port identifier of the other  |ATM MIB|    |
                        |   end                           |  gr. 5|no  |
                        |(4)VPI or VPI/VCI value          |       |    |
                        |   of one end                    |       |    |
                        |(5)VPI or VPI/VCI value of       |       |    |
                        |   the other end                 |       |    |
                        |(6)VC/VP cross-connect           |       |    |
                        |   operational status            |       |    |
                        |(7)VC/VP cross-connect           |       |    |
                        |   administrative status         |       |    |
                        |(8)VC/VP last change status      |       |    |
          _____________________________________________________________
          VCC AAL5 CPCS |(1)PDUs discarded for CRC errors |ATM MIB|    |
          layer:        |(2)PDUs discarded due to         |  gr.6 |    |
          performance   |   reassembly time out           |       |no  |
                        |(3)PDUs discarded due to large   |       |    |
                        |   SDUs                          |       |    |
          _____________________________________________________________
          AAL5 entity:  |(1)received/transmitted PDUs     |       |    |
                        |(2)PDUs discarded due to         |       |    |
                        |   protocol errors               |MIB II |no  |
                        |(3)a set of configuration/state  |       |    |
                        |   parameters                    |       |    |
          _____________________________________________________________

          *The operational, administrative, and last change status of
          the ATM interface and the physical transmission type shall be
          supported by the interface table in MIB II (RFC 1213, RFC
          1573).  ILMI does not contain the administrative and last
          change status of the ATM interface.

          ** The ILMI MIB does not contain information on the ATM
          address type and the ATM administrative address assigned at
          the ATM interface.

          ***The ILMI MIB contains local and end-to-end operational
          status of the VPC/VCC segment.  However, it does not contain
          the VPC/VCC administrative and last change status and the VCC
          AAL information.


Next RFC Part