Network Working Group M. Ahmed Request for Comments: 1695 K. Tesink Category: Standards Track Editors Bell Communications Research August 1994 Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2 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. Table of Contents 1. Introduction ............................................. 2 2. The SNMPv2 Network Management Framework .................. 2 3. Object Definitions ....................................... 2 4. ATM Terminology .......................................... 3 4.1 VCL/VPL and VCC/VPC ..................................... 3 4.2 PVC and SVC ............................................. 5 4.3 Traffic Management Parameters ........................... 5 4.3.1 Traffic Policing and Traffic Shaping Parameters ...... 5 4.3.2 Cell Loss Priority .................................... 6 4.3.3 QoS Class ............................................. 6 5. Overview ................................................. 7 5.1 Background .............................................. 7 5.2 Structure of the MIB .................................... 7 5.3 ATM Interface Configuration Group ....................... 7 5.4 ATM Interface DS3 PLCP and TC Layer Groups .............. 8 5.5 ATM Virtual Link and Cross-Connect Groups ............... 8 6. Application of MIB II to ATM ............................. 8 6.1 The System Group ........................................ 8 6.2 The Interface Group ..................................... 8 6.2.1 Support of the ATM Cell Layer by ifTable .............. 9 7. Support of the AAL3/4 Based Interfaces ................... 10 8. Support of the AAL5 Managed Objects ...................... 10 8.1 Managing AAL5 in a Switch ............................... 11 8.2 Managing AAL5 in a Host ................................. 12 8.3 Support of AAL5 by ifTable .............................. 13 8.4 Support of Proprietary Virtual Interface by ifT-able .. 14 8.5 AAL5 Connection Performance Statistics Group ............ 15 Ahmed & Tesink [Page 1] RFC 1695 ATM Management Objects August 1994 9. ILMI MIB and the ATM Managed Objects ..................... 15 10. Definitions ............................................. 18 11. Acknowledgments ......................................... 72 12. References .............................................. 72 13. Security Considerations ................................. 73 14. Authors' Addresses ...................................... 73 1. Introduction 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 specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: 0 RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. 0 STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. 0 RFC 1445 [3] which defines the administrative and other architectural aspects of the framework. 0 RFC 1448 [4] which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 3. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we Ahmed & Tesink [Page 2] RFC 1695 ATM Management Objects August 1994 often use a textual string, termed the descriptor, to also refer to the object type. 4. ATM Terminology Some basic ATM terminologies are described in this section to facilitate defining the ATM managed objects. 4.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. <-----------------------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 Ahmed & Tesink [Page 3] RFC 1695 ATM Management Objects August 1994 <-----------------------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 at one end of the VCC/VPC supports its end of the VCC/VPC plus the VCLs or VPLs on its external interfaces, and each switch through which the VCC/VPC passes, supports the multiple VCLs/VPLs on that switch's external interfaces and the cross- connection of those VCLs/VPLs through that switch. 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. Ahmed & Tesink [Page 4] RFC 1695 ATM Management Objects August 1994 <---------------------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, QoS Class 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. 4.2. PVC and SVC 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. 4.3. Traffic Management Parameters 4.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 activated on an incoming VCL or VPL as shown in Figure 3. The use of the traffic enforcer at the ingress of the connection is to make sure that the user traffic does not exceed the Ahmed & Tesink [Page 5] RFC 1695 ATM Management Objects August 1994 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 3: 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 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. ATM Forum has specified seven traffic descriptor types including one for the best effort traffic [9]. 4.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. 4.3.3. QoS Class A VCC or VPC is associated with one of a number of Quality of Service (QoS) classes. The following service classes have been specified: Service Class A: Constant bit rate video and Circuit emulation Service Class B: Variable bit rate video/audio Service Class C: Connection-oriented data Service Class D: Connectionless data Four QoS classes numbered 1, 2, 3, and 4 have been specified with the aim of supporting service classes A, B, C, and D respectively. The VCLs (or VPLs) concatenated to form a VCC (or VPC) will all have the same QoS class as that of the VCC (or VPC). The Cell Loss Ratio (CLR), Cell Delay Variation (CDV), and end-to-end Cell Delay (CD) parameters are defined as part of QoS Class definition. In addition, Ahmed & Tesink [Page 6] RFC 1695 ATM Management Objects August 1994 an unspecified QoS Class numbered 0 is specified for best effort traffic. 5. 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. 5.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 (RFC 1213 and RFC 1573), 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. 5.2. Structure of the MIB The managed ATM objects are arranged into the following groups: (1) ATM interface configuration group (2) ATM interface DS3 PLCP group (3) ATM interface TC Sublayer group (4) ATM interface virtual link (VPL/VCL) configuration groups (5) ATM VP/VC cross-connect groups (6) AAL5 connection performance statistics group 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. 5.3. ATM Interface Configuration Group This group contains information on ATM cell layer configuration of local ATM interfaces on an ATM device in addition to the information Ahmed & Tesink [Page 7] RFC 1695 ATM Management Objects August 1994 on such interfaces contained in the ifTable. 5.4. ATM Interface DS3 PLCP and TC Layer Groups These groups 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. 5.5. ATM Virtual Link and Cross-Connect Groups ATM virtual link and cross-connect groups model bi-directional ATM virtual links and ATM cross-connects. The ATM VP/VC link groups 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 groups. Both link and cross-connect groups are implemented in a carrier's network for Customer Network Management (CNM) purposes. The ATM virtual link groups are used to create, delete or modify ATM virtual links in an ATM host, ATM switch and ATM network. ATM virtual link groups along with the cross-connect groups are used to create, delete or modify ATM cross-connects in an ATM switch or ATM network (e.g., for CNM purposes). 6. Application of MIB II to ATM 6.1. The System Group For the purposes of the sysServices object in the System Group of MIB II [2], ATM is a data link layer protocol. Thus, for ATM switches and ATM networks, sysServices will have the value "2". 6.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 [5] 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 [5]. Ahmed & Tesink [Page 8] RFC 1695 ATM Management Objects August 1994 6.2.1. Support of the ATM Cell Layer by ifTable Some specific interpretations of ifTable for the ATM cell layer follow. 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 [9]. 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 atmInterfaceAdminAddress. ifAdminStatus See [5]. ifOperStatus Assumes the value down(2) if the ATM cell layer or any layer below that layer is down. Ahmed & Tesink [Page 9] RFC 1695 ATM Management Objects August 1994 ifLastChange See [5]. 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. 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 [5]. 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). ifPromiscuousMode Set to false(2). ifHighSpeed See [5]. ifHCInOctets The 64-bit version of ifInOctets; supported if required by the compliance statements in [5]. ifHCOutOctets The 64-bit version of ifOutOctets; supported if required by the compliance statements in [5]. 7. Support of the AAL3/4 Based Interfaces For the management of AAL3/4 CPCS layer, see [6]. 8. Support of the AAL5 Managed Objects Support of AAL5 managed objects in an ATM switch and ATM host are described below. Ahmed & Tesink [Page 10] RFC 1695 ATM Management Objects August 1994 8.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 AAL5 in a switch is modeled as shown in Figures 4 and 5. 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. ___________________________ | | | ============= | | | AAL5 | | | | Entity | | | ============= | | | | | -----Prop. Virtual Interface | | | | ============= | | | ATM | | | | Entity | | | ============= | |_____|__|__|__|__|_______| | | | | | ---------------- ATM UNIs | | | | | | | | | | v v v v v Figure 4 : Model of an AAL5 Entity in a Switch Ahmed & Tesink [Page 11] RFC 1695 ATM Management Objects August 1994 __________________ | | | AAL5 | |________________| | | | Prop. Virtual | | Interface | |________________| Figure 5 : AAL5 Entity's Interface Stack in a Switch 8.2. Managing AAL5 in a Host Managing AAL5 in a host involves managing the AAL5 sublayer interface as shown in Figures 6 and 7. The AAL5 sublayer is stacked directly over the ATM sublayer. The ifTable is applied to the AAL5 sublayer as defined in Section 8.3. ___________________________ | | | ============= | | | AAL5 | | | | Entity | | | ============= | | | ATM | | | | Entity | | | ============= | |___________|_____________| | __|__ ATM UNI | | v Figure 6 : Model of an AAL5 Entity in a Host __________________ | | | AAL5 | |________________| | | | ATM Layer | |________________| | | | Physical Layer| |________________| Ahmed & Tesink [Page 12] RFC 1695 ATM Management Objects August 1994 Figure 7 : AAL5 Entity's Interface Stack in a Host 8.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 [10]. 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 [5]. ifOperStatus Assumes the value down(2) if the AAL5 or any layer below that layer is down. ifLastChange See [5]. 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.] Ahmed & Tesink [Page 13] RFC 1695 ATM Management Objects August 1994 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). 8.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. 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 Ahmed & Tesink [Page 14] RFC 1695 ATM Management Objects August 1994 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 [5]. Set to 0 if the speed is not known. ifPhysAddress See [5]. An octet string of zero length if no address is used for this interface. ifAdminStatus See [5]. ifOperStatus See [5]. ifLastChange See [5]. ifName Textual name (unique on this system) of the interface or an octet string of zero length. ifHighSpeed See [5]. Set to 0 if the speed is not known. ifConnectorPresent Set to false (2). ifLinkUpDownTrapEnable Default is disabled (2). 8.5. AAL5 Connection Performance Statistics Group 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. 9. ILMI MIB and the ATM Managed Objects The ILMI MIB is specified by the ATM Forum in UNI specification [9], to manage local ATM UNIs. The support of the ATM management functions by the ILMI MIB and those contained in this memo are compared in Table 1. In this table, "yes" in the "ILMI MIB" column indicates that the management functions are supported by the ILMI MIB. The MIB groups in the "This memo" column are the groups listed in Section 5.2. For that subset of management information which the ILMI MIB and this memo have in common, every effort has been made to retain identical semantics and syntax, even though the MIB objects are identified Ahmed & Tesink [Page 15] RFC 1695 ATM Management Objects August 1994 using different OBJECT IDENTIFIERs. Table 1 - Structuring of ATM Managed Objects ______________________________________________________________ | |This |ILMI| ATM Mgmt.Inf. |ATM Managed Objects |memo |MIB | ______________|_________________________________|_______|____| Local Interface Information: _____________________________________________________________ ATM interface:| (1) port identifier |ATM MIB| | physical layer| (2) physical transmission types | gr.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 | gr.1 |yes | configuration | (3) configured VPCs/VCCs | | ** | | (4) ILMI VPI/VCI values | | | | (5) ATM address type | | | | (6) ATM administrative address | | | _____________________________________________________________ ATM interface:|(1) received/transmitted cells | | | cell layer |(2) cells with HEC error |MIB II |yes | performance |(3) cell header validation errors| | | _____________________________________________________________ ATM interface:|(1)DS3 PLCP severely errored |ATM MIB| | PLCP & TC | framing seconds | gr.2,3| | 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 | gr. 4|yes | |(3)VCL/VPL administrative status | |*** | |(4)VCL/VPL last change status | | | |(5)transmit/receive traffic/QoS | | | | parameters | | | |(6)AAL type | | | |(7)transmit/receive AAL5 SDU size| | | |(8)AAL5 encapsulation type | | | _____________________________________________________________ Ahmed & Tesink [Page 16] RFC 1695 ATM Management Objects August 1994 _____________________________________________________________ VP/VC |(1)cross-connect identifier | | | Cross-connect:|(2)port identifier of one | | | configuration | end | | | |(3)port identifier of the other |ATM MIB| | | end | gr. 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 | gr.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 | | | _____________________________________________________________ *The operational, administrative, and last change status of the ATM interface and the physical transmission type shall be supported by the interface table in MIB II (RFC 1213, RFC 1573). ILMI does not contain the administrative and last change status of the ATM interface. ** The ILMI MIB does not contain information on the ATM address type and the ATM administrative address assigned at the ATM interface. ***The ILMI MIB contains local and end-to-end operational status of the VPC/VCC segment. However, it does not contain the VPC/VCC administrative and last change status and the VCC AAL information. Ahmed & Tesink [Page 17] RFC 1695 ATM Management Objects August 1994 10. Definitions ATM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Counter32, Integer32, IpAddress FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString, TimeStamp, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex, mib-2 FROM RFC1213-MIB; atmMIB MODULE-IDENTITY LAST-UPDATED "9406072245Z" ORGANIZATION "IETF AToM MIB Working Group" CONTACT-INFO " Masuma Ahmed Postal: Bellcore 331 Newman Springs Road Red Bank, NJ 07701 US Tel: +1 908 758 2515 Fax: +1 908 758 4131 E-mail: mxa@mail.bellcore.com Kaj Tesink Postal: Bellcore 331 Newman Springs Road Red Bank, NJ 07701 US Tel: +1 908 758 5254 Fax: +1 908 758 4196 E-mail: kaj@cc.bellcore.com" DESCRIPTION "This is the MIB Module for ATM and AAL5-related objects for managing ATM interfaces, ATM virtual links, ATM cross-connects, AAL5 entities, and and AAL5 connections." ::= { mib-2 37 } atmMIBObjects OBJECT IDENTIFIER ::= {atmMIB 1} -- This ATM MIB Module consists of the following groups: Ahmed & Tesink [Page 18] RFC 1695 ATM Management Objects August 1994 -- (1) ATM Interface configuration group -- (2) ATM Interface DS3 PLCP group -- (3) ATM Interface TC Sublayer group -- (4) ATM Interface VPL configuration group -- (5) ATM Interface VCL configuration group -- (6) ATM VP Cross Connect group -- (7) ATM VC Cross Connect group -- (8) ATM Interface AAL5 VCC performance statistics -- group IfIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object identifies the interface for which the entry contains management information. The value of this object for a particular interface has the same value as the ifIndex object, defined in RFC 1213, for the same interface." SYNTAX Integer32 AtmTrafficDescrParamIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object identifies the row in the atmTrafficDescrParamTable." SYNTAX Integer32 atmTrafficDescriptorTypes OBJECT IDENTIFIER ::= {atmMIBObjects 1} -- The following values are defined for use as -- possible values of the ATM traffic descriptor type. -- ATM Forum specified seven types of ATM traffic -- descriptors. atmNoTrafficDescriptor OBJECT-IDENTITY STATUS current DESCRIPTION "This identifies the no ATM traffic descriptor type. Parameters 1, 2, 3, 4, and 5 are not used. This traffic descriptor type can be used for best effort traffic." ::= { atmTrafficDescriptorTypes 1} atmNoClpNoScr OBJECT-IDENTITY Ahmed & Tesink [Page 19] RFC 1695 ATM Management Objects August 1994 STATUS current DESCRIPTION "This traffic descriptor is for no CLP and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: CLP=0+1 peak cell rate in cells per second Parameter 2: not used Parameter 3: not used Parameter 4: not used Parameter 5: not used. This traffic descriptor type can be used for best effort traffic." ::= { atmTrafficDescriptorTypes 2} atmClpNoTaggingNoScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor is for no CLP without tagging and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: CLP=0+1 peak cell rate in cells per second Parameter 2: CLP=0 peak cell rate in cells per second Parameter 3: not used Parameter 4: not used Parameter 5: not used." ::= { atmTrafficDescriptorTypes 3} atmClpTaggingNoScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor is for CLP with tagging and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: CLP=0+1 peak cell rate in cells per second Parameter 2: CLP=0 peak cell rate in cells per second with excess traffic tagged as CLP=1 Parameter 3: not used Parameter 4: not used Parameter 5: not used." ::= { atmTrafficDescriptorTypes 4} atmNoClpScr OBJECT-IDENTITY STATUS current Ahmed & Tesink [Page 20] RFC 1695 ATM Management Objects August 1994 DESCRIPTION "This traffic descriptor is for no CLP with Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: CLP=0+1 peak cell rate in cells per second Parameter 2: CLP=0+1 sustained cell rate in cells per second Parameter 3: CLP=0+1 maximum burst size in cells Parameter 4: not used Parameter 5: not used." ::= { atmTrafficDescriptorTypes 5} atmClpNoTaggingScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor is for CLP with Sustained Cell Rate and no tagging. The use of the parameter vector for this type: Parameter 1: CLP=0+1 peak cell rate in cells per second Parameter 2: CLP=0 sustained cell rate in cells per second Parameter 3: CLP=0 maximum burst size in cells Parameter 4: not used Parameter 5: not used." ::= { atmTrafficDescriptorTypes 6} atmClpTaggingScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor is for CLP with tagging and Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: CLP=0+1 peak cell rate in cells per second Parameter 2: CLP=0 sustained cell rate in cells per second with excess traffic tagged as CLP=1 Parameter 3: CLP=0 maximum burst size in cells Parameter 4: not used Parameter 5: not used." ::= { atmTrafficDescriptorTypes 7} -- ATM Interface Configuration Parameters Group Ahmed & Tesink [Page 21] RFC 1695 ATM Management Objects August 1994 -- This group contains ATM specific -- configuration information associated with -- an ATM interface beyond those -- supported using the ifTable. atmInterfaceConfTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmInterfaceConfEn