tech-invite   World Map     

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

RFC 2515

Proposed STD
Pages: 87
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ATOMMIB

Definitions of Managed Objects for ATM Management

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

Obsoletes:    1695


Top       ToC       Page 1 
Network Working Group                                 K. Tesink, Editor
Request for Comments: 2515                 Bell Communications Research
Obsoletes: 1695                                           February 1999
Category: Standards Track


                     Definitions of Managed Objects
                           for ATM Management

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

Table of Contents

   1 Abstract  .............................................    2
   2 The SNMP Network Management Framework .................    2
   3 ATM Terminology .......................................    3
   3.1 VCL/VPL and VCC/VPC .................................    3
   3.2 PVC, SVC and Soft PVC ...............................    5
   3.3 Traffic Management Parameters .......................    6
   3.3.1 Traffic Policing and Traffic Shaping  Parameters
        ....................................................    6
   3.3.2 Cell Loss Priority ................................    6
   3.3.3 QoS Class .........................................    6
   3.3.4 Service Category ..................................    7
   3.4 Max Active and Max Current VPI and VCI Bits .........    7
   4 Overview ..............................................    8
   4.1 Background ..........................................    8
   4.2 Structure of the MIB ................................    9
   4.3 ATM Interface Configuration Table ...................    9
   4.4 ATM Interface DS3 PLCP and TC Layer Tables ..........    9
   4.5 ATM Virtual Link and Cross-Connect Tables ...........    9
   5 Application of MIB II to ATM ..........................   10
   5.1 The System Group ....................................   10
   5.2 The Interface Group .................................   10
   5.2.1 Support of the ATM Cell Layer by ifTable ..........   10
   6 Support of the AAL3/4 Based Interfaces ................   12
   7 Support of the AAL5 Managed Objects ...................   12
   7.1 Managing AAL5 in a Switch ...........................   12

Top      ToC       Page 2 
   7.2 Managing AAL5 in a Host .............................   14
   7.3 Support of AAL5 by ifTable ..........................   15
   7.4 Support of Proprietary Virtual Interface  by  ifT-
        able ...............................................   16
   7.5 AAL5 Connection Performance Statistics Table ........   17
   8 ILMI MIBs and the ATM Managed Objects .................   18
   9 Definitions ...........................................   20
   10 Acknowledgments ......................................   83
   11 References ...........................................   83
   12 Security Considerations ..............................   85
   13 Author's Address .....................................   85
   14 Intellectual Property ................................   86
   15 Full Copyright Statement .............................   87

1.  Abstract

   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 replaces RFC 1695 [24].  Changes relative to RFC 1695 are
   summarized in the MIB module's REVISION clause.

   Textual Conventions used in this MIB are defined in [6] and [19].

2.  The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   0    An overall architecture, described in RFC 2271 [1].

   0    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 RFC
        1902 [5], RFC 1903 [6] and RFC 1904 [7].

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

Top      ToC       Page 3 
        The third version of the message protocol is called SNMPv3 and
        described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12].

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

   0    A set of fundamental applications described in RFC 2273 [14] and
        the view-based access control mechanism described in RFC 2275
        [15].

   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 (e.g., 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.

3.  ATM Terminology

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

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

Top      ToC       Page 4 
     <-----------------------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



     <-----------------------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 (or ATM switch) at one end of the VCC/VPC supports its
   end of the VCC/VPC plus the VCL or VPL on its external interface, and
   each switch through which the VCC/VPC passes supports the pair of
   VCLs/VPLs on its external interfaces as well as the cross-connection
   of those VCLs/VPLs. 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, service category 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.

3.2.  PVC, SVC and Soft PVC

   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.  A Soft PVC is a connection of which
   portions are switched, while other portions are permanent (see Figure
   3 and [22]).


       +--------+           +--------+           +--------+
    pvc|  ATM   |svc    svc |  ATM   |svc    svc |  ATM   |pvc
   ----| Switch |-----------| Switch |-----------| Switch |----
       +--------+           +--------+           +--------+

                  Figure 3: An example of a Soft PVC

Top      ToC       Page 6 
3.3.  Traffic Management Parameters

3.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 conceptually activated on an incoming VCL or VPL
   as shown in Figure 4.  The use of the traffic enforcer at the ingress
   of the connection is to make sure that the user traffic does not
   exceed the 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 4: 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, conceptually 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.

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

3.3.3.  QoS Class

   RFC1695 specified that one of a number of Quality of Service (QoS)
   classes is assigned to a VCC or VPC by associating the object
   atmTrafficQoSClass with each VCL or VPL.  However, new insights in
   ATM traffic management have caused this object to be deprecated.

Top      ToC       Page 7 
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)

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

Top      ToC       Page 9 
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-

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

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

Top      ToC       Page 12 
   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

Top      ToC       Page 13 
   AAL5 in a switch is modeled as shown in Figure 7 and 8.  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. Note that for the proprietary virtual interface
   the traffic transmit and receive conventions in the virtual channel
   link table are as follows:

      Transmitting traffic:  ATM Entity     --->  AAL5 Entity
      Receiving traffic:     ATM Entity     <---  AAL5 Entity

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

         Figure 7: Model of an AAL5 Entity in a Switch

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

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

7.2.  Managing AAL5 in a Host

   Managing AAL5 in a host involves managing the AAL5 sublayer interface
   as shown in Figure 9 and 10.  The AAL5 sublayer is stacked directly
   over the ATM sublayer.  The ifTable is applied to the AAL5 sublayer
   as defined in Section 10.3.

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

         Figure 9: Model of an AAL5 Entity in a Host

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

          Figure 10: AAL5 Entity's Interface Stack in a Host

Top      ToC       Page 15 
7.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 [21].  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 [17].

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

   ifLastChange    See [17].

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

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

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

Top      ToC       Page 17 
   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
            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 [17].  Set to 0 if the speed is not
            known.

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

   ifAdminStatus   See [17].

   ifOperStatus    See [17].

   ifLastChange    See [17].

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

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

   ifConnectorPresent  Set to false (2).

   ifLinkUpDownTrapEnable     Default is disabled (2).

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

7.5.  AAL5 Connection Performance Statistics Table

   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.

Top      ToC       Page 18 
8.  ILMI MIBs and the ATM Managed Objects

   The ILMI MIBs are specified by the ATM Forum as a set of several
   MIBs, all currently defined in the ILMI Specification [23]. The ILMI
   protocols and MIBs allow two connected ATM Interface Management
   Entities (IMEs) to exchange bi-directional parameters, mainly to
   facilitate auto-configuration between ATM peer entities.  The support
   of the ATM management functions by the ILMI MIBs and those contained
   in this memo are compared in Table 1.  In this table, "yes" in the
   "ILMI MIBs"  column indicates that the management functions are
   supported by the ILMI MIBs.  The parenthesized numbers in the "This
   memo" column correspond to the sets of tables enumerated in Section
   6.2.

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

                Table 1 - Structuring of ATM Managed Objects
   ______________________________________________________________
                 |                                 |This   |ILMI|
   ATM Mgmt.Inf. |ATM Managed Objects              |memo   |MIBs|
   ______________|_________________________________|_______|____|

   Local Interface Information:
   _____________________________________________________________
   ATM interface:| (1) port identifier             |ATM MIB|    |
   physical layer| (2) physical transmission types |   (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 |   (1) |yes |
   configuration | (3) configured VPCs/VCCs        |       | ** |
                 | (4) ILMI VPI/VCI values         |       |    |
                 | (5) Neighbor system info        |       |    |
                 | (6) Max. number of VPI/VCI bits |       |yes |
                 | (7) ATM Subscribed Address      |       |    |
   _____________________________________________________________
   ATM interface:|(1) received/transmitted cells   |       |    |
   cell layer    |(2) cells with HEC error         |MIB II |yes |
   performance   |(3) cell header validation errors|       |    |
   _____________________________________________________________

Top      ToC       Page 19 
   _____________________________________________________________
   ATM interface:|(1)DS3 PLCP severely errored     |ATM MIB|    |
   PLCP & TC     |   framing seconds               |    (2)|    |
   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 |  (3,4)|yes |
                 |(3)VCL/VPL administrative status |       |*** |
                 |(4)VCL/VPL last change status    |       |    |
                 |(5)transmit/receive traffic/     |       |    |
                 |   service category parameters   |       |    |
                 |(6)AAL type                      |       |    |
                 |(7)transmit/receive AAL5 SDU size|       |    |
                 |(8)AAL5 encapsulation type       |       |    |
                 |(9)connection topology type      |       |    |
                 |(10)use of call control          |       |    |
   _____________________________________________________________
   VP/VC         |(1)cross-connect identifier      |       |    |
   Cross-connect:|(2)port identifier of one        |       |    |
   configuration |   end                           |       |    |
                 |(3)port identifier of the other  |ATM MIB|    |
                 |   end                           |    (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         |   (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                    |       |    |
   _____________________________________________________________

Top      ToC       Page 20 
   *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 [16][17].  ILMI does not contain the
   administrative and last change status of the ATM interface.

   ** The ILMI MIB contains read-only objects for various parameters at
   the ATM interface level.

   ***The ILMI MIBs contain 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.



(page 20 continued on part 2)

Next RFC Part