Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3606

Definitions of Supplemental Managed Objects for ATM Interface

Pages: 94
Proposed Standard
Part 1 of 3 – Pages 1 to 21
None   None   Next

Top   ToC   RFC3606 - 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   ToC   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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   RFC3606 - 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 Section