tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3606

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

Definitions of Supplemental Managed Objects for ATM Interface

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

 


Top       ToC       Page 1 
Network Working Group                                              F. Ly
Request for Comments: 3606                             Pedestal Networks
Category: Standards Track                                        M. Noto
                                                           Cisco Systems
                                                                A. Smith
                                                              Consultant
                                                              E. Spiegel
                                                           Cisco Systems
                                                               K. Tesink
                                                  Telcordia Technologies
                                                           November 2003


     Definitions of Supplemental Managed Objects for ATM Interface

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

Abstract

   This memo defines objects used for managing ATM-based interfaces,
   devices, and services, in addition to those defined in RFC 2515, the
   ATM-MIB, to provide additional support for the management of ATM
   Switched Virtual Connections (SVCs) and ATM Permanent Virtual
   Connections (PVCs).

Top       Page 2 
Table of Contents

   1.  The Internet-Standard Management Framework. . . . . . . . .   3
   2.  Overview. . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Background. . . . . . . . . . . . . . . . . . . . . .   3
       2.2.  Important Definitions . . . . . . . . . . . . . . . .   4
   3.  Conventions used in the MIB . . . . . . . . . . . . . . . .   6
       3.1.  Structure . . . . . . . . . . . . . . . . . . . . . .   6
             3.1.1.  ATM SVC VP Cross-Connect Table. . . . . . . .   6
             3.1.2.  ATM SVC VC Cross-Connect Table. . . . . . . .   7
             3.1.3.  ATM Interface Signalling Statistics Table . .   8
             3.1.4.  ATM Signalling Capability Support . . . . . .   9
             3.1.5.  Signalling Descriptor Parameter Table . . . .  10
             3.1.6.  ATM Interface Registered Address Table. . . .  10
             3.1.7.  ATM VPI/VCI to Address Mapping Table. . . . .  11
             3.1.8.  ATM Address to VPI/VCI Mapping Table. . . . .  11
             3.1.9.  ATM VPL Statistics Table. . . . . . . . . . .  11
             3.1.10. ATM VPL Logical Port Table. . . . . . . . . .  12
             3.1.11. ATM VCL Statistics Table. . . . . . . . . . .  15
             3.1.12. ATM VC General Information Table. . . . . . .  15
             3.1.13. ATM Interface Configuration Extension Table .  16
             3.1.14. ATM ILMI Service Registry Table . . . . . . .  17
             3.1.15. ILMI Network Prefix Table . . . . . . . . . .  19
             3.1.16. ATM Switch Address Table. . . . . . . . . . .  19
             3.1.17. AAL5 per-VCC Statistics Table . . . . . . . .  19
             3.1.18. ATM VP Cross-Connect Extension Table. . . . .  20
             3.1.19. ATM VC Cross-Connect Extension Table. . . . .  20
             3.1.20. Currently Failing PVPL Table. . . . . . . . .  20
             3.1.21. Currently Failing PVCL Table. . . . . . . . .  20
             3.1.22. Leaf Initiated Join Counter support . . . . .  20
       3.2.  Network and User Addresses. . . . . . . . . . . . . .  20
       3.3.  Configuration of VPLs, VCLs, and Cross-Connects . . .  20
       3.4.  ATM-related Trap Support. . . . . . . . . . . . . . .  20
   4.  Conformance and Compliance. . . . . . . . . . . . . . . . .  21
   5.  Definitions . . . . . . . . . . . . . . . . . . . . . . . .  21
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  89
   7.  References. . . . . . . . . . . . . . . . . . . . . . . . .  89
       7.1.  Normative References. . . . . . . . . . . . . . . . .  89
       7.2.  Informative References. . . . . . . . . . . . . . . .  90
   8.  Security Considerations . . . . . . . . . . . . . . . . . .  90
   9.  Intellectual Property Statement . . . . . . . . . . . . . .  92
   10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . .  93
   11. Full Copyright Statement. . . . . . . . . . . . . . . . . .  94

Top      ToC       Page 3 
1.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

2.  Overview

   The purpose of this memo is to provide additional capabilities, not
   found in the ATM-MIB [RFC2515], which are needed to manage ATM
   interfaces.  This memo addresses the following areas:

   -  ATM Switch Support
   -  ATM Service Support
   -  ATM Host Support

   In addition, this memo also provides ATM trap support.

2.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
   ([RFC2863]), the DS3 ([RFC2496]) or SONET MIBs ([RFC3592]) for
   management of SONET and DS3 physical interfaces, and, as appropriate,
   MIB modules for applications that make use of ATM, such as SMDS
   [RFC1694] and LAN Emulation [ATM Forum LANE].  These MIB modules are
   outside the scope of this specification.

   This MIB module also requires the use of the ATM-MIB module defined
   in [RFC2515] and ATM-specific textual conventions defined in
   [RFC2514].

   ATM Endpoint applications such as ATM LAN Emulation or Classical IP-
   over-ATM Clients and Servers use ATM to establish SVC/PVC connections
   for exchanging control and data information.  The agents of these ATM
   applications must provide the network manager with information on the
   SVC/PVCs in use and which applications are using them.  The
   information can be made generic so as to apply to all ATM

Top      ToC       Page 4 
   applications.  This memo defines extensions to the ATM-MIB [RFC2515]
   in order to support this.

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

2.2.  Important Definitions

   The following terms are defined here and used throughout this MIB:

   -  Virtual Path Link (VPL)
   -  Virtual Path Connection (VPC)
   -  Virtual Path Segment (VP Segment)
   -  Virtual Channel Link (VCL)
   -  Virtual Channel Connection (VCC)
   -  Virtual Channel Segment (VC Segment).

   The figures on the next page show how these terms apply in typical
   ATM network topologies.  Additional terms relevant to this MIB are
   defined and illustrated in the ATM Terminology section 3 of
   [RFC2515].

    _____      _______      _______      _______      _____
   |     |____|       |____|       |____|       |____|     |
   |Host1|    |SwitchA|    |SwitchB|    |SwitchC|    |Host2|
   |     |____|       |____|       |____|       |____|     |
   |_____|    |_______|    |_______|    |_______|    |_____|

         |<-->|                    |<-->|
    Virtual Path Link         Virtual Path Link

         |<----------------------------------------->|
                     Virtual Path Connection
                    (between Host1 and Host2)

                      |<--------------->|
                      Virtual Path Segment
                 (between SwitchA and SwitchC)

   Figure 1: Examples of Virtual Path Links, Virtual Path
             Connection, and Virtual Path Segment

Top      ToC       Page 5 
    _____      _______      _______      _______      _____
   |     |____|       |____|       |____|       |____|     |
   |Host1|----|SwitchA|----|SwitchB|----|SwitchC|----|Host2|
   |     |____|       |____|       |____|       |____|     |
   |_____|    |_______|    |_______|    |_______|    |_____|

         |<-->|                    |<-->|
   Virtual Channel Link      Virtual Channel Link

         |<----------------------------------------->|
                   Virtual Channel Connection
                   (between Host1 and Host2)

                      |<--------------->|
                    Virtual Channel Segment
                 (between SwitchA and SwitchC)

   Figure 2: Examples of Virtual Channel Links, Virtual
             Channel Connection, and Virtual Channel Segment

Top      ToC       Page 6 
3.  Conventions used in the MIB

3.1.  Structure

   The managed ATM objects are arranged as follows:

     Table                         Host   Switch Service
   _____________________________________________________
   atmSvcVcCrossConnectTable      |      |  Y   |  Y   |
   atmSvcVpCrossConnectTable      |      |  Y   |  Y   |

   atmSigStatTable                |  Y   |  Y   |  Y   |
   atmSigSupportTable             |      |  Y   |  Y   |
   atmSigDescrParamTable          |  Y   |      |      |

   atmIfRegisteredAddrTable       |      |  Y   |  Y   |
   atmVclAddrTable                |  Y   |      |      |
   atmAddrVclTable                |  Y   |      |      |

   atmVplStatTable                |  Y   |  Y   |  Y   |
   atmVplLogicalPortTable         |  Y   |  Y   |  Y   |

   atmVclStatTable                |  Y   |  Y   |  Y   |
   atmAal5VclStatTable            |  Y   |      |      |
   atmVclGenTable                 |  Y   |      |      |

   atmInterfaceExtTable           |  Y   |  Y   |  Y   |

   atmIlmiSrvcRegTable            |      |  Y   |  Y   |
   atmIlmiNetworkPrefixTable      |      |  Y   |  Y   |
   atmSwitchAddressTable          |      |  Y   |      |

   atmVpCrossConnectXTable        |      |      |  Y   |
   atmVcCrossConnectXTable        |      |      |  Y   |

   atmCurrentlyFailingPVplTable   |  Y   |  Y   |  Y   |
   atmCurrentlyFailingPVclTable   |  Y   |  Y   |  Y   |

   Table 1: MIB structure

3.1.1.  ATM SVC VP Cross-Connect Table

   This table provides the SVC VP Cross-Connect (SVPC) information.  The
   equivalent PVC VP Cross-Connect table is defined in [RFC2515].  This
   table also includes cross-connect information for Soft PVPs.

Top      ToC       Page 7 
   This table contains configuration and state information of all SVC VP
   point-to-point, point-to-multipoint, or multipoint-to-multipoint VP
   cross-connects.

   This table has read-only access and can be used to monitor the
   cross-connects which connect the VPLs together in an ATM switch or
   network.  The atmSvcVpCrossConnectIndex is used to associate the
   related SVC VPLs that are cross-connected together.  The
   atmSvcVpCrossConnectRowStatus object has read-write access to allow
   for tear-down.

   The ATM SVC VP Cross-Connect Table models each bi-directional
   Switched Virtual Circuit (SVC) VP cross-connect as a set of entries
   in the atmSvcVpCrossConnectTable.  A point-to-point VPC cross-connect
   is modeled as one entry; a point-to-multipoint (N leafs) VPC cross-
   connect as N entries in this table; and a multipoint-to-multipoint (N
   parties) VPC cross-connect as N(N-1)/2 entries in this table.  In the
   latter cases, all the N (or N(N-1)/2) entries are associated with a
   single VPC cross-connect by having the same value of
   atmSvcVpCrossConnectIndex.

        _________________________________________
        |                                       |
    Low |         ATM Switch or Network         | High
    port|                                       | port
   _____|>> from low to high VPC traffic flow >>|______
        |<< from high to low VPC traffic flow <<|
        |_______________________________________|

   Figure 3: VPC Cross-Connect Model

   The terms low and high are chosen to represent numerical ordering of
   the two interfaces associated with a VPC cross-connect.  That is, the
   ATM interface with the lower value of ifIndex is termed 'low', while
   the other ATM interface associated with the VPC cross-connect is
   termed 'high'.

3.1.2.  ATM SVC VC Cross-Connect Table

   This table provides the SVC Cross-Connect (SVCC) information.  The
   equivalent PVC VC Cross-Connect table is defined in [RFC2515].  This
   table also includes cross-connect information for Soft PVCs.

   This table is used to model a bi-directional point-to-point, point-
   to-multipoint or multipoint-to-multipoint SVC VC cross-connect.

Top      ToC       Page 8 
   This table has read-only access and is used to monitor the cross-
   connects which connect the VCLs together in an ATM switch or network
   that belong to a VC connection.  The atmSvcVcCrossConnectIndex is
   used to associate the related SVC VCLs that are cross-connected
   together.  The atmSvcVcCrossConnectRowStatus object has read-write
   access to allow for tear-down.

   The ATM SVC VC Cross-Connect Table models each bi-directional
   Switched Virtual Circuit (SVC) VC cross-connect as a set of entries
   in the atmSvcVcCrossConnectTable.  A point-to-point VC cross-connect
   is modeled as one entry; a point-to-multipoint (N leafs) VC cross-
   connect as N entries in this table; and a multipoint-to-multipoint (N
   parties) VPC cross-connect as N(N-1)/2 entries in this table.  In the
   latter cases, all the N (or N(N-1)/2) entries are associated with a
   single VPC cross-connect by having the same value of
   atmSvcVcCrossConnectIndex.

         ______________________________________
        |                                      |
    Low |         ATM Switch or Network        | High
    port|                                      | port
   _____|>> from low to high VC traffic flow >>|______
        |<< from high to low VC traffic flow <<|
        |______________________________________|

   Figure 4: VC Cross-Connect Model

   The terms low and high are chosen to represent numerical ordering of
   the two interfaces associated with a VPC cross-connect.  That is, the
   ATM interface with the lower value of ifIndex is termed 'low', while
   the other ATM interface associated with the VPC cross-connect is
   termed 'high'.

3.1.3.  ATM Interface Signalling Statistics Table

   This table provides statistical information of the signalling entity.
   A signalling entity can be deployed over an ATM interface as defined
   in the atmInterfaceConfTable [RFC2515], a logical ATM interface
   defined in section 5.1.10.1 in this document, or a proprietary
   virtual interface as described in the atmInterfaceExtTable.  To
   monitor the signalling entity, a few counters are provided.  They are
   defined as:

      atmSigSSCOPConEvents
      atmSigSSCOPErrdPdus
      atmSigDetectSetupAttempts
      atmSigEmitSetupAttempts
      atmSigDetectUnavailRoutes

Top      ToC       Page 9 
      atmSigEmitUnavailRoutes
      atmSigDetectUnavailResrcs
      atmSigEmitUnavailResrcs
      atmSigDetectCldPtyEvents
      atmSigEmitCldPtyEvents
      atmSigDetectMsgErrors
      atmSigEmitMsgErrors
      atmSigDetectClgPtyEvents
      atmSigEmitClgPtyEvents
      atmSigDetectTimerExpireds
      atmSigEmitTimerExpireds
      atmSigDetectRestarts
      atmSigEmitRestarts
      atmSigInEstabls
      atmSigOutEstabls

3.1.4.  ATM Signalling Capability Support

   A number of Information Elements may or may not be supported by ATM
   switches or ATM Services.  Hence, for trouble isolation it is
   important to keep track which particular Information Elements are
   supported.  The corresponding group of objects must be supported by
   switches or services supporting SVCs, and indicate whether the
   following Information Elements are enabled/disabled:

   1) Calling party number

   2) Calling party subaddress

   3) Called party subaddress

   4) Broadband high layer information

   5) Broadband low layer information

   6) Broadband Repeat Indicator

   7) AAL parameters

   The last parameter, Preferred Carrier Pre-Subscription, identifies
   the carrier to which intercarrier calls originated from this
   interface are routed when transit network selection information is
   not provided by the calling party.

Top      ToC       Page 10 
3.1.5.  Signalling Descriptor Parameter Table

   This table extends the ATM VCL table of the ATM-MIB [RFC2515] to
   include all other necessary signalling information as specified in
   the ATM Forum UNI Specifications [ATM Forum 3.0] and [ATM Forum UNI
   3.1].  A user can create an entry with all signalling parameters and
   later use that entry to specify the signalling characteristics of
   SVCs.

   Some of the signalling parameters, such as the AAL5 parameters
   information element, are reflected in the VCL and VPL tables, and
   this table only contains the remaining AAL5 parameters.

   Signalling attributes can be grouped into following categories:

   1) ATM Adaptation Layer Parameters

      Information in this group is captured in the ATM Signalling
      Descriptor Parameter Table defined in this memo.  Please refer to
      section 5.4.5.5 of [ATM Forum 3.0] and [ATM Forum UNI 3.1].

   2) Broadband High Layer Information

      Information in this group is captured by the ATM Signalling
      Descriptor Parameter Table defined in this memo.  Please refer to
      section 5.4.5.8 of [ATM Forum 3.0] and [ATM Forum UNI 3.1].

   3) Broadband Low Layer Information

      Information in this group is captured by the ATM Signalling
      Descriptor Parameter Table defined in this memo.  Please refer to
      section 5.4.5.9 of [ATM Forum 3.0] and [ATM Forum UNI 3.1].

3.1.6.  ATM Interface Registered Address Table

   This table contains a list of ATM addresses that can be used for
   calls to and from a given interface by a switch or service.  The ATM
   addresses are either registered by the endsystem via ILMI or
   statically configured.  This table does not expose PNNI reachability
   information.  This table only applies to switches and network
   services.  See also Section 5.2.

Top      ToC       Page 11 
3.1.7.  ATM VPI/VCI to Address Mapping Table

   In the atmVclAddrTable, the object atmVclAddrAddr can either be an
   ATM Local Address or an ATM Remote Address which represent the two
   endpoint addresses of a VCL.  ATM Local Address identifies the local
   endpoint of the VCL represented by this agent.  The ATM Remote
   address represents the address of the ATM application at the other
   end of the VCL.

3.1.8.  ATM Address to VPI/VCI Mapping Table

   This table provides an alternative way to retrieve the atmVclTable.
   This table can be used to retrieve the indexing to the atmVclTable by
   an ATM address.

3.1.9.  ATM VPL Statistics Table

   The atmVplStatTable includes per-VPL cell counters.  The VPL cell
   counters count the valid ATM cells.  The valid ATM cells include the
   user and OAM cells but exclude the physical layer (e.g., idle cells)
   and unassigned cells.  Cells coming into an ATM managed system are
   counted differently with the high Cell Loss Priority (CLP=0) or low
   Cell Loss Priority (CLP=1).  The cells are tagged, passed or
   discarded depending on the incoming CLP value and the policed cell
   rate by the "traffic policing" entity in the ATM managed system.
   Refer to [ATM Forum 3.0] and [ATM Forum UNI 3.1] for a description of
   the traffic policing.

   In the switch where the traffic policing is not supported, cells are
   passed or discarded depending on the bandwidth and buffering capacity
   of the switching fabric.  The Output Tagged Cells counter, in this
   case, is always zero.
                 _______________
                 | ATM Managed |
      Input      | System      | Output
      CLP=0 cells|             | CLP=0 cells
      ---------->|             |----------->
      CLP=1 cells| (traffic    | CLP=1 cells
      ---------->| policing    |----------->
                 | entity)     | Tagged cells (CLP=1)
                 |_____________|----------->
                  |Discard  | Discard
                  |CLP=0    | CLP=1
                  |cells    | cells
                  |         |
                  V         V

   Figure 5: ATM Cell Counters per VPL

Top      ToC       Page 12 
   In this table, cells coming into and out of the managed ATM system
   are counted as the total number of cells and the cells with the
   CLP=0.  The CLP=1 counter is derived by subtracting CLP=0 cells from
   the total cells.  In addition, cells that are tagged on the output
   are also counted.  The output CLP=1 cells equals the total cells out
   count minus both the CLP=0 cells and the tagged cells.

3.1.10.  ATM VPL Logical Port Table

   The ATM VPL Logical Port Table includes all ATM logical port
   interface configuration information.

3.1.10.1.  ATM Logical Port Interface

   The interface type "ATM Logical Port" (ifType=80) is defined to allow
   the representation of a VP Tunnel, which is a VPL used as a trunk
   connection (most likely between devices that are not physically
   adjacent), providing for multiplexing and demultiplexing of VCs on
   the VP.  Figure 6 illustrates such a VP Tunnel.

   Note: the "ATM Logical Port" interface is more of a logical port,
   compared with an interface of type "ATM" which is more of a physical
   port that provides for the transport of many VP and VC connections
   between adjacent devices.

                       <------VP Tunnel------>
                 ATM Switch A             ATM Switch B
                ------------             -----------
                |ATM       |_____________|ATM       |
                |X-Connect |      .      |X-Connect |
         VCL1   |Point     | VPL1 . VPL2 |Point     |  VCL4
      O---------|----X-----|----- . -----|----X-----|-----O
                |    X-----|----- . -----|----X     |
                |    |     |_____________|    |     |
                ------------             ------------
                     | VCL2                   | VCL3
                     O                        O

   Figure 6: Virtual Path Tunnel

   In Figure 6, a VP tunnel (denoted as VPL1 by Switch A, and as VPL2 by
   Switch B) is used to connect VCL1 with VCL4 and VCL2 with VCL3.
   Figure 6 shows only one VP tunnel, but there can be multiple VP
   tunnels over the same physical interface.

Top      ToC       Page 13 
   A particularly useful VP tunnel scenario is tunneling across a public
   network that does not support signalling.  In Figure 6 above, assume
   Switches A and B are private switches that signal over the VP to set
   up connections transparently through the public network.  The public
   network would just transport a PVC VP between the two switches.

   Because the VP Tunnel constitutes an interface between two ATM
   devices that are not necessarily physically adjacent, most of the
   management information pertaining to the interface may differ for the
   tunnel, including:

   -  active VPI/VCI fields (the tunnel may be a subset of the parent
      interface).
   -  maximum number of VCCs
   -  configured VCCs
   -  ILMI VPI/VCI values
   -  ATM address type
   -  ATM administrative address
   -  received/transmitted cells.

3.1.10.2.  How to create an ATM Logical Port interface

      On ATM devices supporting VP tunnels, the ATM Logical Port
      Interface Table can be used to create VP tunnels.  To create an
      ATM Logical Port interface via SNMP:

         - Create a VPL (e.g., VPI=a on an existing ATM interface
           which has ifIndex=x) in the atmVplTable.

         - Set the object atmVplLogicalPortDef to isLogicalIf.
           A new row in the ifTable is then created by the agent,
           with ifIndex=y, to represent the ATM Logical Port
           interface.  The object atmVplLogicalPortIndex is also
           set to y by the agent to represent the ifIndex value of
           the ATM Logical Port interface.

         - The ifEntry values are set for the ATM Logical
           Port interface (ifIndex=y) as discussed in RFC
           2515, with the following exceptions:
               * ifType - a new enumerated value of atmLogical(80)
                 was added to IANAifType, specifying an "ATM
                 Logical Port" interface.
               * ifSpeed - The total bandwidth in bits per
                 second for use by the ATM layer.  Computed
                 from the traffic descriptor for the VPL.

Top      ToC       Page 14 
               * ifOperStatus - determined hierarchically,
                 depending on the state of the physical
                 atm-cell layer interface beneath it,
                 and the ILMI on the VP.
            * ifInOctets, ifOutOctets - support of
              these objects is not mandatory for ATM
              Logical Port interfaces.
            * ifInErrors - always zero, HEC errors are
              specified for the atm cell-layer interface
              beneath it.
            * ifInUnknownProtos - always zero, errors
              are specified for the atm cell-layer
              interface beneath it.

      - The atmInterfaceConfEntry values are set and reported
        as discussed in [RFC2515], with the following exceptions:
            * atmInterfaceMaxVpcs - 0.
            * atmInterfaceConfVpcs - 0.
            * atmInterfaceIlmiVpi - VPI of the VP tunnel.

      - The atmInterfaceExtEntry values are set and reported
        as follows:
            * atmInterfaceConfMaxSvpcVpi - VPI of the VP tunnel,
              although VPCs cannot be setup on a VP tunnel.
            * atmInterfaceCurrentMaxSvpcVpi - VPI of VP tunnel,
              although VPCs cannot be setup on a VP tunnel.
            * atmInterfaceConfMaxSvccVpi - VPI of the VP tunnel.
            * atmInterfaceCurrentMaxSvccVpi - VPI of VP tunnel.
            * atmIntfPvcFailures - Includes failures of PVCLs
              within the VP tunnel, but not of the PVPL itself,
              since those are reported on the atm(37) interface.
            * atmIntfCurrentlyFailingPVpls - 0.
            * atmIntfPvcFailuresTrapEnable - Enables traps for
              PVCL failures within the VP tunnel, but not for
              the PVPL itself, since the latter are generated on
              behalf of the atm(37) interface.

      - An entry is created in the ifStackTable, with
        values: ifStackHigherLayer=y, ifStackLowerLayer=x.

      - VCLs defined on the VP tunnel are indexed by
        ifIndex=y, VPI=a, VCI.

Top      ToC       Page 15 
3.1.11.  ATM VCL Statistics Table

      The atmVclStatTable includes per-VCL cell counters.  The VCL cell
      counters count the valid ATM cells.  The valid ATM cells include
      the user and OAM cells but exclude the physical layer (e.g., idle
      cells) and unassigned cells.  Cells coming into an ATM managed
      system are counted differently with the high Cell Loss Priority
      (CLP=0) or low Cell Loss Priority (CLP=1).  The cells are tagged,
      passed or discarded depending on the incoming CLP value and the
      policed cell rate by the "traffic policing" entity in the ATM
      managed system.  Refer to [ATM Forum 3.0] and [ATM Forum UNI 3.1]
      for the description of the traffic policing.

      In a switch where the traffic policing is not supported, cells are
      passed or discarded depending on the bandwidth and buffering
      capacity of the switching fabric.  The Output Tagged Cells
      counter, in this case, is always zero.

                 _______________
                 | ATM Managed |
      Input      | System      | Output
      CLP=0 cells|             | CLP=0 cells
      ---------->|             |----------->
      CLP=1 cells| (traffic    | CLP=1 cells
      ---------->| policing    |----------->
                 | entity)     | Tagged cells (CLP=1)
                 |_____________|----------->
                  |Discard  | Discard
                  |CLP=0    | CLP=1
                  |cells    | cells
                  |         |
                  V         V

   Figure 7: ATM Cell Counters per VCL

   In this table, cells coming into and out of the managed ATM system
   are counted as the total number of cells and the cells with the
   CLP=0.  The CLP=1 counter is derived by subtracting CLP=0 cells from
   the total cells.  In addition, cells that are tagged on the output
   are also counted.  The output CLP=1 cells equals the total cells out
   count minus both the CLP=0 cells and the tagged cells.

3.1.12.  ATM VC General Information Table

   This table contains the general information for each VC.  It provides
   an index to the atmSigDescrParamTable defined in this MIB.  This
   table is an extension to the atmVclTable defined in the ATM-MIB
   [RFC2515].

Top      ToC       Page 16 
3.1.13.  ATM Interface Configuration Extension Table

   The ATM Interface Configuration Extension Table contains ATM
   interface information that supplements the atmInterfaceConfTable
   defined in [RFC2515].  It includes the configuration information of
   the interface type (i.e., connection setup procedures) and ILMI.

   A network manager can configure the interface to run a specific type
   of connection setup procedures (i.e., protocol and version) such as
   ITU-T DSS2, ATM Forum UNI 3.1, PNNI 1.0 or BICI 2.0.  It can also
   dictate the role of the managed entity as one side of the interface.
   For example, if an interface is configured to run ATM Forum UNI 3.1,
   the managed entity has to be told to run as either the network side
   or the user side of the UNI.

   The objects atmIntfConfigType and atmIntfConfigSide are used for
   configuration and the objects atmIntfActualType and atmIntfActualSide
   are used for reading back the actual interface protocol and version.

   The following table describes all the valid combinations of
   configuration of the interface type and side.  Note that the value
   N/A meaning not applicable, should be set to the value other(1) when
   used.

      atmIntfConfigType          atmIntfConfigSide
      -----------------          -----------------
      autoConfig                 N/A
      ituDss2                    user/network
      atmfUni3Dot0               user/network
      atmfUni3Dot1               user/network
      atmfUni4Dot0               user/network
      atmfIispUni3Dot0           user/network
      atmfIispUni3Dot1           user/network
      atmfIispUni4Dot0           user/network
      atmfPnni1Dot0              N/A
      atmfBici2Dot0              N/A
      atmfUniPvcOnly             user/network
      atmfNniPvcOnly             N/A

   When the value of the object atmIntfConfigType is configured to
   autoConfig(2), the interface type is determined via the ATM Forum
   ILMI auto-configuration procedures [ATM Forum ILMI].  There is no
   need to set the interface side since it should be a derived value.
   The PNNI and BICI interfaces are always symmetric so setting the
   interface side is also not necessary.

Top      ToC       Page 17 
   This table also includes the configured and negotiated maximum VPI
   value per ATM interface, and the configured and negotiated minimum
   VCI value per ATM interface.  Refer to [ATM Forum ILMI] Sections
   8.2.3.8 through 8.2.3.10 for a detailed description.

   The following figure provides an example how the current minimum VCI
   values are derived from the configured minimum VCI values and the
   neighboring minimum VCI values:

   +--------+              +--------+              +--------+
   |  ATM   | ifA      ifB |  ATM   | ifC      ifD |  ATM   |
   | Device |--------------| Device |--------------| Device |
   +--------+              +--------+              +--------+


        ifA:  Configured Min SVCC VCI = 32  (configured)
              Current Min SVCC VCI    = 40  (negotiated)

        ifB:  Configured Min SVCC VCI = 40  (configured)
              Current Min SVCC VCI    = 40  (negotiated)

        ifC:  Configured Min SVCC VCI = 32  (configured)
              Current Min SVCC VCI    = 32  (negotiated)

        ifD:  Configured Min SVCC VCI = 32  (configured)
              Current Min SVCC VCI    = 32  (negotiated)

   Between ifA and ifB, the maximum of the two vales for
   atmInterfaceConfMinSvccVci is 40, so both interfaces set their
   atmInterfaceCurrentMinSvccVci values to 40.  On the other hand, since
   ifC and ifD both are configured with atmInterfaceConfMinSvccVci
   values of 32, they set their atmInterfaceCurrentMinSvccVci values to
   32.

   Figure 8: Examples of configured vs. negotiated ILMI values

3.1.14.  ATM ILMI Service Registry Table

   This table contains information used by the switch/service to inform
   ATM hosts of the location of ATM network services such as the LAN
   Emulation Configuration Server (LECS), the ATM Name Server (ANS), the
   ATMARP Server, the Multicast Address Resolution Server (MARS), and
   the NHRP Server (NHS).  Entries in this table are exported to
   adjacent devices via ILMI over either all or a few user selected ATM
   interfaces.

Top      ToC       Page 18 
   As an example, let's assume that:

   -  An ATM switch X has three interfaces if1, if2 and if3.
   -  There are two ATM network services offered, a1.a2...aN and
      b1.b2...bN, where a1.a2...aN is an object identifier used to
      identify the first service, and b1.b2...bN is the object
      identifier for the other service.
   -  The first service is available at the ATM address 'a'.
   -  The second service is available at the ATM address 'b'.
   -  The first service can be used by any device connecting to the
      switch X.
   -  The second service can be used only by devices that connect to
      interfaces if1 and if3 on switch X.

     +------------------+    +------------------+
     |service a1.a2...aN|    |service b1.b2...bN|
     |                  |    |                  |
     | ATM address = a  |    | ATM address = b  |
     +--------+---------+    +--------+---------+
              |                       |
              |                       |
     +--------+-----------------------+---------+
     |             ATM NETWORK                  |
     +-----------------+------------------------+
                       |
                       |
                +-------------+
                |  switch X   |
                +-+----+----+-+
                  |    |    |
                  |    |    |
                 if1  if2  if3   (interfaces)

       Figure 9: ATM topology with registered services

   The table for switch X will contain three entries:

    - one entry for the "a1.a2...aN", implicitly available to any
      devices on switch X.
    - two entries for the "b1.b2...bN" (one for each interface
      where this service can be explicitly used).

Top      ToC       Page 19 
   The content of the table is:

    - Service Identifier:   a1.a2...aN    b1.b2...bN   b1.b2...bN
    - ATM address:              a             b            b
    - Arbitrary index:          m             n            p
    - Available interface:      0             1            3

   where the Service Identifier values a1.a2...aN and b1.b2...bN are
   represented by atmIlmiSrvcRegServiceID, the ATM addresses a and b are
   represented by atmIlmiSrvcRegATMAddress, the values m, n, and p are
   arbitrary non-zero integer parameters (necessary in this example to
   differentiate the two entries for b1.b2...bN that are both available
   at the ATM address 'b') represented by atmIlmiSrvcRegAddressIndex,
   and the available interfaces are represented by atmIlmiSrvcRegIndex,
   where the special value 0 indicates any ATM interface.

   When querying the ILMI service registry table, through the ILMI
   protocol:

   -  the device attached to interface if1 will obtain the address a and
      b.

   -  the device attached to interface if2 will obtain the address a
      only.

   -  the device attached to interface if3 will obtain the address a and
      b.

3.1.15.  ILMI Network Prefix Table

   A table specifying per-interface network prefix(es) supplied by the
   network side of the UNI during ILMI address registration.  When no
   network prefixes are specified for a particular interface, one or
   more network prefixes based on the switch address(es) may be used for
   ILMI address registration.

3.1.16.  ATM Switch Address Table

   This table contains one or more ATM endsystem addresses on a per-
   switch basis.  These addresses are used to identify the switch.  When
   no ILMI network prefixes are configured for certain interfaces,
   network prefixes based on the switch address(es) may be used for ILMI
   address registration.

3.1.17.  AAL5 per-VCC Statistics Table

   This table contains the AAL5 statistics for the VCCs.

Top      ToC       Page 20 
3.1.18.  ATM VP Cross-Connect Extension Table

   This table extends the atmVpCrossConnectTable defined in ATM-MIB
   [RFC2515].

3.1.19.  ATM VC Cross-Connect Extension Table

   This table extends the atmVcCrossConnectTable defined in ATM-MIB
   [RFC2515].

3.1.20.  Currently Failing PVPL Table

   This table contains all the PVPLs that are in trouble.

3.1.21.  Currently Failing PVCL Table

   This table contains all the PVCLs that are in trouble.

3.1.22.  Leaf Initiated Join Counter support

   Two counter objects are added to count the number of leaf intiated
   setup requests and setup failures.

3.2.  Network and User Addresses

   At the user side of a given ATM UNI interface there may be an
   address, "ifPhysAddress", to identify the interface.  In addition,
   there may be several other addresses which can be used to originate
   and receive calls.  These other addresses that are used to receive
   calls are listed in the "ifRcvAddrTable" defined in RFC 2863.  The
   registered addresses on the network side are listed in the ATM
   Registered Address Table.  The ATM Registered Address Table is
   supported by switches and network services.  It is not supported by
   hosts.

3.3.  Configuration of VPLs, VCLs, and Cross-Connects

   The ATM Managed Objects needed to support the configuration of VPLs,
   VCLs, and Cross-Connects of the Permanent VPLs and VCLs are defined
   in the ATM-MIB [RFC2515].  Cross-Connects of the Switched VPLs and
   VCLs are defined in this memo.

3.4.  ATM-related Trap Support

   Traps are defined to detect changes in the status of permanent VPLs
   and VCLs.  The current up/down status of each permanent VPL or VCL is
   indicated by the atmVplOperStatus or atmVclOperStatus object,
   respectively.  Several tables and objects and one trap are defined in

Top      ToC       Page 21 
   order to help network managers quickly and efficiently detect changes
   in the status of permanent virtual links.  Through use of these
   tables, objects, and traps, the time consuming and resource intensive
   task of continuously polling each row in the entire atmVplTable and
   atmVclTable can be avoided.

   The atmIntfPvcFailures counter and the atmIntfCurrentlyFailingPVpls
   and atmIntfCurrentlyFailingPVcls gauges provide a quick means of
   determining the status of all PVPLs and PVCLs on an interface.  The
   atmCurrentlyFailingPVplTable and the atmCurrentlyFailingPVclTable
   list all of the problematic PVPLs and PVCLs, respectively, allowing
   them to be quickly identified.

   The atmIntfPvcFailuresTrap is generated just after a PVPL or PVCL on
   a particular interface leaves the 'up' operational state.  Managers
   can then determine which PVPLs and/or PVCLs are failing by reading
   the atmCurrentlyFailingPVplTable and the
   atmCurrentlyFailingPVclTable.  Generation of the
   atmIntfPvcFailuresTrap is rate limited by suppressing all traps that
   would occur within atmIntfPvcNotificationInterval of a previous trap
   for the same interface.  Managers should continuously poll the tables
   and objects mentioned above for at least this amount of time in order
   to keep up with the state of the network.

4.  Conformance and Compliance

   See the conformance and compliance statements within the information
   module.



(page 21 continued on part 2)

Next RFC Part