|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 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.
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.
5. Definitions
ATM2-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Gauge32, Counter32, Integer32
FROM SNMPv2-SMI
TruthValue, RowStatus, TimeStamp
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
InterfaceIndex, InterfaceIndexOrZero, ifIndex
FROM IF-MIB
atmMIBObjects, atmInterfaceConfEntry,
atmVplEntry, atmVplVpi,
atmVclEntry, atmVclVpi, atmVclVci,
atmVpCrossConnectEntry, atmVcCrossConnectEntry
FROM ATM-MIB
AtmAddr, AtmSigDescrParamIndex,
AtmInterfaceType, AtmIlmiNetworkPrefix,
AtmVcIdentifier, AtmVpIdentifier,
AtmTrafficDescrParamIndex
FROM ATM-TC-MIB;
atm2MIB MODULE-IDENTITY
LAST-UPDATED "200309230000Z"
ORGANIZATION "IETF AToMMIB Working Group"
CONTACT-INFO
"AToMMIB WG
http://www.ietf.org/html.charters/atommib-charter.html
Editors:
Faye Ly
Postal: Pedestal Networks