RFC 3606
Definitions of Supplemental Managed Objects for ATM Interface
Pages: 94
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 21
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).
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
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
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
_____ _______ _______ _______ _____ | |____| |____| |____| |____| | |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
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 structure3.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.
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.
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
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.
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.
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
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.
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.
* 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.
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].
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.
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 values3.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.
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).
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.
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
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)