Network Working Group K. Tesink, Editor Request for Comments: 2515 Bell Communications Research Obsoletes: 1695 February 1999 Category: Standards Track
Definitions of Managed Objects
for ATM Management
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Table of Contents
1 Abstract ............................................. 2
2 The SNMP Network Management Framework ................. 2
3 ATM Terminology ....................................... 3
3.1 VCL/VPL and VCC/VPC ................................. 3
3.2 PVC, SVC and Soft PVC ............................... 5
3.3 Traffic Management Parameters ....................... 6
3.3.1 Traffic Policing and Traffic Shaping Parameters
.................................................... 6
3.3.2 Cell Loss Priority ................................ 6
3.3.3 QoS Class ......................................... 6
3.3.4 Service Category .................................. 7
3.4 Max Active and Max Current VPI and VCI Bits ......... 7
4 Overview .............................................. 8
4.1 Background .......................................... 8
4.2 Structure of the MIB ................................ 9
4.3 ATM Interface Configuration Table ................... 9
4.4 ATM Interface DS3 PLCP and TC Layer Tables .......... 9
4.5 ATM Virtual Link and Cross-Connect Tables ........... 9
5 Application of MIB II to ATM .......................... 10
5.1 The System Group .................................... 10
5.2 The Interface Group ................................. 10
5.2.1 Support of the ATM Cell Layer by ifTable .......... 10
6 Support of the AAL3/4 Based Interfaces ................ 12
7 Support of the AAL5 Managed Objects ................... 12
7.1 Managing AAL5 in a Switch ........................... 12
Tesink Standards Track [Page 1] RFC 2515 ATM Management Objects February 1999
7.2 Managing AAL5 in a Host ............................. 14
7.3 Support of AAL5 by ifTable .......................... 15
7.4 Support of Proprietary Virtual Interface by ifT-
able ............................................... 16
7.5 AAL5 Connection Performance Statistics Table ........ 17
8 ILMI MIBs and the ATM Managed Objects ................. 18
9 Definitions ........................................... 20
10 Acknowledgments ...................................... 83
11 References ........................................... 83
12 Security Considerations .............................. 85
13 Author's Address ..................................... 85
14 Intellectual Property ................................ 86
15 Full Copyright Statement ............................. 87
1. Abstract
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services.
This memo replaces RFC 1695 [24]. Changes relative to RFC 1695 are summarized in the MIB module's REVISION clause.
Textual Conventions used in this MIB are defined in [6] and [19].
2. The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major components:
0 An overall architecture, described in RFC 2271 [1].
0 Mechanisms for describing and naming objects and events
for the purpose of management. The first version of this
Structure of Management Information (SMI) is called SMIv1 and
described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC
1215 [4]. The second version, called SMIv2, is described in RFC
1902 [5], RFC 1903 [6] and RFC 1904 [7].
0 Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [8]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [9] and
RFC 1906 [10].
Tesink Standards Track [Page 2] RFC 2515 ATM Management Objects February 1999
The third version of the message protocol is called SNMPv3 and
described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12].
0 Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [8]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[13].
0 A set of fundamental applications described in RFC 2273 [14] and
the view-based access control mechanism described in RFC 2275
[15].
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (e.g., use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.
3. ATM Terminology
Some basic ATM terminologies are described in this section to facilitate defining the ATM managed objects.
3.1. VCL/VPL and VCC/VPC
There are two distinct types of ATM virtual connections: Virtual Channel Connections (VCCs) and Virtual Path Connection (VPCs). As shown in Figures 1 and 2, ATM virtual connections consist of concatenated series of virtual links which forms a path between two end points, with each concatenation occurring at an ATM switch. Virtual links of VCCs are called Virtual Channel Links (VCLs). Virtual links of VPCs are called Virtual Path Links (VPLs). The VCI and VPI fields in the ATM cell header associate each cell of a VCC with a particular VCL over a given physical link. The VPI field in the ATM cell header associates each cell of a VPC with a particular VPL over a given physical link. Switches route cells between VCLs (or VPLs) via a cross-connect function according to the cells' VCI/VPI (or VPI) values.
Tesink Standards Track [Page 3] RFC 2515 ATM Management Objects February 1999
<-----------------------VCC-------------------------->
------------ -----------
|ATM | |ATM |
|X-Connect | |X-Connect |
VCL1 |Point | VCL2 |Point | VCL3
O---------|----X-----|-------|-----|----X-----|-------O
| | | |
------------ ------------
ATM Switch ATM Switch
Figure 1: Virtual Channel Links and
Virtual Channel Connection
<-----------------------VPC-------------------------->
------------ -----------
|ATM | |ATM |
|X-Connect | |X-Connect |
VPL1 |Point | VPL2 |Point | VPL3
O---------|----X-----|-------|-----|----X-----|-------O
| | | |
------------ ------------
ATM Switch ATM Switch
Figure 2: Virtual Path Links and
Virtual Path Connection
A single ATM end-system or switch does not support the whole end-to- end span of a VCC (or VPC). Rather, multiple ATM end-systems and/or switches each support one piece of the VCC (or VPC). That is, each ATM end-system (or ATM switch) at one end of the VCC/VPC supports its end of the VCC/VPC plus the VCL or VPL on its external interface, and each switch through which the VCC/VPC passes supports the pair of VCLs/VPLs on its external interfaces as well as the cross-connection of those VCLs/VPLs. Thus, the end-to-end management of a VCC or VPC is achieved only by appropriate management of its individual pieces in combination.
Note that for management purposes, an ATM network may be viewed as a large distributed switch by hiding all the network's internal connectivity as being internal to the distributed switch (as shown in Figure 2a). This model may for example be used for Customer Network Management (CNM) purposes.
Tesink Standards Track [Page 4] RFC 2515 ATM Management Objects February 1999
<---------------------VCC--------------------------->
--------------------------------------
| |
| ---------- ---------- |
| | ATM | | ATM | |
VCL1 | | Switch | | Switch | | VCL3
O-------|-|--------|------/-------|--------|-|------O
| | | | | |
| ---------- ---------- |
| |
| ATM Network |
--------------------------------------
Figure 2a: ATM Network modeled as a large distributed
switch
A VCC has a set of traffic characteristics (i.e., bandwidth parameters, service category parameters, etc.). VCLs inherit their traffic characteristics from the VCC of which they are a part. VCCs are bi-directional by definition. However, the traffic parameters in the two directions of a connection can be symmetric or asymmetric, i.e., the two directions can have the same or different traffic flows. A uni-directional traffic flow across a VCC is achieved by assigning a zero bandwidth in one direction. Note that in addition to the bandwidth required by the user traffic flow, bandwidth is also required for OAM cell flows, even for the zero-bandwidth direction of a uni-directional connection. These same principles apply to VPCs.
3.2. PVC, SVC and Soft PVC
A Permanent Virtual Connection (PVC) is a provisioned VCC or VPC. A Switched Virtual Connection (SVC) is a switched VCC or VPC that is set up in real-time via call set-up signaling procedures. A PVC (or an SVC) can be a point-to-point, point-to-multipoint, or multipoint- to-multipoint VCC or VPC. A Soft PVC is a connection of which portions are switched, while other portions are permanent (see Figure 3 and [22]).
+--------+ +--------+ +--------+
pvc| ATM |svc svc | ATM |svc svc | ATM |pvc
----| Switch |-----------| Switch |-----------| Switch |----
+--------+ +--------+ +--------+
Figure 3: An example of a Soft PVC
Tesink Standards Track [Page 5] RFC 2515 ATM Management Objects February 1999
3.3. Traffic Management Parameters
3.3.1. Traffic Policing and Traffic Shaping Parameters
In order to allocate resources fairly among different users, some networks police traffic at resource access points. The traffic enforcement or policing taken at a UNI is called Usage Parameter Control (UPC) and is conceptually activated on an incoming VCL or VPL as shown in Figure 4. The use of the traffic enforcer at the ingress of the connection is to make sure that the user traffic does not exceed the negotiated traffic parameters such as the peak cell rate associated with a specific traffic descriptor type.
UNI | ATM | NNI | ATM | UNI
| | switch | | | switch | |
O<---|---->X(UPC) |<----|------>| (UPC)X<-----|--->O
| VCL | | | VCL | | VCL |
---------- ----------
Figure 4: An Example of a UPC
In addition, traffic shaping may be performed on an outgoing VPL or VCL at a given ATM interface. The function of the ATM traffic shaper, conceptually either at the source or an egress point of the connection, is to smooth the outgoing cell traffic inter-arrival time. If policing or shaping is not performed then the policing or shaping algorithm is not activated.
3.3.2. Cell Loss Priority
To prioritize traffic during resource congestion, ATM cells are assigned one of the two types of Cell Loss Priority (CLP), CLP=0 and CLP=1. ATM cells with CLP=0 have a higher priority in regard to cell loss than ATM cells with CLP=1. Therefore, during resource congestions, CLP=1 cells are dropped before any CLP=0 cell is dropped.
3.3.3. QoS Class
RFC1695 specified that one of a number of Quality of Service (QoS) classes is assigned to a VCC or VPC by associating the object atmTrafficQoSClass with each VCL or VPL. However, new insights in ATM traffic management have caused this object to be deprecated.
Tesink Standards Track [Page 6] RFC 2515 ATM Management Objects February 1999
3.3.4. Service Category
Replacing QoS Class, VPLs and VCLs are qualified in terms of their service category (atmServiceCategory). When properly configured, VCLs (or VPLs) concatenated to form a VCC (or VPC) will all have the same service category class as that of the VCC (or VPC).
3.4. Max Active and Max Current VPI and VCI Bits
A manager may wish to configure the maximum number of VPI and VCI bits that can be used to identify VPIs and VCIs on a given ATM interface. This value can be less than or equal to the maximum number of bits supported by the interface hardware, and is referred to in the MIB as the Max Active VPI Bits and Max Active VCI Bits.
However, a manager may not be able to configure the Max Active Bits on both ends of an ATM link. For example, the manager may not be allowed write access to the peer's MIB, or there may be hardware limitations on the peer device. Therefore, the two ATM devices may use ILMI to negotiate "Max Current" VPI and VCI bits, which is the maximum number of bits that both interfaces are willing to support. This is illustrated in Figure 5. The relationship between the different parameters is illustrated in Figure 6. Note that if ILMI negotiation is not supported, then the devices have no choice but to use the configured Max Active bits, and assume that it has been configured to the same value on both ends of the link.
+--------+ +--------+ +--------+ | ATM | IF a IF b | ATM | IF c IF d | ATM | | Device |--------------| Device |--------------| Device | +--------+ +--------+ +--------+
IF a: Max Active VPI Bits = 6 (configured)
Max Current VPI Bits = 6 (negotiated)
IF b: Max Active VPI Bits = 8 (configured)
Max Current VPI Bits = 6 (negotiated)
IF c: Max Active VPI Bits = 8 (configured)
Max Current VPI Bits = 8 (negotiated)
IF d: Max Active VPI Bits = 8 (configured)
Max Current VPI Bits = 8 (negotiated)
Tesink Standards Track [Page 7] RFC 2515 ATM Management Objects February 1999
(between IF a and IF b, the minimum of the two configured
"Max Active VPI Bits" is 6, so both interfaces set their
"Max Current VPI Bits" to 6. Since IF c and IF d both
are configured with "Max Active VPI Bits" of 8, they
set their "Max Current VPI Bits" to 8.)
Figure 5
MSB LSB
+----------------------------------------------------+
| | | | |
+----------------------------------------------------+
^ ^ ^ ^
| | | |
Max bits Max Bits Max Max
supported supported Active (config.) current (negotiated)
by MIB by h/w Bits Bits
Figure 6
4. Overview
ATM management objects are used to manage ATM interfaces, ATM virtual links, ATM cross-connects, AAL5 entities and AAL5 connections supported by ATM hosts, ATM switches and ATM networks. This section provides an overview and background of how to use this MIB and other potential MIBs for this purpose.
The purpose of this memo is primarily to manage ATM PVCs. ATM SVCs are also represented by the management information in this MIB. However, full management of SVCs may require additional capabilities which are beyond the scope of this memo.
4.1. Background
In addition to the MIB module defined in this memo, other MIB modules are necessary to manage ATM interfaces, links and cross-connects. Examples include MIB II for general system and interface management [16][17], the DS3 or SONET MIBs for management of physical interfaces, and, as appropriate, MIB modules for applications that make use of ATM, such as SMDS. These MIB modules are outside the scope of this specification.
The current specification of this ATM MIB is based on SNMPv2-SMI.
Tesink Standards Track [Page 8] RFC 2515 ATM Management Objects February 1999
4.2. Structure of the MIB
The managed ATM objects are arranged into the following tables:
(1) ATM interface configuration table
(2) ATM interface DS3 PLCP and TC sublayer tables
(3) ATM traffic parameter table
(4) ATM interface virtual link (VPL/VCL) configuration
tables
(5) ATM VP/VC cross-connect tables
(6) AAL5 connection performance statistics table
Note that, managed objects for activation/deactivation of OAM cell flows and ATM traps notifying virtual connection or virtual link failures are outside the scope of this memo.
4.3. ATM Interface Configuration Table
This table contains information on ATM cell layer configuration of local ATM interfaces on an ATM device in addition to the information on such interfaces contained in the ifTable.
4.4. ATM Interface DS3 PLCP and TC Layer Tables
These tables provide performance statistics of the DS3 PLCP and TC sublayer of local ATM interfaces on a managed ATM device. DS3 PLCP and TC sublayer are currently used to carry ATM cells respectively over DS3 and SONET transmission paths.
4.5. ATM Virtual Link and Cross-Connect Tables
ATM virtual link and cross-connect tables model bi-directional ATM virtual links and ATM cross-connects. The ATM VP/VC link tables are implemented in an ATM host, ATM switch and ATM network. The ATM switch and ATM network also implement the ATM VP/VC cross-connect tables. Both link and cross-connect tables are implemented in a carrier's network for Customer Network Management (CNM) purposes.
The ATM virtual link tables are used to create, delete or modify ATM virtual links in an ATM host, ATM switch and ATM network. ATM virtual link tables along with the cross-connect tables are used to create, delete or modify ATM cross-connects in an ATM switch or ATM network (e.g., for CNM purposes).
For a PVC, the cross-connect between two VPLs is represented in the atmVpCrossConnectTable of the ATM-MIB, indexed by the atmVplCrossConnectIdentifier values for the two VPLs, and the cross-
Tesink Standards Track [Page 9] RFC 2515 ATM Management Objects February 1999
rconnect between two VCLs is represented in the atmVcCrossConnectTable of the ATM-MIB, indexed by the atmVclCrossConnectIdentifier values for the two VCLs.
For an SVC or Soft PVC the VPL and VCL tables defined in this memo are used. Hoewever, for an SVC or Soft PVC the cross-connect between two VPLs is represented in the atmSvcVpCrossConnectTable of the ATM2-MIB, indexed by the atmVplCrossConnectIdentifier values for the two VPLs, and the cross-connect between two VCLs is represented in the atmSvcVcCrossConnectTable of the ATM2-MIB, indexed by the atmVclCrossConnectIdentifier values for the two VCLs.
Note: The ATM2-MIB module was being defined in a separate memo at the time of this publication. Please consult the RFC directory for an exact reference.
5. Application of MIB II to ATM
5.1. The System Group
For the purposes of the sysServices object in the System Group of MIB II [16], ATM is a data link layer protocol. Thus, for ATM switches and ATM networks, sysServices will have the value "2".
5.2. The Interface Group
The Interfaces Group of MIB II defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing ATM interfaces.
This memo assumes the interpretation of the Interfaces Group to be in accordance with [17] which states that the interfaces table (ifTable) contains information on the managed resource's interfaces and that each sub-layer below the internetwork layer of a network interface is considered an interface. Thus, the ATM cell layer interface is represented as an entry in the ifTable. This entry is concerned with the ATM cell layer as a whole, and not with individual virtual connections which are managed via the ATM-specific managed objects specified in this memo. The inter-relation of entries in the ifTable is defined by Interfaces Stack Group defined in [17].
5.2.1. Support of the ATM Cell Layer by ifTable
Some specific interpretations of ifTable for the ATM cell layer follow.
Tesink Standards Track [Page 10] RFC 2515 ATM Management Objects February 1999
Object Use for the generic ATM layer ====== =============================
ifIndex Each ATM port is represented by an ifEntry.
ifDescr Description of the ATM interface.
ifType The value that is allocated for ATM is 37.
ifSpeed The total bandwidth in bits per second
for use by the ATM layer.
ifPhysAddress The interface's address at the ATM protocol
sublayer; the ATM address which would be used as the value
of the Called Party Address Information Element (IE) of a
signalling message for a connection which either:
- would terminate at this interface, or
- for which the Called Party Address IE
would need to be replaced by the Called Party SubAddress
IE before the message was forwarded to any other
interface.
For an interface on which signalling is not supported,
then the interface does not necessarily have an address,
but if it does, then ifPhysAddress is the address which
would be used as above in the event that signalling were
supported. If the interface has multiple such addresses,
then ifPhysAddress is its primary address. If the
interface has no addresses, then ifPhysAddress is an octet
string of zero length. Address encoding is as per [20].
Note that addresses assigned for purposes other than those
listed above (e.g., an address associated with the service
provider side of a public network UNI) may be represented
through atmInterfaceSubscrAddress.
ifAdminStatus See [17].
ifOperStatus Assumes the value down(2) if the ATM cell
layer is down.
ifLastChange See [17].
ifInOctets The number of received octets over the
interface, i.e., the number of received, assigned cells
multiplied by 53.
ifOutOctets The number of transmitted octets over the interface,
i.e., the number of transmitted, assigned cells multiplied
by 53.
Tesink Standards Track [Page 11] RFC 2515 ATM Management Objects February 1999
ifInErrors The number of cells dropped due to uncorrectable HEC
errors.
ifInUnknownProtos The number of received cells discarded during cell
header validation, including cells with unrecognized
VPI/VCI values, and cells with invalid cell header
patterns. If cells with undefined PTI values are
discarded, they are also counted here.
ifOutErrors See [17].
ifName Textual name (unique on this system) of the
interface or an octet string of zero length.
ifLinkUpDownTrapEnable Default is disabled (2).
ifConnectorPresent Set to false (2).
ifHighSpeed See [17].
ifHCInOctets The 64-bit version of ifInOctets; supported
if required by the compliance statements in [17].
ifHCOutOctets The 64-bit version of ifOutOctets; supported
if required by the compliance statements in [17].
ifAlias The non-volatile 'alias' name for the interface
as specified by a network manager.
6. Support of the AAL3/4 Based Interfaces
For the management of AAL3/4 CPCS layer, see [18].
7. Support of the AAL5 Managed Objects
Support of AAL5 managed objects in an ATM switch and ATM host are described below.
7.1. Managing AAL5 in a Switch
Managing AAL5 in a switch involves:
(1) performance management of an AAL5 entity as
an internal resource in a switch
(2) performance management of AAL5 per virtual connection
Tesink Standards Track [Page 12] RFC 2515 ATM Management Objects February 1999
AAL5 in a switch is modeled as shown in Figure 7 and 8. AAL5 will be managed in a switch for only those virtual connections that carry AAL5 and are terminated at the AAL5 entity in the switch. Note that, the virtual channels within the ATM UNIs carrying AAL5 will be switched by the ATM switching fabric (termed as ATM Entity in the figure) to the virtual channels on a proprietary internal interface associated with the AAL5 process (termed as AAL5 Entity in the figure). Therefore, performance management of the AAL5 resource in the switch will be modeled using the ifTable through an internal (pseudo-ATM) virtual interface and the AAL5 performance management per virtual connection will be supported using an additional AAL5 connection table in the ATM MIB. The association between the AAL5 virtual link at the proprietary virtual, internal interface and the ATM virtual link at the ATM interface will be derived from the virtual channel cross-connect table and the virtual channel link table in the ATM MIB. Note that for the proprietary virtual interface the traffic transmit and receive conventions in the virtual channel link table are as follows:
Transmitting traffic: ATM Entity ---> AAL5 Entity
Receiving traffic: ATM Entity <--- AAL5 Entity
___________________________
| |
| ============= |
| | AAL5 | |
| | Entity | |
| ============= |
| | |
| -----Prop. Virtual Interface
| | |
| ============= |
| | ATM | |
| | Entity | |
| ============= |
|_____|__|__|__|__|_______|
| | | | |
---------------- ATM UNIs
| | | | |
| | | | |
v v v v v
Figure 7: Model of an AAL5 Entity in a Switch
Tesink Standards Track [Page 13] RFC 2515 ATM Management Objects February 1999
__________________
| |
| AAL5 |
|________________|
| |
| Prop. Virtual |
| Interface |
|________________|
Figure 8: AAL5 Entity's Interface Stack in a Switch
7.2. Managing AAL5 in a Host
Managing AAL5 in a host involves managing the AAL5 sublayer interface as shown in Figure 9 and 10. The AAL5 sublayer is stacked directly over the ATM sublayer. The ifTable is applied to the AAL5 sublayer as defined in Section 10.3.
___________________________
| |
| ============= |
| | AAL5 | |
| | Entity | |
| ============= |
| | ATM | |
| | Entity | |
| ============= |
|___________|_____________|
|
__|__ ATM UNI
|
|
v
Figure 9: Model of an AAL5 Entity in a Host
__________________
| |
| AAL5 |
|________________|
| |
| ATM Layer |
|________________|
| |
| Physical Layer|
|________________|
Figure 10: AAL5 Entity's Interface Stack in a Host
Tesink Standards Track [Page 14] RFC 2515 ATM Management Objects February 1999
7.3. Support of AAL5 by ifTable
The AAL5 entity in an ATM device (e.g., switch or host) is managed using the ifTable. There are additional counters specified for AAL5 than those specified in the ATM B-ICI document [21]. Specific interpretations of ifTable for the AAL5 CPCS layer are as follows.
Object Use for AAL5 CPCS layer entity ====== ==============================
ifIndex Each AAL5 entity is represented by an ifEntry.
ifDescr Description of the AAL5 entity.
ifType The value that is allocated for AAL5 is 49.
ifMtu Set to the largest PDU size for the
AAL5 CPCS layer that can be processed
by the AAL5 entity.
ifSpeed Set to 0.
ifPhysAddress An octet string of zero length.
ifAdminStatus See [17].
ifOperStatus Assumes the value down(2) if the AAL5
layer is down.
ifLastChange See [17].
ifInOctets The number of received AAL5 CPCS PDU octets.
ifOutOctets The number of AAL5 CPCS PDU octets
transmitted.
ifInUcastPkts The number of received AAL5 CPCS PDUs passed
to a higher-layer.
ifOutUcastPkts The number of AAL5 CPCS PDUs received from a
higher-layer for transmission.
[Note: The number of AAL5 PDUs actually
transmitted is the number received from a
higher-layer for transmission minus any which
are counted by ifOutErrors and ifOutDiscards.]
Tesink Standards Track [Page 15] RFC 2515 ATM Management Objects February 1999
ifInErrors Number of errored AAL5 CPCS PDUs received.
The types of errors counted include CRC-32 errors,
SAR time-out errors, and oversized SDU errors.
ifInUnknownProtos Set to 0.
ifInDiscards Number of received AAL5 CPCS PDUs discarded.
Possible reason may be input buffer overflow.
ifOutErrors Number of AAL5 CPCS PDUs that could not
be transmitted due to errors.
ifOutDiscards Number of AAL5 CPCS PDUs received for
transmission that are discarded.
Possible reason may be output buffer
overflow.
ifInMulticastPkts Set to 0.
ifInBroadcastPkts Set to 0.
ifOutMulticastPkts Set to 0.
ifOutBroadcastPkts Set to 0.
ifName Textual name (unique on this system) of the
AAL5 entity or an octet string of zero length.
ifHighSpeed Set to 0.
ifConnectorPresent Set to false (2).
ifPromiscuousMode Set to false(2).
ifLinkUpDownTrapEnable Default is disabled (2).
ifAlias The non-volatile 'alias' name for the interface
as specified by a network manager.
7.4. Support of Proprietary Virtual Interface by ifTable
Specific interpretations of ifTable for the proprietary virtual, internal interface associated with an AAL5 entity in an ATM switch are as follows.
Tesink Standards Track [Page 16] RFC 2515 ATM Management Objects February 1999
Object Use for proprietary virtual, internal interface
associated with AAL entities
====== ===============================================
ifIndex Each proprietary virtual, internal interface
associated with AAL entities is represented by an
ifEntry.
ifDescr Description of the proprietary virtual, internal
interface associated with AAL entities.
ifType The value that is allocated for proprietary
virtual, internal interface is 53.
ifSpeed See [17]. Set to 0 if the speed is not
known.
ifPhysAddress See [17]. An octet string of zero length
if no address is used for this interface.
ifAdminStatus See [17].
ifOperStatus See [17].
ifLastChange See [17].
ifName Textual name (unique on this system) of the
interface or an octet string of zero length.
ifHighSpeed See [17]. Set to 0 if the speed is not known.
ifConnectorPresent Set to false (2).
ifLinkUpDownTrapEnable Default is disabled (2).
ifAlias The non-volatile 'alias' name for the interface
as specified by a network manager.
7.5. AAL5 Connection Performance Statistics Table
An AAL5 connection table is used to provide AAL5 performance information for each AAL5 virtual connection that is terminated at the AAL5 entity contained within an ATM switch or host.
Tesink Standards Track [Page 17] RFC 2515 ATM Management Objects February 1999
8. ILMI MIBs and the ATM Managed Objects
The ILMI MIBs are specified by the ATM Forum as a set of several MIBs, all currently defined in the ILMI Specification [23]. The ILMI protocols and MIBs allow two connected ATM Interface Management Entities (IMEs) to exchange bi-directional parameters, mainly to facilitate auto-configuration between ATM peer entities. The support of the ATM management functions by the ILMI MIBs and those contained in this memo are compared in Table 1. In this table, "yes" in the "ILMI MIBs" column indicates that the management functions are supported by the ILMI MIBs. The parenthesized numbers in the "This memo" column correspond to the sets of tables enumerated in Section 6.2.
For that subset of management information which the ILMI MIBs and this memo have in common, every effort has been made to retain identical semantics and syntax, even though the MIB objects are identified using different OBJECT IDENTIFIERs.
Table 1 - Structuring of ATM Managed Objects
______________________________________________________________
| |This |ILMI|
ATM Mgmt.Inf. |ATM Managed Objects |memo |MIBs|
______________|_________________________________|_______|____|
Local Interface Information:
_____________________________________________________________
ATM interface:| (1) port identifier |ATM MIB| |
physical layer| (2) physical transmission types | (1)*|yes |
configuration | (3) operational status |MIB II | * |
| (4) administrative status | | ** |
| (5) last change status | | |
_____________________________________________________________
ATM interface:| (1) active VPI/VCI fields |ATM MIB| |
cell layer | (2) maximum number of VPCs/VCCs | (1) |yes |
configuration | (3) configured VPCs/VCCs | | ** |
| (4) ILMI VPI/VCI values | | |
| (5) Neighbor system info | | |
| (6) Max. number of VPI/VCI bits | |yes |
| (7) ATM Subscribed Address | | |
_____________________________________________________________
ATM interface:|(1) received/transmitted cells | | |
cell layer |(2) cells with HEC error |MIB II |yes |
performance |(3) cell header validation errors| | |
_____________________________________________________________
Tesink Standards Track [Page 18] RFC 2515 ATM Management Objects February 1999
_____________________________________________________________
ATM interface:|(1)DS3 PLCP severely errored |ATM MIB| |
PLCP & TC | framing seconds | (2)| |
layer |(2)DS3 PLCP unavailable seconds | |no |
performance |(3)DS3 PLCP alarm state | | |
|(4)out of cell delineation events| | |
|(5)TC alarm state | | |
_____________________________________________________________
VP/VC link: |(1)VPI or VPI/VCI value |ATM MIB| |
configuration |(2)VCL or VPL operational status | (3,4)|yes |
|(3)VCL/VPL administrative status | |*** |
|(4)VCL/VPL last change status | | |
|(5)transmit/receive traffic/ | | |
| service category parameters | | |
|(6)AAL type | | |
|(7)transmit/receive AAL5 SDU size| | |
|(8)AAL5 encapsulation type | | |
|(9)connection topology type | | |
|(10)use of call control | | |
_____________________________________________________________
VP/VC |(1)cross-connect identifier | | |
Cross-connect:|(2)port identifier of one | | |
configuration | end | | |
|(3)port identifier of the other |ATM MIB| |
| end | (5)|no |
|(4)VPI or VPI/VCI value | | |
| of one end | | |
|(5)VPI or VPI/VCI value of | | |
| the other end | | |
|(6)VC/VP cross-connect | | |
| operational status | | |
|(7)VC/VP cross-connect | | |
| administrative status | | |
|(8)VC/VP last change status | | |
_____________________________________________________________
VCC AAL5 CPCS |(1)PDUs discarded for CRC errors |ATM MIB| |
layer: |(2)PDUs discarded due to | (6) | |
performance | reassembly time out | |no |
|(3)PDUs discarded due to large | | |
| SDUs | | |
_____________________________________________________________
AAL5 entity: |(1)received/transmitted PDUs | | |
|(2)PDUs discarded due to | | |
| protocol errors |MIB II |no |
|(3)a set of configuration/state | | |
| parameters | | |
_____________________________________________________________
Tesink Standards Track [Page 19] RFC 2515 ATM Management Objects February 1999
interface and the physical transmission type shall be supported by
the interface table in MIB II [16][17]. ILMI does not contain the administrative and last change status of the ATM interface.
the ATM interface level.
GROUP atmInterfaceTCGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement the
TC Sublayer."
GROUP atmVpcTerminationGroup2
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VPLs that terminate VPCs (i.e., ones which
are NOT cross-connected to other VPLs)."
GROUP atmVplCrossConnectGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VPLs that are not associated with VCLs
and are cross-connected to other VPLs
for VPCs."
Tesink Standards Track [Page 68] RFC 2515 ATM Management Objects February 1999
GROUP atmVpPvcCrossConnectGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VPLs that are not associated with VCLs
and are cross-connected to other VPLs
for permanent VPCs (i.e., PVCs).
This group is not used to crossconnect
a PVC with an SVC to form a Soft PVC."
OBJECT atmVplAdminStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVplReceiveTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVplTransmitTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVplRowStatus
SYNTAX INTEGER {active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
OBJECT atmVplCastType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVplConnKind
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVpCrossConnectAdminStatus
MIN-ACCESS read-only
DESCRIPTION
Tesink Standards Track [Page 69] RFC 2515 ATM Management Objects February 1999
"Write access is not required."
OBJECT atmVpCrossConnectRowStatus
SYNTAX INTEGER {active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
GROUP atmVccTerminationGroup2
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VCLs that terminate VCCs (i.e., ones which
are NOT cross-connected to other VCLs)."
GROUP atmVclCrossConnectGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VCLs that are cross-connected to other VCLs
for VCCs."
GROUP atmVcPvcCrossConnectGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VCLs that are cross-connected to other
VCLs for permanent VCCs (i.e., PVCs).
This group is not used to crossconnect
a PVC with an SVC to form a Soft PVC."
OBJECT atmVclAdminStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVclReceiveTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
Tesink Standards Track [Page 70] RFC 2515 ATM Management Objects February 1999
OBJECT atmVclTransmitTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVccAalType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVclRowStatus
SYNTAX INTEGER {active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
OBJECT atmVclCastType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVclConnKind
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVcCrossConnectAdminStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVcCrossConnectRowStatus
SYNTAX INTEGER { active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
--
-- ****** AAL5 Support ******************************
--
GROUP aal5VccGroup
Tesink Standards Track [Page 71] RFC 2515 ATM Management Objects February 1999
DESCRIPTION
"This group is mandatory for the
AAL5 virtual connections only."
OBJECT atmVccAal5CpcsTransmitSduSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVccAal5CpcsReceiveSduSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVccAal5EncapsType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { atmMIBCompliances 2 }
atmInterfaceDs3PlcpGroup OBJECT-GROUP
OBJECTS {atmInterfaceDs3PlcpSEFSs,
atmInterfaceDs3PlcpAlarmState,
atmInterfaceDs3PlcpUASs}
STATUS current
DESCRIPTION
"A collection of objects providing information
about DS3 PLCP layer at an ATM interface."
::= { atmMIBGroups 3 }
atmInterfaceTCGroup OBJECT-GROUP
OBJECTS { atmInterfaceOCDEvents,
atmInterfaceTCAlarmState }
STATUS current
DESCRIPTION
"A collection of objects providing information
about TC sublayer at an ATM interface."
::= { atmMIBGroups 4 }
aal5VccGroup OBJECT-GROUP
OBJECTS {atmVccAal5CpcsTransmitSduSize,
atmVccAal5CpcsReceiveSduSize,
atmVccAal5EncapsType,
aal5VccCrcErrors, aal5VccSarTimeOuts,
aal5VccOverSizedSDUs }
STATUS current
Tesink Standards Track [Page 72] RFC 2515 ATM Management Objects February 1999
DESCRIPTION
"A collection of objects providing
AAL5 configuration and performance statistics
of a VCC."
::= { atmMIBGroups 9 }
atmInterfaceConfGroup2 OBJECT-GROUP
OBJECTS {
atmInterfaceMaxVpcs, atmInterfaceMaxVccs,
atmInterfaceConfVpcs, atmInterfaceConfVccs,
atmInterfaceMaxActiveVpiBits,
atmInterfaceMaxActiveVciBits,
atmInterfaceIlmiVpi,
atmInterfaceIlmiVci,
atmInterfaceMyNeighborIpAddress,
atmInterfaceMyNeighborIfName,
atmInterfaceCurrentMaxVpiBits,
atmInterfaceCurrentMaxVciBits,
atmInterfaceSubscrAddress }
STATUS current
DESCRIPTION
"A collection of objects providing configuration
information about an ATM interface."
::= { atmMIBGroups 10 }
atmTrafficDescrGroup2 OBJECT-GROUP
OBJECTS {
atmTrafficDescrType, atmTrafficDescrParam1,
atmTrafficDescrParam2, atmTrafficDescrParam3,
atmTrafficDescrParam4, atmTrafficDescrParam5,
atmTrafficDescrRowStatus, atmServiceCategory,
atmTrafficFrameDiscard,
atmTrafficDescrParamIndexNext }
STATUS current
DESCRIPTION
"A collection of objects providing information
about ATM traffic descriptor type and
the associated parameters."
::= { atmMIBGroups 11 }
atmVpcTerminationGroup2 OBJECT-GROUP
OBJECTS {atmVplOperStatus, atmVplAdminStatus,
atmVplLastChange,
atmVplReceiveTrafficDescrIndex,
atmVplTransmitTrafficDescrIndex,
atmVplRowStatus, atmVplCastType,
atmVplConnKind }
STATUS current
Tesink Standards Track [Page 73] RFC 2515 ATM Management Objects February 1999
DESCRIPTION
"A collection of objects providing information
about a VPL at an ATM interface which
terminates a VPC (i.e., one which is NOT
cross-connected to other VPLs)."
::= { atmMIBGroups 12 }
atmVccTerminationGroup2 OBJECT-GROUP
OBJECTS {atmVclOperStatus, atmVclAdminStatus,
atmVclLastChange,
atmVclReceiveTrafficDescrIndex,
atmVclTransmitTrafficDescrIndex,
atmVccAalType, atmVclRowStatus,
atmVclCastType, atmVclConnKind }
STATUS current
DESCRIPTION
"A collection of objects providing information
about a VCL at an ATM interface
which terminates a VCC (i.e., one which is
NOT cross-connected to other VCLs)."
::= { atmMIBGroups 13 }
atmVplCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVplReceiveTrafficDescrIndex,
atmVplTransmitTrafficDescrIndex,
atmVplOperStatus, atmVplLastChange,
atmVplRowStatus,
atmVplCastType, atmVplConnKind }
STATUS current
DESCRIPTION
"A collection of objects providing
information about the VPLs that
are cross-connected together."
::= { atmMIBGroups 14 }
atmVpPvcCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVpCrossConnectAdminStatus,
atmVpCrossConnectL2HOperStatus,
atmVpCrossConnectH2LOperStatus,
atmVpCrossConnectL2HLastChange,
atmVpCrossConnectH2LLastChange,
atmVpCrossConnectRowStatus,
atmVplCrossConnectIdentifier,
atmVpCrossConnectIndexNext }
STATUS current
DESCRIPTION
"A collection of objects providing
information about a VP cross-connect
Tesink Standards Track [Page 74] RFC 2515 ATM Management Objects February 1999
for PVCs. These objects are not used
for Soft PVCs or SVCs."
::= { atmMIBGroups 15 }
atmVclCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVclReceiveTrafficDescrIndex,
atmVclTransmitTrafficDescrIndex,
atmVclOperStatus, atmVclLastChange,
atmVclRowStatus,
atmVclCastType, atmVclConnKind }
STATUS current
DESCRIPTION
"A collection of objects providing
information about the VCLs that
are cross-connected together."
::= { atmMIBGroups 16 }
atmVcPvcCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVcCrossConnectAdminStatus,
atmVcCrossConnectL2HOperStatus,
atmVcCrossConnectH2LOperStatus,
atmVcCrossConnectL2HLastChange,
atmVcCrossConnectH2LLastChange,
atmVcCrossConnectRowStatus,
atmVclCrossConnectIdentifier,
atmVcCrossConnectIndexNext }
STATUS current
DESCRIPTION
"A collection of objects providing
information about a VC cross-connect
for PVCs. These objects are not used
for Soft PVCs or SVCs."
::= { atmMIBGroups 17 }
atmMIBCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"The compliance statement for SNMP entities
including networks which have ATM and
Tesink Standards Track [Page 75] RFC 2515 ATM Management Objects February 1999
AAL5 interfaces."
MODULE -- this module
MANDATORY-GROUPS {atmInterfaceConfGroup,
atmTrafficDescrGroup}
OBJECT atmInterfaceMaxVpcs
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceMaxVccs
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceMaxActiveVpiBits
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceMaxActiveVciBits
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceIlmiVpi
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceIlmiVci
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceMyNeighborIpAddress
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmInterfaceMyNeighborIfName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrType
MIN-ACCESS read-only
Tesink Standards Track [Page 76] RFC 2515 ATM Management Objects February 1999
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrParam1
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrParam2
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrParam3
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrParam4
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrParam5
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficQoSClass
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmTrafficDescrRowStatus
SYNTAX INTEGER {active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
GROUP atmInterfaceDs3PlcpGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement the
DS3 PLCP layer."
Tesink Standards Track [Page 77] RFC 2515 ATM Management Objects February 1999
GROUP atmInterfaceTCGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement the
TC Sublayer."
GROUP atmVpcTerminationGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VPLs that terminate VPCs (i.e., ones which
are NOT cross-connected to other VPLs)."
GROUP atmVpCrossConnectGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VPLs that are not associated with VCLs
and are cross-connected to other VPLs."
OBJECT atmVplAdminStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVplReceiveTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVplTransmitTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVplRowStatus
SYNTAX INTEGER {active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
OBJECT atmVpCrossConnectAdminStatus
MIN-ACCESS read-only
DESCRIPTION
Tesink Standards Track [Page 78] RFC 2515 ATM Management Objects February 1999
"Write access is not required."
OBJECT atmVpCrossConnectRowStatus
SYNTAX INTEGER {active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
GROUP atmVccTerminationGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VCLs that terminate VCCs (i.e., ones which
are NOT cross-connected to other VCLs)."
GROUP atmVcCrossConnectGroup
DESCRIPTION
"This group is mandatory only for those
ATM interfaces which implement ATM
VCLs that are cross-connected to
other VCLs."
OBJECT atmVclAdminStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVclReceiveTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVclTransmitTrafficDescrIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVccAalType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVclRowStatus
SYNTAX INTEGER {active(1)}
Tesink Standards Track [Page 79] RFC 2515 ATM Management Objects February 1999
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
OBJECT atmVcCrossConnectAdminStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVcCrossConnectRowStatus
SYNTAX INTEGER { active(1)}
-- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the six enumerated values for the
RowStatus textual convention need be
supported, specifically: active(1)."
GROUP aal5VccGroup
DESCRIPTION
"This group is mandatory for the
AAL5 virtual connections only."
OBJECT atmVccAal5CpcsTransmitSduSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVccAal5CpcsReceiveSduSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT atmVccAal5EncapsType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { atmMIBCompliances 1 }
Tesink Standards Track [Page 80] RFC 2515 ATM Management Objects February 1999
atmInterfaceConfGroup OBJECT-GROUP
OBJECTS {
atmInterfaceMaxVpcs, atmInterfaceMaxVccs,
atmInterfaceConfVpcs, atmInterfaceConfVccs,
atmInterfaceMaxActiveVpiBits,
atmInterfaceMaxActiveVciBits,
atmInterfaceIlmiVpi,
atmInterfaceIlmiVci,
atmInterfaceAddressType,
atmInterfaceAdminAddress,
atmInterfaceMyNeighborIpAddress,
atmInterfaceMyNeighborIfName }
STATUS deprecated
DESCRIPTION
"A collection of objects providing configuration
information about an ATM interface."
::= { atmMIBGroups 1 }
atmTrafficDescrGroup OBJECT-GROUP
OBJECTS {
atmTrafficDescrType, atmTrafficDescrParam1,
atmTrafficDescrParam2, atmTrafficDescrParam3,
atmTrafficDescrParam4, atmTrafficDescrParam5,
atmTrafficQoSClass, atmTrafficDescrRowStatus}
STATUS deprecated
DESCRIPTION
"A collection of objects providing information
about ATM traffic descriptor type and
the associated parameters."
::= { atmMIBGroups 2 }
atmVpcTerminationGroup OBJECT-GROUP
OBJECTS {atmVplOperStatus, atmVplAdminStatus,
atmVplLastChange,
atmVplReceiveTrafficDescrIndex,
atmVplTransmitTrafficDescrIndex,
atmVplRowStatus }
STATUS deprecated
DESCRIPTION
"A collection of objects providing
information about a VPL at an ATM interface
which terminates a VPC
(i.e., one which is NOT cross-connected
to other VPLs)."
::= { atmMIBGroups 5 }
atmVccTerminationGroup OBJECT-GROUP
OBJECTS {atmVclOperStatus, atmVclAdminStatus,
Tesink Standards Track [Page 81] RFC 2515 ATM Management Objects February 1999
atmVclLastChange,
atmVclReceiveTrafficDescrIndex,
atmVclTransmitTrafficDescrIndex,
atmVccAalType, atmVclRowStatus }
STATUS deprecated
DESCRIPTION
"A collection of objects providing information
about a VCL at an ATM interface
which terminates a VCC (i.e., one which is
NOT cross-connected to other VCLs)."
::= { atmMIBGroups 6 }
atmVpCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVplReceiveTrafficDescrIndex,
atmVplTransmitTrafficDescrIndex,
atmVplOperStatus, atmVplRowStatus,
atmVpCrossConnectAdminStatus,
atmVpCrossConnectL2HOperStatus,
atmVpCrossConnectH2LOperStatus,
atmVpCrossConnectL2HLastChange,
atmVpCrossConnectH2LLastChange,
atmVpCrossConnectRowStatus,
atmVplCrossConnectIdentifier,
atmVpCrossConnectIndexNext }
STATUS deprecated
DESCRIPTION
"A collection of objects providing
information about a VP cross-connect
and the associated VPLs that are
cross-connected together."
::= { atmMIBGroups 7 }
atmVcCrossConnectGroup OBJECT-GROUP
OBJECTS { atmVclReceiveTrafficDescrIndex,
atmVclTransmitTrafficDescrIndex,
atmVclOperStatus, atmVclRowStatus,
atmVcCrossConnectAdminStatus,
atmVcCrossConnectL2HOperStatus,
atmVcCrossConnectH2LOperStatus,
atmVcCrossConnectL2HLastChange,
atmVcCrossConnectH2LLastChange,
atmVcCrossConnectRowStatus,
atmVclCrossConnectIdentifier,
atmVcCrossConnectIndexNext }
STATUS deprecated
DESCRIPTION
"A collection of objects providing
information about a VC cross-connect
Tesink Standards Track [Page 82] RFC 2515 ATM Management Objects February 1999
and the associated VCLs that are
cross-connected together."
::= { atmMIBGroups 8 }
END
10. Acknowledgments
This memo is the result of the work of the AToMMIB Working Group.
11. References
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks", RFC
2271, January 1998.
[2] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[4] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Structure of Management Information for Version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Conformance Statements for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901,
January 1996.
Tesink Standards Track [Page 83] RFC 2515 ATM Management Objects February 1999
[10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2272, January 1998.
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2274, January 1998.
[13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[14] Levi, D., Meyer, P. and B. Stewart, MPv3 Applications", RFC
2273, January 1998.
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2275, January 1998.
[16] McCloghrie, K. and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, March 1991.
[17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2233, November 1997.
[18] Brown, T. and K. Tesink, "Definitions of Managed Objects for
SMDS Interfaces", RFC 1694, May 1994.
[19] Noto, M., Spiegel, E. and K. Tesink, Editors, "Definitions of
Textual Conventions and OBJECT-IDENTITIES for ATM Management",
RFC 2514, February 1999.
[20] ATM Forum, ATM User-Network Interface, Version 3.0 (UNI 3.0)
Specification, 1994.
[21] ATM Forum, B-ICI Specification, Version 2.0, af-bici-0013.002,
November 1995.
[22] "ATM Forum Private Network-Network Interface Specification,
Version 1.0 (PNNI 1.0)", af-sig-0055.000, March 1996.
[23] "ATM Forum Integrated Local Management Interface (ILMI)
Specification", Version 4.0", af-ilmi-0065.000, September 1996.
Tesink Standards Track [Page 84] RFC 2515 ATM Management Objects February 1999
[24] Ahmed, M. and K. Tesink, "Definitions of Managed Objects for ATM
Management Version 8.0 using SMIv2", RFC 1695, August 1994.
12. Security Considerations
There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.
The managed objects in this MIB contain sensitive information since, collectively, they allow tracing and influencing of virtual connections in ATM switches or networks and provide information of their traffic characteristics.
It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment.
SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2274 [12] and the View-based Access Control Model RFC 2275 [15] is recommended.
It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
13. Author's Address
Kaj Tesink Bellcore 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020
Phone: (732) 758-5254 EMail: kaj@bellcore.com
Tesink Standards Track [Page 85] RFC 2515 ATM Management Objects February 1999
14. Intellectual Property
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Tesink Standards Track [Page 86] RFC 2515 ATM Management Objects February 1999
15. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Tesink Standards Track [Page 87]