As per Relevance of the word february, we have this rfc below:











Network Working Group K. Tesink,
Request for Comments: 2515 Bell Communications
Obsoletes: 1695 February 1999
Category: Standards


Definitions of Managed
for ATM

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

Table of

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
.................................................... 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.

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-
interfaces, devices, networks and services

This memo replaces RFC 1695 [24]. Changes relative to RFC 1695
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

The SNMP Management Framework presently consists of five
components

0 An overall architecture, described in RFC 2271 [1].

0 Mechanisms for describing and naming objects and
for the purpose of management. The first version of
Structure of Management Information (SMI) is called SMIv1
described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and
1215 [4]. The second version, called SMIv2, is described in
1902 [5], RFC 1903 [6] and RFC 1904 [7].

0 Message protocols for transferring management information.
first version of the SNMP message protocol is called SNMPv1
described in STD 15, RFC 1157 [8]. A second version of the
message protocol, which is not an Internet standards
protocol, is called SNMPv2c and described in RFC 1901 [9]
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
described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12].

0 Protocol operations for accessing management information.
first set of protocol operations and associated PDU formats
described in STD 15, RFC 1157 [8]. A second set of
operations and associated PDU formats is described in RFC 1905
[13].

0 A set of fundamental applications described in RFC 2273 [14]
the view-based access control mechanism described in RFC 2275
[15].

Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the mechanisms defined in the SMI

This memo specifies a MIB module that is compliant to the SMIv2.
MIB conforming to the SMIv1 can be produced through the
translations. The resulting translated MIB must be
equivalent, except where objects or events are omitted because
translation is possible (e.g., use of Counter64). Some
readable information in SMIv2 will be converted into
descriptions in SMIv1 during the translation process. However,
loss of machine readable information is not considered to change
semantics of the MIB

3. ATM

Some basic ATM terminologies are described in this section
facilitate defining the ATM managed objects

3.1. VCL/VPL and VCC/

There are two distinct types of ATM virtual connections:
Channel Connections (VCCs) and Virtual Path Connection (VPCs).
shown in Figures 1 and 2, ATM virtual connections consist
concatenated series of virtual links which forms a path between
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
and VPI fields in the ATM cell header associate each cell of a
with a particular VCL over a given physical link. The VPI field
the ATM cell header associates each cell of a VPC with a
VPL over a given physical link. Switches route cells between
(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 | VCL
O---------|----X-----|-------|-----|----X-----|-------
| | | |
------------ ------------
ATM Switch ATM


Figure 1: Virtual Channel Links
Virtual Channel



<-----------------------VPC-------------------------->
------------ -----------
|ATM | |ATM |
|X-Connect | |X-Connect |
VPL1 |Point | VPL2 |Point | VPL
O---------|----X-----|-------|-----|----X-----|-------
| | | |
------------ ------------
ATM Switch ATM


Figure 2: Virtual Path Links
Virtual Path


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/
switches each support one piece of the VCC (or VPC). That is,
ATM end-system (or ATM switch) at one end of the VCC/VPC supports
end of the VCC/VPC plus the VCL or VPL on its external interface,
each switch through which the VCC/VPC passes supports the pair
VCLs/VPLs on its external interfaces as well as the cross-
of those VCLs/VPLs. Thus, the end-to-end management of a VCC or
is achieved only by appropriate management of its individual
in combination

Note that for management purposes, an ATM network may be viewed as
large distributed switch by hiding all the network's
connectivity as being internal to the distributed switch (as shown
Figure 2a). This model may for example be used for Customer
Management (CNM) purposes




Tesink Standards Track [Page 4]

RFC 2515 ATM Management Objects February 1999


<---------------------VCC--------------------------->
--------------------------------------
| |
| ---------- ---------- |
| | ATM | | ATM | |
VCL1 | | Switch | | Switch | | VCL
O-------|-|--------|------/-------|--------|-|------
| | | | | |
| ---------- ---------- |
| |
| ATM Network |
--------------------------------------


Figure 2a: ATM Network modeled as a large


A VCC has a set of traffic characteristics (i.e.,
parameters, service category parameters, etc.). VCLs inherit
traffic characteristics from the VCC of which they are a part.
are bi-directional by definition. However, the traffic parameters
the two directions of a connection can be symmetric or asymmetric
i.e., the two directions can have the same or different
flows. A uni-directional traffic flow across a VCC is achieved
assigning a zero bandwidth in one direction. Note that in
to the bandwidth required by the user traffic flow, bandwidth is
required for OAM cell flows, even for the zero-bandwidth direction
a uni-directional connection. These same principles apply to VPCs

3.2. PVC, SVC and Soft

A Permanent Virtual Connection (PVC) is a provisioned VCC or VPC.
Switched Virtual Connection (SVC) is a switched VCC or VPC that
set up in real-time via call set-up signaling procedures. A PVC (
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
portions are switched, while other portions are permanent (see
3 and [22]).


+--------+ +--------+ +--------+
pvc| ATM |svc svc | ATM |svc svc | ATM |
----| Switch |-----------| Switch |-----------| Switch |----
+--------+ +--------+ +--------+

Figure 3: An example of a Soft





Tesink Standards Track [Page 5]

RFC 2515 ATM Management Objects February 1999


3.3. Traffic Management

3.3.1. Traffic Policing and Traffic Shaping

In order to allocate resources fairly among different users,
networks police traffic at resource access points. The
enforcement or policing taken at a UNI is called Usage
Control (UPC) and is conceptually activated on an incoming VCL or
as shown in Figure 4. The use of the traffic enforcer at the
of the connection is to make sure that the user traffic does
exceed the negotiated traffic parameters such as the peak cell
associated with a specific traffic descriptor type

---------- ----------
UNI | ATM | NNI | ATM |
| | switch | | | switch | |
O<---|---->X(UPC) |<----|------>| (UPC)X<-----|--->
| VCL | | | VCL | | VCL |
---------- ----------


Figure 4: An Example of a

In addition, traffic shaping may be performed on an outgoing VPL
VCL at a given ATM interface. The function of the ATM
shaper, conceptually either at the source or an egress point of
connection, is to smooth the outgoing cell traffic inter-
time. If policing or shaping is not performed then the policing
shaping algorithm is not activated

3.3.2. Cell Loss

To prioritize traffic during resource congestion, ATM cells
assigned one of the two types of Cell Loss Priority (CLP), CLP=0
CLP=1. ATM cells with CLP=0 have a higher priority in regard to
loss than ATM cells with CLP=1. Therefore, during
congestions, CLP=1 cells are dropped before any CLP=0 cell
dropped

3.3.3. QoS

RFC1695 specified that one of a number of Quality of Service (QoS
classes is assigned to a VCC or VPC by associating the
atmTrafficQoSClass with each VCL or VPL. However, new insights
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

Replacing QoS Class, VPLs and VCLs are qualified in terms of
service category (atmServiceCategory). When properly configured,
(or VPLs) concatenated to form a VCC (or VPC) will all have the
service category class as that of the VCC (or VPC).

3.4. Max Active and Max Current VPI and VCI

A manager may wish to configure the maximum number of VPI and
bits that can be used to identify VPIs and VCIs on a given
interface. This value can be less than or equal to the
number of bits supported by the interface hardware, and is
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
on both ends of an ATM link. For example, the manager may not
allowed write access to the peer's MIB, or there may be
limitations on the peer device. Therefore, the two ATM devices
use ILMI to negotiate "Max Current" VPI and VCI bits, which is
maximum number of bits that both interfaces are willing to support
This is illustrated in Figure 5. The relationship between
different parameters is illustrated in Figure 6. Note that if
negotiation is not supported, then the devices have no choice but
use the configured Max Active bits, and assume that it has
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
"Max Active VPI Bits" is 6, so both interfaces set
"Max Current VPI Bits" to 6. Since IF c and IF d
are configured with "Max Active VPI Bits" of 8,
set their "Max Current VPI Bits" to 8.)

Figure 5


MSB
+----------------------------------------------------+
| | | | |
+----------------------------------------------------+
^ ^ ^ ^
| | | |
Max bits Max Bits Max
supported supported Active (config.) current (negotiated
by MIB by h/w Bits

Figure 6

4.

ATM management objects are used to manage ATM interfaces, ATM
links, ATM cross-connects, AAL5 entities and AAL5
supported by ATM hosts, ATM switches and ATM networks. This
provides an overview and background of how to use this MIB and
potential MIBs for this purpose

The purpose of this memo is primarily to manage ATM PVCs. ATM
are also represented by the management information in this MIB
However, full management of SVCs may require additional
which are beyond the scope of this memo

4.1.

In addition to the MIB module defined in this memo, other MIB
are necessary to manage ATM interfaces, links and cross-connects
Examples include MIB II for general system and interface
[16][17], the DS3 or SONET MIBs for management of
interfaces, and, as appropriate, MIB modules for applications
make use of ATM, such as SMDS. These MIB modules are outside
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

The managed ATM objects are arranged into the following tables

(1) ATM interface configuration
(2) ATM interface DS3 PLCP and TC sublayer
(3) ATM traffic parameter
(4) ATM interface virtual link (VPL/VCL)

(5) ATM VP/VC cross-connect
(6) AAL5 connection performance statistics

Note that, managed objects for activation/deactivation of OAM
flows and ATM traps notifying virtual connection or virtual
failures are outside the scope of this memo

4.3. ATM Interface Configuration

This table contains information on ATM cell layer configuration
local ATM interfaces on an ATM device in addition to the
on such interfaces contained in the ifTable

4.4. ATM Interface DS3 PLCP and TC Layer

These tables provide performance statistics of the DS3 PLCP and
sublayer of local ATM interfaces on a managed ATM device. DS3
and TC sublayer are currently used to carry ATM cells
over DS3 and SONET transmission paths

4.5. ATM Virtual Link and Cross-Connect

ATM virtual link and cross-connect tables model bi-directional
virtual links and ATM cross-connects. The ATM VP/VC link tables
implemented in an ATM host, ATM switch and ATM network. The
switch and ATM network also implement the ATM VP/VC cross-
tables. Both link and cross-connect tables are implemented in
carrier's network for Customer Network Management (CNM) purposes

The ATM virtual link tables are used to create, delete or modify
virtual links in an ATM host, ATM switch and ATM network.
virtual link tables along with the cross-connect tables are used
create, delete or modify ATM cross-connects in an ATM switch or
network (e.g., for CNM purposes).

For a PVC, the cross-connect between two VPLs is represented in
atmVpCrossConnectTable of the ATM-MIB, indexed by
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
atmVcCrossConnectTable of the ATM-MIB, indexed by
atmVclCrossConnectIdentifier values for the two VCLs

For an SVC or Soft PVC the VPL and VCL tables defined in this
are used. Hoewever, for an SVC or Soft PVC the cross-connect
two VPLs is represented in the atmSvcVpCrossConnectTable of
ATM2-MIB, indexed by the atmVplCrossConnectIdentifier values for
two VPLs, and the cross-connect between two VCLs is represented
the atmSvcVcCrossConnectTable of the ATM2-MIB, indexed by
atmVclCrossConnectIdentifier values for the two VCLs

Note: The ATM2-MIB module was being defined in a separate memo at
time of this publication. Please consult the RFC directory for
exact reference

5. Application of MIB II to

5.1. The System

For the purposes of the sysServices object in the System Group of
II [16], ATM is a data link layer protocol. Thus, for ATM
and ATM networks, sysServices will have the value "2".

5.2. The Interface

The Interfaces Group of MIB II defines generic managed objects
managing interfaces. This memo contains the media-
extensions to the Interfaces Group for managing ATM interfaces

This memo assumes the interpretation of the Interfaces Group to be
accordance with [17] which states that the interfaces table (ifTable
contains information on the managed resource's interfaces and
each sub-layer below the internetwork layer of a network interface
considered an interface. Thus, the ATM cell layer interface
represented as an entry in the ifTable. This entry is concerned
the ATM cell layer as a whole, and not with individual
connections which are managed via the ATM-specific managed
specified in this memo. The inter-relation of entries in the
is defined by Interfaces Stack Group defined in [17].

5.2.1. Support of the ATM Cell Layer by

Some specific interpretations of ifTable for the ATM cell
follow






Tesink Standards Track [Page 10]

RFC 2515 ATM Management Objects February 1999


Object Use for the generic ATM
====== =============================

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
for use by the ATM layer

ifPhysAddress The interface's address at the ATM
sublayer; the ATM address which would be used as the
of the Called Party Address Information Element (IE) of
signalling message for a connection which either
- would terminate at this interface,
- for which the Called Party Address
would need to be replaced by the Called Party
IE before the message was forwarded to any
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
would be used as above in the event that signalling
supported. If the interface has multiple such addresses
then ifPhysAddress is its primary address. If
interface has no addresses, then ifPhysAddress is an
string of zero length. Address encoding is as per [20].
Note that addresses assigned for purposes other than
listed above (e.g., an address associated with the
provider side of a public network UNI) may be
through atmInterfaceSubscrAddress

ifAdminStatus See [17].

ifOperStatus Assumes the value down(2) if the ATM
layer is down

ifLastChange See [17].

ifInOctets The number of received octets over
interface, i.e., the number of received, assigned
multiplied by 53.

ifOutOctets The number of transmitted octets over the interface
i.e., the number of transmitted, assigned cells
by 53.



Tesink Standards Track [Page 11]

RFC 2515 ATM Management Objects February 1999


ifInErrors The number of cells dropped due to uncorrectable
errors

ifInUnknownProtos The number of received cells discarded during
header validation, including cells with
VPI/VCI values, and cells with invalid cell
patterns. If cells with undefined PTI values
discarded, they are also counted here

ifOutErrors See [17].

ifName Textual name (unique on this system) of
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;
if required by the compliance statements in [17].

ifHCOutOctets The 64-bit version of ifOutOctets;
if required by the compliance statements in [17].

ifAlias The non-volatile 'alias' name for the
as specified by a network manager

6. Support of the AAL3/4 Based

For the management of AAL3/4 CPCS layer, see [18].

7. Support of the AAL5 Managed

Support of AAL5 managed objects in an ATM switch and ATM host
described below

7.1. Managing AAL5 in a

Managing AAL5 in a switch involves

(1) performance management of an AAL5 entity
an internal resource in a

(2) performance management of AAL5 per virtual





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
managed in a switch for only those virtual connections that
AAL5 and are terminated at the AAL5 entity in the switch. Note that
the virtual channels within the ATM UNIs carrying AAL5 will
switched by the ATM switching fabric (termed as ATM Entity in
figure) to the virtual channels on a proprietary internal
associated with the AAL5 process (termed as AAL5 Entity in
figure). Therefore, performance management of the AAL5 resource
the switch will be modeled using the ifTable through an
(pseudo-ATM) virtual interface and the AAL5 performance
per virtual connection will be supported using an additional AAL
connection table in the ATM MIB. The association between the AAL
virtual link at the proprietary virtual, internal interface and
ATM virtual link at the ATM interface will be derived from
virtual channel cross-connect table and the virtual channel
table in the ATM MIB. Note that for the proprietary virtual
the traffic transmit and receive conventions in the virtual
link table are as follows

Transmitting traffic: ATM Entity ---> AAL5
Receiving traffic: ATM Entity <--- AAL5

___________________________
| |
| ============= |
| | AAL5 | |
| | Entity | |
| ============= |
| | |
| -----Prop. Virtual
| | |
| ============= |
| | ATM | |
| | Entity | |
| ============= |
|_____|__|__|__|__|_______|
| | | | |
---------------- ATM
| | | | |
| | | | |
v v v v

Figure 7: Model of an AAL5 Entity in a








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

7.2. Managing AAL5 in a

Managing AAL5 in a host involves managing the AAL5 sublayer
as shown in Figure 9 and 10. The AAL5 sublayer is stacked
over the ATM sublayer. The ifTable is applied to the AAL5
as defined in Section 10.3.

___________________________
| |
| ============= |
| | AAL5 | |
| | Entity | |
| ============= |
| | ATM | |
| | Entity | |
| ============= |
|___________|_____________|
|
__|__ ATM
|
|


Figure 9: Model of an AAL5 Entity in a

__________________
| |
| AAL5 |
|________________|
| |
| ATM Layer |
|________________|
| |
| Physical Layer
|________________|

Figure 10: AAL5 Entity's Interface Stack in a



Tesink Standards Track [Page 14]

RFC 2515 ATM Management Objects February 1999


7.3. Support of AAL5 by

The AAL5 entity in an ATM device (e.g., switch or host) is
using the ifTable. There are additional counters specified for AAL
than those specified in the ATM B-ICI document [21].
interpretations of ifTable for the AAL5 CPCS layer are as follows

Object Use for AAL5 CPCS layer
====== ==============================

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
AAL5 CPCS layer that can be
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 AAL
layer is down

ifLastChange See [17].

ifInOctets The number of received AAL5 CPCS PDU octets

ifOutOctets The number of AAL5 CPCS PDU
transmitted

ifInUcastPkts The number of received AAL5 CPCS PDUs
to a higher-layer

ifOutUcastPkts The number of AAL5 CPCS PDUs received from
higher-layer for transmission
[Note: The number of AAL5 PDUs
transmitted is the number received from
higher-layer for transmission minus any
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
be transmitted due to errors

ifOutDiscards Number of AAL5 CPCS PDUs received
transmission that are discarded
Possible reason may be output
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
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
as specified by a network manager

7.4. Support of Proprietary Virtual Interface by

Specific interpretations of ifTable for the proprietary virtual
internal interface associated with an AAL5 entity in an ATM
are as follows







Tesink Standards Track [Page 16]

RFC 2515 ATM Management Objects February 1999


Object Use for proprietary virtual, internal
associated with AAL
====== ===============================================

ifIndex Each proprietary virtual, internal
associated with AAL entities is represented by
ifEntry

ifDescr Description of the proprietary virtual,
interface associated with AAL entities

ifType The value that is allocated for
virtual, internal interface is 53.

ifSpeed See [17]. Set to 0 if the speed is
known

ifPhysAddress See [17]. An octet string of zero
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
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
as specified by a network manager

7.5. AAL5 Connection Performance Statistics

An AAL5 connection table is used to provide AAL5
information for each AAL5 virtual connection that is terminated
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

The ILMI MIBs are specified by the ATM Forum as a set of
MIBs, all currently defined in the ILMI Specification [23]. The
protocols and MIBs allow two connected ATM Interface
Entities (IMEs) to exchange bi-directional parameters, mainly
facilitate auto-configuration between ATM peer entities. The
of the ATM management functions by the ILMI MIBs and those
in this memo are compared in Table 1. In this table, "yes" in
"ILMI MIBs" column indicates that the management functions
supported by the ILMI MIBs. The parenthesized numbers in the "
memo" column correspond to the sets of tables enumerated in
6.2.

For that subset of management information which the ILMI MIBs
this memo have in common, every effort has been made to
identical semantics and syntax, even though the MIB objects
identified using different OBJECT IDENTIFIERs

Table 1 - Structuring of ATM Managed
______________________________________________________________
| |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


*The operational, administrative, and last change status of the
interface and the physical transmission type shall be supported
the interface table in MIB II [16][17]. ILMI does not contain
administrative and last change status of the ATM interface

** The ILMI MIB contains read-only objects for various parameters
the ATM interface level

***The ILMI MIBs contain local and end-to-end operational status
the VPC/VCC segment. However, it does not contain the VPC/
administrative and last change status and the VCC AAL information

9.

ATM-MIB DEFINITIONS ::=


MODULE-IDENTITY, OBJECT-TYPE
Counter32, Integer32, IpAddress, mib-2
FROM SNMPv2-
DisplayString, RowStatus,
FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-
FROM SNMPv2-
InterfaceIndex,
FROM IF-
AtmAddr, AtmConnKind, AtmConnCastType
AtmServiceCategory, AtmTrafficDescrParamIndex
AtmVpIdentifier, AtmVcIdentifier
AtmVorXAdminStatus, AtmVorXLastChange
AtmVorXOperStatus,
FROM ATM-TC-MIB


atmMIB MODULE-
LAST-UPDATED "9810191200Z
ORGANIZATION "IETF AToM MIB Working Group
CONTACT-
" Kaj
Postal:
331 Newman Springs
Red Bank, NJ 07701
Tel: 732-758-5254
Fax: 732-758-2269
E-mail: kaj@bellcore.com

"This is the MIB Module for ATM and AAL5-
objects for managing ATM interfaces, ATM



Tesink Standards Track [Page 20]

RFC 2515 ATM Management Objects February 1999


links, ATM cross-connects, AAL5 entities,
and AAL5 connections."
REVISION "9810191200Z

"The initial revision of this module was
as RFC 1695. Key revisions include
o Textual Conventions and OBJECT IDENTITIES
been moved to a separate MIB module
o Applicability of objects to PVCs, SVCs and
PVCs has been clarified
o DEFVAL clauses have been added
o The relationship of ifIndex values with
layers and sublayers related to ATM has
clarified
o atmTrafficQosClass has been
and replaced with atmServiceCategory
o atmInterfaceCurrentMaxVpiBits
atmInterfaceCurrentMaxVciBits have been added
a description on their relationship with
objects
o atmInterfaceAddressType and
have been deprecated and replaced
atmInterfaceSubscrAddress
o atmInterfaceTCAlarmState has been clarified
o atmTrafficDescrParamIndexNext has been
in order to provide a manager a
atmTrafficDescrParamIndex value
o The atmTrafficFrameDiscard capability has been added
o A connection topology type (atmVpl/VclCastType)
a call control type (atmVpl/VclConnKind) have
added
o aal2 has been added to atmVccAalType."
REVISION "9406072245Z

"The RFC1695 version of this MIB module."
::= { mib-2 37 }


atmMIBObjects OBJECT IDENTIFIER ::= {atmMIB 1}

-- {atmMIBObjects 1} has been moved to a
-- specification [19].


-- This ATM MIB Module consists of the following tables
-- (1) ATM Interface configuration
-- (2) ATM Interface DS3 PLCP
-- (3) ATM Interface TC Sublayer



Tesink Standards Track [Page 21]

RFC 2515 ATM Management Objects February 1999


-- (4) Atm Traffic Descriptor
-- (5) ATM Interface VPL configuration
-- (6) ATM Interface VCL configuration
-- (7) ATM VP Cross Connect table (for PVCs
-- (8) ATM VC Cross Connect table (for PVCs
-- (9) ATM Interface AAL5 VCC performance
--

-- ATM Interface Configuration Parameters

-- This table contains ATM
-- configuration information associated
-- an ATM interface beyond
-- supported using the ifTable




atmInterfaceConfTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS

"This table contains ATM local
configuration parameters, one entry per
interface port."
::= { atmMIBObjects 2 }

atmInterfaceConfEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS

"This list contains ATM interface
parameters and state variables and is
by ifIndex values of ATM interfaces."
INDEX { ifIndex }
::= { atmInterfaceConfTable 1}

AtmInterfaceConfEntry ::= SEQUENCE {
atmInterfaceMaxVpcs INTEGER
atmInterfaceMaxVccs INTEGER
atmInterfaceConfVpcs INTEGER
atmInterfaceConfVccs INTEGER
atmInterfaceMaxActiveVpiBits INTEGER
atmInterfaceMaxActiveVciBits INTEGER
atmInterfaceIlmiVpi AtmVpIdentifier
atmInterfaceIlmiVci AtmVcIdentifier



Tesink Standards Track [Page 22]

RFC 2515 ATM Management Objects February 1999


atmInterfaceAddressType INTEGER
atmInterfaceAdminAddress AtmAddr
atmInterfaceMyNeighborIpAddress IpAddress
atmInterfaceMyNeighborIfName DisplayString
atmInterfaceCurrentMaxVpiBits INTEGER
atmInterfaceCurrentMaxVciBits INTEGER
atmInterfaceSubscrAddress
}


atmInterfaceMaxVpcs OBJECT-
SYNTAX INTEGER (0..4096)
MAX-ACCESS read-
STATUS

"The maximum number of VPCs (PVPCs and SVPCs
supported at this ATM interface. At the ATM UNI
the maximum number of VPCs (PVPCs and SVPCs
ranges from 0 to 256 only."
::= { atmInterfaceConfEntry 1}

atmInterfaceMaxVccs OBJECT-
SYNTAX INTEGER (0..65536)
MAX-ACCESS read-
STATUS

"The maximum number of VCCs (PVCCs and SVCCs
supported at this ATM interface."
::= { atmInterfaceConfEntry 2}

atmInterfaceConfVpcs OBJECT-
SYNTAX INTEGER (0..4096)
MAX-ACCESS read-
STATUS

"The number of VPCs (PVPC, Soft PVPC and SVPC
currently in use at this ATM interface. It
the number of PVPCs and Soft PVPCs that are
at the interface, plus the number of
that are currently established at
interface

At the ATM UNI, the configured number
VPCs (PVPCs and SVPCs) can range
0 to 256 only."
::= { atmInterfaceConfEntry 3}

atmInterfaceConfVccs OBJECT-



Tesink Standards Track [Page 23]

RFC 2515 ATM Management Objects February 1999


SYNTAX INTEGER (0..65536)
MAX-ACCESS read-
STATUS

"The number of VCCs (PVCC, Soft PVCC and SVCC
currently in use at this ATM interface. It
the number of PVCCs and Soft PVCCs that are
at the interface, plus the number of
that are currently established at
interface."
::= { atmInterfaceConfEntry 4}

atmInterfaceMaxActiveVpiBits OBJECT-
SYNTAX INTEGER (0..12)
MAX-ACCESS read-
STATUS

"The maximum number of active VPI
configured for use at the ATM interface
At the ATM UNI, the maximum number of
VPI bits configured for use ranges
0 to 8 only."
::= { atmInterfaceConfEntry 5}

atmInterfaceMaxActiveVciBits OBJECT-
SYNTAX INTEGER (0..16)
MAX-ACCESS read-
STATUS

"The maximum number of active VCI
configured for use at this ATM interface."
::= { atmInterfaceConfEntry 6}

atmInterfaceIlmiVpi OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The VPI value of the VCC
the ILMI at this ATM interface. If the values
atmInterfaceIlmiVpi and atmInterfaceIlmiVci
both equal to zero then the ILMI is
supported at this ATM interface."
DEFVAL { 0 }
::= { atmInterfaceConfEntry 7}

atmInterfaceIlmiVci OBJECT-
SYNTAX



Tesink Standards Track [Page 24]

RFC 2515 ATM Management Objects February 1999


MAX-ACCESS read-
STATUS

"The VCI value of the VCC
the ILMI at this ATM interface. If the values
atmInterfaceIlmiVpi and atmInterfaceIlmiVci
both equal to zero then the ILMI is
supported at this ATM interface."
DEFVAL { 16 }
::= { atmInterfaceConfEntry 8}

atmInterfaceAddressType OBJECT-
SYNTAX INTEGER {
private(1),
nsapE164(2),
nativeE164(3),
other(4)
}
MAX-ACCESS read-
STATUS

"The type of primary ATM address
for use at this ATM interface."
::= { atmInterfaceConfEntry 9 }

-- The atmInterfaceAdminAddress object has been replaced
-- atmInterfaceSubscrAddress

atmInterfaceAdminAddress OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The primary address assigned for administrative purposes
for example, an address associated with
service provider side of a public network
(thus, the value of this address
with the value of ifPhysAddress at the host side).
If this interface has no assigned
address, or when the address used
administrative purposes is the same as that
for ifPhysAddress, then this is an octet string
zero length."
::= { atmInterfaceConfEntry 10 }

atmInterfaceMyNeighborIpAddress OBJECT-
SYNTAX
MAX-ACCESS read-



Tesink Standards Track [Page 25]

RFC 2515 ATM Management Objects February 1999


STATUS

"The IP address of the neighbor system connected
the far end of this interface, to which a
Management Station can send SNMP messages, as
datagrams sent to UDP port 161, in order to
network management information concerning
operation of that system. Note that the
of this object may be obtained in different ways
e.g., by manual configuration, or through
interaction with the neighbor system."
::= { atmInterfaceConfEntry 11 }

atmInterfaceMyNeighborIfName OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The textual name of the interface on the
system on the far end of this interface, and
which this interface connects. If the
system is manageable through SNMP and
the object ifName, the value of this object
be identical with that of ifName for the
of the lowest level physical
for this port. If this interface does not have
textual name, the value of this object is a
length string. Note that the value of this
may be obtained in different ways, e.g., by
configuration, or through ILMI interaction
the neighbor system."
::= { atmInterfaceConfEntry 12 }

atmInterfaceCurrentMaxVpiBits OBJECT-
SYNTAX INTEGER (0..12)
MAX-ACCESS read-
STATUS

"The maximum number of VPI Bits that
currently be used at this ATM interface
The value is the minimum
atmInterfaceMaxActiveVpiBits, and
atmInterfaceMaxActiveVpiBits of the interface'
UNI/NNI peer

If the interface does not negotiate
its peer to determine the number of VPI
that can be used on the interface, then



Tesink Standards Track [Page 26]

RFC 2515 ATM Management Objects February 1999


value of this object must
atmInterfaceMaxActiveVpiBits."
::= { atmInterfaceConfEntry 13 }

atmInterfaceCurrentMaxVciBits OBJECT-
SYNTAX INTEGER (0..16)
MAX-ACCESS read-
STATUS

"The maximum number of VCI Bits that
currently be used at this ATM interface
The value is the minimum
atmInterfaceMaxActiveVciBits, and
atmInterfaceMaxActiveVciBits of the interface'
UNI/NNI peer

If the interface does not negotiate
its peer to determine the number of VCI
that can be used on the interface, then
value of this object must
atmInterfaceMaxActiveVciBits."
::= { atmInterfaceConfEntry 14 }

atmInterfaceSubscrAddress OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The identifier assigned by a service
to the network side of a public network UNI
If this interface has no assigned service
address, or for other interfaces this is an octet
of zero length."
::= { atmInterfaceConfEntry 15 }

-- The ATM Interface DS3 PLCP

-- This table contains the DS3 PLCP configuration
-- state parameters of those ATM
-- which use DS3 PLCP for carrying ATM cells over DS3.

atmInterfaceDs3PlcpTable OBJECT-
SYNTAX SEQUENCE OF AtmInterfaceDs3
MAX-ACCESS not-
STATUS

"This table contains ATM interface DS3
parameters and state variables, one entry



Tesink Standards Track [Page 27]

RFC 2515 ATM Management Objects February 1999


ATM interface port."
::= { atmMIBObjects 3}

atmInterfaceDs3PlcpEntry OBJECT-
SYNTAX AtmInterfaceDs3
MAX-ACCESS not-
STATUS

"This list contains DS3 PLCP parameters
state variables at the ATM interface and
indexed by the ifIndex value of the ATM interface."
INDEX { ifIndex }
::= { atmInterfaceDs3PlcpTable 1}

AtmInterfaceDs3PlcpEntry ::= SEQUENCE {
atmInterfaceDs3PlcpSEFSs Counter32,
atmInterfaceDs3PlcpAlarmState INTEGER
atmInterfaceDs3PlcpUASs Counter32
}


atmInterfaceDs3PlcpSEFSs OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"The number of DS3 PLCP Severely Errored
Seconds (SEFS). Each SEFS represents
one-second interval which
one or more SEF events."
::= { atmInterfaceDs3PlcpEntry 1}

atmInterfaceDs3PlcpAlarmState OBJECT-
SYNTAX INTEGER {
noAlarm(1),
receivedFarEndAlarm(2),
incomingLOF(3)
}
MAX-ACCESS read-
STATUS

"This variable indicates if there is
alarm present for the DS3 PLCP. The
receivedFarEndAlarm means that the DS3
has received an incoming
Signal, the value incomingLOF means
the DS3 PLCP has declared a loss of frame (LOF
failure condition, and the value



Tesink Standards Track [Page 28]

RFC 2515 ATM Management Objects February 1999


means that there are no alarms present
Transition from the failure to the no alarm
occurs when no defects (e.g., LOF) are
for more than 10 seconds."
::= { atmInterfaceDs3PlcpEntry 2}

atmInterfaceDs3PlcpUASs OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"The counter associated with the number
Unavailable Seconds encountered by the PLCP."
::= { atmInterfaceDs3PlcpEntry 3}


-- The ATM Interface TC Sublayer

-- This table contains TC sublayer configuration
-- state parameters of those ATM
-- which use TC sublayer for carrying ATM cells
-- SONET/SDH or DS3.


atmInterfaceTCTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS

"This table contains ATM interface
Sublayer parameters and state variables
one entry per ATM interface port."
::= { atmMIBObjects 4}

atmInterfaceTCEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS

"This list contains TC Sublayer
and state variables at the ATM interface and
indexed by the ifIndex value of the ATM interface."
INDEX {ifIndex }
::= { atmInterfaceTCTable 1}

AtmInterfaceTCEntry ::= SEQUENCE {
atmInterfaceOCDEvents Counter32,
atmInterfaceTCAlarmState



Tesink Standards Track [Page 29]

RFC 2515 ATM Management Objects February 1999


}

atmInterfaceOCDEvents OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"The number of times the Out of
Delineation (OCD) events occur. If
consecutive ATM cells have Header
Control (HEC) violations, an OCD event occurs
A high number of OCD events may indicate
problem with the TC Sublayer."
::= { atmInterfaceTCEntry 1}


atmInterfaceTCAlarmState OBJECT-
SYNTAX INTEGER {
noAlarm(1),
lcdFailure(2)
}
MAX-ACCESS read-
STATUS

"This variable indicates if there is
alarm present for the TC Sublayer. The
lcdFailure(2) indicates that the TC
is currently in the Loss of Cell
(LCD) defect maintenance state. The
noAlarm(1) indicates that the TC
is currently not in the LCD
maintenance state."
::= { atmInterfaceTCEntry 2}

-- ATM Traffic Descriptor Parameter

-- This table contains a set of self-
-- ATM traffic parameters including
-- ATM traffic service category

-- The ATM virtual link tables (i.e., VPL and VCL tables
-- will use this ATM Traffic Descriptor
-- to assign traffic parameters and service
-- to the receive and transmit directions
-- the ATM virtual links (i.e., VPLs and VCLs).
-- The ATM VPL or VCL table will indicate a
-- in the
-- using its atmTrafficDescrParamIndex value



Tesink Standards Track [Page 30]

RFC 2515 ATM Management Objects February 1999


-- The management application can then compare a set
-- ATM traffic parameters with a single value

-- If no suitable row(s) in the
-- exists, the manager must create a new row(s) in
-- table. If such a row is created, agent checks
-- sanity of that set of ATM traffic parameter values

-- The manager may use
-- in order to obtain a free
-- value

-- When creating a new row, the parameter
-- will be checked for self-consistency
-- Predefined/template rows may be supported

-- A row in the atmTrafficDescrParamTable is
-- by setting the atmTrafficDescrRowStatus to destroy(6).
-- The agent will check whether this row is still in
-- by any entry of the atmVplTable or atmVclTable
-- The agent denies the request if the row is still
-- use

-- The ATM Traffic Descriptor Parameter


atmTrafficDescrParamTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS

"This table contains information on ATM
descriptor type and the associated parameters."
::= { atmMIBObjects 5}

atmTrafficDescrParamEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS

"This list contains ATM traffic
type and the associated parameters."
INDEX {atmTrafficDescrParamIndex
::= { atmTrafficDescrParamTable 1}

AtmTrafficDescrParamEntry ::= SEQUENCE {
atmTrafficDescrParamIndex AtmTrafficDescrParamIndex
atmTrafficDescrType OBJECT IDENTIFIER



Tesink Standards Track [Page 31]

RFC 2515 ATM Management Objects February 1999


atmTrafficDescrParam1 Integer32,
atmTrafficDescrParam2 Integer32,
atmTrafficDescrParam3 Integer32,
atmTrafficDescrParam4 Integer32,
atmTrafficDescrParam5 Integer32,
atmTrafficQoSClass INTEGER
atmTrafficDescrRowStatus RowStatus
atmServiceCategory AtmServiceCategory
atmTrafficFrameDiscard
}

atmTrafficDescrParamIndex OBJECT-
SYNTAX AtmTrafficDescrParamIndex (1..2147483647)
MAX-ACCESS not-
STATUS

"This object is used by the virtual
table (i.e., VPL or VCL table
to identify the row of this table
When creating a new row in the
the value of this index may be
by retrieving the value
atmTrafficDescrParamIndexNext."
::= { atmTrafficDescrParamEntry 1}

atmTrafficDescrType OBJECT-
SYNTAX OBJECT
MAX-ACCESS read-
STATUS

"The value of this object identifies the
of ATM traffic descriptor
The type may indicate no traffic descriptor
traffic descriptor with one or more parameters
These parameters are specified as a
vector, in the corresponding instances of
objects
atmTrafficDescrParam
atmTrafficDescrParam
atmTrafficDescrParam
atmTrafficDescrParam
atmTrafficDescrParam5."
DEFVAL { atmNoClpNoScr }
::= { atmTrafficDescrParamEntry 2}

atmTrafficDescrParam1 OBJECT-
SYNTAX Integer32
MAX-ACCESS read-



Tesink Standards Track [Page 32]

RFC 2515 ATM Management Objects February 1999


STATUS

"The first parameter of the ATM traffic
used according to the value
atmTrafficDescrType."
DEFVAL { 0 }
::= { atmTrafficDescrParamEntry 3}

atmTrafficDescrParam2 OBJECT-
SYNTAX Integer32
MAX-ACCESS read-
STATUS

"The second parameter of the ATM traffic
used according to the value
atmTrafficDescrType."
DEFVAL { 0 }
::= { atmTrafficDescrParamEntry 4}

atmTrafficDescrParam3 OBJECT-
SYNTAX Integer32
MAX-ACCESS read-
STATUS

"The third parameter of the ATM traffic
used according to the value
atmTrafficDescrType."
DEFVAL { 0 }
::= { atmTrafficDescrParamEntry 5}

atmTrafficDescrParam4 OBJECT-
SYNTAX Integer32
MAX-ACCESS read-
STATUS

"The fourth parameter of the ATM traffic
used according to the value
atmTrafficDescrType."
DEFVAL { 0 }
::= { atmTrafficDescrParamEntry 6}

atmTrafficDescrParam5 OBJECT-
SYNTAX Integer32
MAX-ACCESS read-
STATUS

"The fifth parameter of the ATM traffic
used according to the value



Tesink Standards Track [Page 33]

RFC 2515 ATM Management Objects February 1999


atmTrafficDescrType."
DEFVAL { 0 }
::= { atmTrafficDescrParamEntry 7}

atmTrafficQoSClass OBJECT-
SYNTAX INTEGER (0..255)
MAX-ACCESS read-
STATUS

"The value of this object identifies the QoS Class
Four Service classes have
specified in the ATM Forum UNI Specification
Service Class A: Constant bit rate video
Circuit
Service Class B: Variable bit rate video/
Service Class C: Connection-oriented
Service Class D: Connectionless
Four QoS classes numbered 1, 2, 3, and 4
been specified with the aim to support
classes A, B, C, and D respectively
An unspecified QoS Class numbered `0' is
for best effort traffic."
DEFVAL { 0 }
::= { atmTrafficDescrParamEntry 8}

atmTrafficDescrRowStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"This object is used to
a new row or modify or delete
existing row in this table."
DEFVAL { active }
::= {atmTrafficDescrParamEntry 9}

atmServiceCategory OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The ATM service category."
DEFVAL { ubr }
::= { atmTrafficDescrParamEntry 10}


atmTrafficFrameDiscard OBJECT-
SYNTAX



Tesink Standards Track [Page 34]

RFC 2515 ATM Management Objects February 1999


MAX-ACCESS read-
STATUS

"If set to 'true', this object indicates that the
is requested to treat data for this connection, in
given direction, as frames (e.g. AAL5 CPCS_PDU's)
than as individual cells. While the
implementation is network-specific, this treatment
for example involve discarding entire frames
congestion, rather than a few cells from many frames."
DEFVAL { true }
::= { atmTrafficDescrParamEntry 11 }

-- ATM Interface Virtual Path Link (VPL)

-- This table contains configuration and
-- information of a bi-directional Virtual Path
-- (VPL

-- This table can be used to create, delete or
-- a VPL that is terminated in an ATM host or switch
-- This table can also be used to create, delete
-- modify a VPL which is cross-connected to
-- VPL

-- In the example below, the traffic flows on the
-- and transmit directions of the VPLs are
-- by atmVplReceiveTrafficDescrIndex
-- atmVplTransmitTrafficDescrIndex respectively
-- The cross-connected VPLs are identified
-- atmVplCrossConnectIdentifier



-- ________________________________
-- | |
-- VPL | ATM Host, Switch, or Network |
-- receive | |
-- ========> X X <=======
-- <======== X X ========>
-- transmit | |
-- |______________________________|



-- The ATM Interface VPL





Tesink Standards Track [Page 35]

RFC 2515 ATM Management Objects February 1999


atmVplTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS

"The Virtual Path Link (VPL) table.
bi-directional VPL is modeled as one
in this table. This table can be used
PVCs, SVCs and Soft PVCs
Entries are not present in this table
the VPIs used by entries in the atmVclTable."
::= { atmMIBObjects 6}

atmVplEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS

"An entry in the VPL table. This entry
used to model a bi-directional VPL
To create a VPL at an ATM interface
either of the following procedures are used

Negotiated VPL

(1) The management application
a VPL entry in the
by setting atmVplRowStatus to createAndWait(5).
This may fail for the following reasons
- The selected VPI value is unavailable
- The selected VPI value is in use
Otherwise, the agent creates a row
reserves the VPI value on that port

(2) The manager selects an existing row(s) in
atmTrafficDescrParamTable
thereby, selecting a set of self-
ATM traffic parameters and the service
for receive and transmit directions of the VPL

(2a) If no suitable row(s) in
atmTrafficDescrParamTable exists
the manager must create a new row(s
in that table

(2b) The manager characterizes the VPL's
parameters through setting
atmVplReceiveTrafficDescrIndex and



Tesink Standards Track [Page 36]

RFC 2515 ATM Management Objects February 1999


atmVplTransmitTrafficDescrIndex
in the VPL table, which point to the
containing desired ATM traffic parameter
in the atmTrafficDescrParamTable. The
will check the availability of resources
may refuse the request
If the transmit and receive service
are inconsistent, the agent sho