Internetworking Over NBMA (ion) Working Group INTERNET DRAFT: <draft-ietf-ion-mib-00.txt> Maria Greene Expiration Date: December, 1996 Ascom Nexion Corp. James Luciani Bay Networks Kenneth White Ted T.I. Kuo IBM Corp. June 1996 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 <draft-ietf-ion-mib-00.txt> Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any Internet Draft. Distribution of this document is unlimited. Table of Contents 1.0 Introduction............................................. 2 1.1 Change Log............................................... 2 2.0 The SNMPv2 Network Management Framework.................. 3 2.1 Object Definitions....................................... 4 3.0 Overview................................................. 4 3.1 Background............................................... 4 3.2 Related MIBs............................................. 4 3.3 Structure of the MIB..................................... 5 3.3.1 AAL5 Interface Layer .................................. 5 3.3.2 ATM Logical IP Subnet (LIS) Table...................... 6 Expires December 1996 [Page 1]
Greene et al. IP over ATM MIB June 1996 3.3.3 ATM ARP Server Table................................... 8 3.3.4 ATM VC Table........................................... 8 3.3.5 ATMARP Statistics Group................................ 8 4.0 Definitions.............................................. 9 5.0 Security Considerations.................................. 22 6.0 Acknowledgments.......................................... 22 7.0 References............................................... 22 8.0 Authors' Addresses....................................... 23 1. Introduction The purpose of this memo is to define the Management Information Base (MIB) for supporting Classical IP and ARP over ATM as specified in Classical IP and ARP over ATM, refer to reference [3]. Support of an ATM interface by an IP layer will require implementation of objects from several Managed Information Bases (MIBs) as well as their enhancement in order to enable usage of ATM transports. It is the intent of this MIB to fully adhere to all prerequisite MIBs unless explicitly stated. Deviations will be documented in corresponding conformance statements. The specification of this MIB will utilize the Structure of Management Information (SMI) for Version 2 of the Simple Network Management Protocol Version (refer to RFC1902, reference [1]). 1.1. Change Log This section tracks changes made to the revisions of the Internet Drafts of this document. It will be deleted when the document is published as an RFC. May 1996 The following changes were made as the result of the LA IETF and on discussions amongst the authors: (1) Minor editorial changes. (2) Renamed "Classical IP and ARP over ATM Update (Part Deaux)" to "Classical IP and ARP over ATM". (3) Working group name changed to Internetworking Over NBMA (ion). (4) Rewrote Related MIBs section to indicate which MIBs must be conformed to. Expires December 1996 [Page 2]
Greene et al. IP over ATM MIB June 1996 (5) Old section 6 (Application of other MIBs ...) was combined with section 2.2 (Related MIBs) and moved to Overview section. (6) Trimmed Reference list. (7) Dropped IP over ATM Virtual Interface. Added ATMARP Statistics Group. Rewrote section 3.3, Structure of the MIB. February 1996 The following changes were made for the version of the document dated February 1996. These changes were made based on the output of the working group's meeting at the Dallas IETF meeting and discussions amongst the authors. (1) Rewrote document text to be consistent with MIB module definition. (2) Added ipAtmLisSubnetMask to IpAtmLisEntry. (3) Added ipAtmArpSrvrRegistrationType to IpAtmArpSrvrEntry. 2. The SNMPv2 Network Management Framework The SNMP Network Management Framework consists of the following components: o RFC 1902 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o RFC 1903 which defines the Textual Conventions. o RFC 1904 which defines Conformance. o RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1157 and RFC 1905 which define two versions of the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Expires December 1996 [Page 3]
Greene et al. IP over ATM MIB June 1996 2.1. 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 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 often use a textual string, termed the descriptor, to refer to the object type. 3. Overview 3.1. Background This document is a product of the Internetworking Over NBMA Working Group. Its purpose is to define a MIB module for extending MIB II object definitions to support Classical IP and ARP over ATM. 3.2. Related MIBs MIB related RFCs and Internet Drafts that have been considered in the development of this document are: o MIB II - Specification prior to development of the SNMPv2 framework. The various portions of MIB II as defined by RFC 1213 is being separated into separate MIBs and defined by new RFCs. RFC 1213's Interface specification has been enhanced (refer to RFC 1573 [2] and its update the ifMib [4]) by the Interface work group. Conformance to this set of MIBs is required in order to support the IP-ATM MIB. In particular, the interface group as defined by the ifMib will be used instead of the RFC 1213 definition. The ifMib provides several very useful enhancements over the interface group defined by RFC 1213 that are necessary in proper support of ATM Ports. The ifMib must be conformed to. o RFC 1695 - Definitions of Managed Objects for ATM Management [6]. Support of this MIB is required for implementing the layers between AAL5 and ATM. The Expires December 1996 [Page 4]
Greene et al. IP over ATM MIB June 1996 contents of this MIB will not explicitly be address here, since the IP-ATM MIB will focus on MIB modeling above the AAL5 layer. o Internet Draft from AToMMIB working group on the Definitions of Supplemental Managed Objects for ATM Management [5] - "This memo defines an experimental 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 in addition to those defined in the ATM MIB [6], to provide additional support for the management of: - ATM Switched Virtual Connections (SVCs) - ATM Permanent Virtual Connections (PVCs)" o ATM Forum UNI ILMI MIB - The ILMI MIB is specified by the ATM Forum in various versions of the UNI specification. The ILMI MIBs being defined are not supported via SNMP agents but via SNMP requests sent over an ATM network to an ATM entity encapsulated in an AAL5 header. Support of the ILMI MIB(s) is out of the scope of this document. 3.3. Structure of the MIB The Classical ARP and IP over ATM MIB structure is composed of the following: o AAL5 Interface Layer o ATM Logic IP Subnet (LIS) Table o ATM ARP Server Table o ATM VC Table o ATMARP Statics Group 3.3.1. AAL5 Interface Layer Implementation of the Definitions of Managed Objects for ATM Management [5] defines the modeling of the various layers within an ATM Port. This modeling is assumed as a prerequisite for the IP-ATM MIB. The IP-ATM MIB assumes the existence of an AAL5 interface and its associating ifIndex for attaching an ATM Port to IP in order to support IP and ARP over ATM. Refer to the Definitions of Managed Objects for ATM Management for the definition of an ATM Port's interface layering. Expires December 1996 [Page 5]
Greene et al. IP over ATM MIB June 1996 The AAL5 layer's ifIndex is used to map a logical subnet entity to a particular ATM transport. This ifIndex is stored in an ipAddrTable entry, either an ipRouteTable entry (RFC 1213) or ipForwardtable entry (ipForwarding Mib), and in an ipAtmLisTable entry. Use of both the ipAddrTable and the IP-ATM MIB defined ipAtmLisTable is the topic of the next section. The use of an IP over ATM Virtual Interface layer has been dropped from the IP-ATM MIB. It was decided that use of a virtual layer above AAL5 was not absolutely necessary for modeling the attachment of IP to an ATM network. Instead of an ATM Virtual Interface the IP-ATM MIB uses the ifIndex of an AAL5 Interface. An AAL5 Interface was stacked below the IP over ATM Virtual Interface in an older version of this document. It has been left up to the implementors of this MIB to determine their own interface layering above AAL5 (assuming compliance with the ifMib). The IANA ifType propVirtual was created for this purpose. 3.3.2. ATM Logical IP Subnet (LIS) Table The ATM Logical IP Subnet (LIS) Table defines the subnets that this system is a member of for purposes of reaching destinations over a ATM transport. The LIS table is indexed by subnet address (ipAtmNetAddr) and not ifIndex. Every entry in the LIS table must have a corresponding ipAddrTable entry where both are indexed by the same entity (ipAdEntAddr for ipAddrTable and ipAtmNetAddr for ipAtmLisTable). Refer to the following diagram that illustrates the relationship between ipAtmLisTable and ipAddrTable objects: ipAtmLisEntry ipAddrTable ----------------------------- ------------------------ | ipAtmLisNetAddr | | ipAdEntAddr | | ipAtmLisNetMask | | ipAdEntNetMask | | ipAtmLisAtmAddr | | | | ipAtmLisIfIndex | | ipAdEntIfIndex | | ipAtmLisIsSrvr | | | | ipAtmLisDefaultMtu | | | | ipAtmLisDefaultEncapsType | | | | ipAtmLisRowStatus | | | | | | ipAdEntBcastAddr | | | | ipAdEntReasmMaxSize | ----------------------------- ------------------------ ipAtmLisRowStatus object enables entries in the ipAtmLisTable to be created. Creation of an ipAtmLisTable entry results in the adding of a corresponding ipAddrTable entry. When ipAtmLisRowStatus is changed Expires December 1996 [Page 6]
Greene et al. IP over ATM MIB June 1996 from 'active(1)' to has the side-effect of removing all entries from the ipNetToMediaTable that are associated with this LIS (in other words, it flushes the entity's ATMARP cache). It also removes the ipAtmVcTable entries that were associated with those ipNetToMediaTable entries. However, entries in the ipAtmArpSrvrTable and ipAtmArpStatsTable associated with the LIS are only removed when the ipAtmLisRowStatus is set to 'destroy(6)' and not when it is set to 'notInService(2)'. The attachment point for IP into an ATM network is via an AAL5 Interface's ifIndex. This ifIndex is part of an ipAtmLisTable entry and must be the same in the corresponding ipAddrTable entry. ipAtmLisNetAddr is the IP address associated with this LIS. ipAtmLisNetMask is the corresponding subnet mask. It is sometimes possible for a system to have multiple IP addresses configured within the same IP subnet. The indexing of this table would seem to preclude that, however, it is possible to have additional entries in the ipAddrTable associated with the LIS' ifIndex with the same subnet address. The mechanism for adding these entries to the ipAddrTable (which is read-only) is beyond the scope of this MIB module. It is also sometimes possible for a system, most commonly a switch, to have multiple LISes associated with the same aal5 interface. In this situation, the performance and error counters kept at the aal5 interface, such as ifInOctets and ifInErrors, will be the aggregate of those associated with the subnets that use the aal5 interface. Therefore, an agent may optionally represent the 'virtual IP interface' associated with the subnet in the ifTable and use the ifStackTable to show that it is stacked above the lower layer aal5 interface. This allows the agent to keep per-subnet statistics. It is recommended that the ifType of this virtual IP interface be propVirtual(53). It should be noted that this situation is no different than having multiple IP subnets associated with the same LAN interface, PPP interface, or other 'lower layer' interface type." The ipAddrTable's ipAdEntReasmMaxSize is the "The size of the largest IP datagram which this entity can re-assemble from incoming IP fragmented datagrams received on this interface" and if different from the ipAtmLisTable's ipAtmLisDefaultMtu with is the default MTU used within the LIS represented by this entry. Note that this is the default MTU not the actually which is represented as ipAtmVcNegotiatedMtu in the atmVcTable. Expires December 1996 [Page 7]
Greene et al. IP over ATM MIB June 1996 3.3.3. ARP Server Table This table defines list of ATMARP servers within the LIS. Each entry of the table defines each ATMARP server's ATM address, status, e.g., up/down, of each server. According to [3], minimum number of entries in this table is three. An entry in this table provides information about an ATMARP server within a LIS and is indexed by ipAdEntAddr (same as ipAtmNetAddr) and the ipAtmArpSrvrAddr (ATM address of the ATMARP server). Entries may be created by a management application using the ipAtmArpSrvrRowStatus object. In an SVC environment, the ipAtmArpSrvrAddr must be specified before the entry's ipAtmArpSrvrRowStatus can be set to 'active(1)'. In a PVC environment, the ipAtmArpSrvrVpi and ipAtmArpSrvrVci values must also be specified; these values are the VPI/VCI of a PVC that was established using some mechanism outside the scope of this MIB module (generally RFC1695, the AToM MIB). Entries in this table may also be created by the system and not by a management application, for example as a result of ILMI. Entries in this table may be deleted by setting the ipAtmArpSrvrRowStatus object to 'destroy(6)'. This includes entries that were added by the system and not by a management application. If an entry with the same IP address and ATM address as one of this system's ipAtmLisTable entries is created or deleted, then the value of ipAtmLisIsSrvr will be changed by the agent as appropriate. Note that changing the role of entity between host and server will have the side effect of flushing the ATMARP cache and VC tables as described in the ipAtmLisRowStatus DESCRIPTION." 3.3.4. ATM VC Table The ATM VC Table essentially enhances the ipNetToMediaTable to facilitate ATM address resolution. More will be provided at the next update of this document. 3.3.5. ATMARP Statistics Group The ATMARP Statistics Group defines a series of objects for tracking the activity of an ATMARP server and is indexed by the same as the ATMARP Server table. Expires December 1996 [Page 8]
Greene et al. IP over ATM MIB June 1996 4. Definitions IP-ATM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, experimental, Integer32, IpAddress, Counter32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF AtmAddr, AtmConnKind FROM ATM-TC-MIB ipNetToMediaIfIndex, ipNetToMediaNetAddress, ipNetToMediaPhysAddress, ipAdEntAddr FROM RFC1213-MIB InterfaceIndex FROM IF-MIB ; ipAtmMIB MODULE-IDENTITY LAST-UPDATED "9603271200Z" -- March 27, 1996 ORGANIZATION "IETF IP over ATM Working Group" CONTACT-INFO "Maria Greene (greene@nexen.com) Ascom Nexion Jim Luciani (jluciani@lobster.BayNetworks.com) Bay Networks Kenneth White (kennethw@vnet.ibm.com) Ted Kuo (tkuo@raleigh.ibm.com) IBM Corp. " DESCRIPTION "This module defines a portion of the management information base (MIB) for managing Classical IP and ARP over ATM entities. It is meant to be used in connection with the ATM-MIB, MIB-II, and optionally the IF-MIB." -- This needs to be replaced with an actual value ::= { experimental 2001 } IpAtmEncapsType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The encapsulation type used on a VC." Expires December 1996 [Page 9]
Greene et al. IP over ATM MIB June 1996 SYNTAX INTEGER { llcSnap(1), vcMuxed(2), other(3) } IpAtmVpiInteger ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An integer large enough to hold a VPI." SYNTAX Integer32 (0..255) IpAtmVciInteger ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An integer large enough to hold a VCI." SYNTAX Integer32 (0..65535) -- -- MIB Objects -- ipAtmObjects OBJECT IDENTIFIER ::= { ipAtmMIB 1 } -- -- The Logical IP Subnet Table -- ipAtmLisTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAtmLisEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "There is one entry in this table for every Logical IP Subnet (LIS) that this system is a member of." ::= { ipAtmObjects 1 } ipAtmLisEntry OBJECT-TYPE SYNTAX IpAtmLisEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about an LIS that this system is a member of either as a client, a server, or both. This table is indexed an IP address. If the host part of this IP address is not all zeroes, then this system is being configured as a client on this LIS and a corresponding entry should be added to the ipAddrTable from RFC1213, 'Management Information Base for Network Management of TCP/IP-based internets: MIB-II'. Expires December 1996 [Page 10]
Greene et al. IP over ATM MIB June 1996 Values for the objects ipAtmLisNetMask, ipAtmLisAtmAddr, and ipAtmLisIfIndex are required in order to set the entry's ifAtmLisRowStatus object to 'active(1)'. The values for these and the ipAtmLisDefaultMtu and ipAtmLisDefaultEncapsType objects can only be changed when ifAtmLisRowStatus is not 'active(1)'. A system is 'attached' to an LIS through one of its entries in the ifTable (defined in RFC1573, 'Evolution of the Interfaces Group of MIB-II'). This attachment is identified by the ipAtmLisIfIndex object. In general, this will by an interface with an ifType of aal5(49). See RFC1695, 'Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2', for information about this interface type and its required stacking relationships with other interfaces. It is sometimes possible for a system to have multiple IP addresses configured within the same IP subnet. The indexing of this table would seem to preclude that, however, it is possible to have additional entries in the ipAddrTable associated with the LIS' ifIndex with the same subnet address. The mechanism for adding these entries to the ipAddrTable (which is read-only) is beyond the scope of this MIB module. It is also sometimes possible for a system, most commonly a switch, to have multiple LISes associated with the same aal5 interface. In this situation, the performance and error counters kept at the aal5 interface, such as ifInOctets and ifInErrors, will be the aggregate of those associated with the subnets that use the aal5 interface. Therefore, an agent may optionally represent the 'virtual IP interface' associated with the subnet in the ifTable and use the ifStackTable to show that it is stacked above the lower layer aal5 interface. This allows the agent to keep per-subnet statistics. It is recommended that the ifType of this virtual IP interface be propVirtual(53). It should be noted that this situation is no different than having multiple IP subnets associated with the same LAN interface, PPP interface, or other 'lower layer' interface type." INDEX { ipAtmLisNetAddr } ::= { ipAtmLisTable 1 } IpAtmLisEntry ::= SEQUENCE { ipAtmLisNetAddr IpAddress, ipAtmLisNetMask IpAddress, ipAtmLisAtmAddr AtmAddr, ipAtmLisIfIndex InterfaceIndex, Expires December 1996 [Page 11]
Greene et al. IP over ATM MIB June 1996 ipAtmLisIsSrvr TruthValue, ipAtmLisDefaultMtu Integer32, ipAtmLisDefaultEncapsType IpAtmEncapsType, ipAtmLisRowStatus RowStatus } ipAtmLisNetAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address associated with this LIS. If the host part of the IP address is valid (not all zeroes), then this system is a client for the LIS." ::= { ipAtmLisEntry 1 } ipAtmLisNetMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object is the subnet mask for the LIS. It be used to initialize the value of ipAdEntNetMask for the ipAddrEntry created for this LIS if it is a client." ::= { ipAtmLisEntry 2 } ipAtmLisAtmAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-create STATUS current DESCRIPTION "This object is ATM address that this system has as a member of the LIS. This will be used as the ifPhysAddress of the interface associated with this LIS." ::= { ipAtmLisEntry 3 } ipAtmLisIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "This object is the ifIndex value of the interface that is associated with this LIS. This will be used as the value of ipAdEntIfIndex for the ipAddrEntry created for this LIS." ::= { ipAtmLisEntry 4 } ipAtmLisIsSrvr OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only Expires December 1996 [Page 12]
Greene et al. IP over ATM MIB June 1996 STATUS current DESCRIPTION "This object indicates whether this system is the ATMARP server for this LIS. The value true(1) indicates it is a server, the value false(2) indicates it is just a client." DEFVAL { false } ::= { ipAtmLisEntry 5 } ipAtmLisDefaultMtu OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The default MTU used within this LIS. Note that the actual size used for a VC between two members of the LIS may be negotiated during connection setup and may be different than this value. The ipAtmVcNegotiatedMtu object indicates the actual MTU in use for a particular VC." DEFVAL { 9180 } ::= { ipAtmLisEntry 6 } ipAtmLisDefaultEncapsType OBJECT-TYPE SYNTAX IpAtmEncapsType MAX-ACCESS read-create STATUS current DESCRIPTION "The default encapsulation to use on VCs created for this LIS. Note that the actual encapsulation type may be negotiated during connection setup and may be different than this value. The ipAtmVcNegotiatedEncapsType object indicates the actual encapsulation in use for a particular VC." DEFVAL { llcSnap } ::= { ipAtmLisEntry 7 } ipAtmLisRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the ipAtmLisTable. When the ipAtmLisRowStatus is changed from 'active(1)' to 'notInService(2)' or from 'active(1)' to 'destroy(6)', this has the side-effect of removing all entries from the ipNetToMediaTable that are associated with this LIS (in other words, it flushes the entity's ATMARP cache). It also removes the ipAtmVcTable entries that were associated with those Expires December 1996 [Page 13]
Greene et al. IP over ATM MIB June 1996 ipNetToMediaTable entries. However, entries in the ipAtmArpSrvrTable and ipAtmArpStatsTable associated with the LIS are only removed when the ipAtmLisRowStatus is set to 'destroy(6)' and not when it is set to 'notInService(2)'." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipAtmLisEntry 8 } -- -- The ATMARP Server Table -- ipAtmArpSrvrTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAtmArpSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATMARP servers for an LIS. In an SVC environment, the agent must support at least three of these." ::= { ipAtmObjects 2 } ipAtmArpSrvrEntry OBJECT-TYPE SYNTAX IpAtmArpSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about an ATMARP server within an LIS. An entry in this table has two indexes: first the ipAdEntAddr, which is the IP address that this system uses as a member of the LIS, and then the ipAtmArpSrvrAddr, which is the ATM address of the ATMARP server. Entries may be created by a management application using the ipAtmArpSrvrRowStatus object. In an SVC environment, the ipAtmArpSrvrAddr must be specified before the entry's ipAtmArpSrvrRowStatus can be set to 'active(1)'. In a PVC environment, the ipAtmArpSrvrVpi and ipAtmArpSrvrVci values must also be specified; these values are the VPI/VCI of a PVC that was established using some mechanism outside the scope of this MIB module (generally RFC1695, the AToM MIB). Entries in this table may also be created by the system and not by a management application, for example as a result of ILMI. Entries in this table may be deleted by setting the ipAtmArpSrvrRowStatus object to 'destroy(6)'. This includes entries that were added by the system and not by a management application. If an entry with the same IP address and ATM address as one of Expires December 1996 [Page 14]
Greene et al. IP over ATM MIB June 1996 this system's ipAtmLisTable entries is created or deleted, then the value of ipAtmLisIsSrvr will be changed by the agent as appropriate. Note that changing the role of entity between host and server will have the side effect of flushing the ATMARP cache and VC tables as described in the ipAtmLisRowStatus DESCRIPTION." INDEX { ipAdEntAddr, ipAtmArpSrvrAddr } ::= { ipAtmArpSrvrTable 1 } IpAtmArpSrvrEntry ::= SEQUENCE { ipAtmArpSrvrAddr AtmAddr, ipAtmArpSrvrVpi IpAtmVpiInteger, ipAtmArpSrvrVci IpAtmVciInteger, ipAtmArpSrvrRowStatus RowStatus } ipAtmArpSrvrAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM address of the ATMARP server." ::= { ipAtmArpSrvrEntry 1 } ipAtmArpSrvrVpi OBJECT-TYPE SYNTAX IpAtmVpiInteger MAX-ACCESS read-create STATUS current DESCRIPTION "The VPI of the VC between this system and the ATMARP server. In an SVC environment, this object may be implemented as read-only by the agent." ::= { ipAtmArpSrvrEntry 2 } ipAtmArpSrvrVci OBJECT-TYPE SYNTAX IpAtmVciInteger MAX-ACCESS read-create STATUS current DESCRIPTION "The VCI of the VC between this system and the ATMARP server. In an SVC environment, this object may be implemented as read-only by the agent." ::= { ipAtmArpSrvrEntry 3 } ipAtmArpSrvrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current Expires December 1996 [Page 15]
Greene et al. IP over ATM MIB June 1996 DESCRIPTION "This object allows entries to be created and deleted from the ipAtmArpSrvrTable." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipAtmArpSrvrEntry 4 } -- -- The VC Table -- ipAtmVcTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAtmVcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A system that support IP over ATM is an IP system and therefore must support all of the appropriate tables from RFC1213, MIB-II. This includes the ipNetToMediaTable (the ARP cache). This ipAtmVcTable keeps a set of VCs for each entry in the ARP cache that was put there by this IP over ATM system acting as either a host or server." ::= { ipAtmObjects 3 } ipAtmVcEntry OBJECT-TYPE SYNTAX IpAtmVcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A VC (permanent or switched) that this host or server has opened with another member of an LIS. Additional information can be determined about the VC from RFC1695, the AToM MIB. In an SVC environment, entries can usually not be created in this table by a management application, therefore the agent treats the ipAtmVcRowStatus object as not-accessible. In a PVC environment, the ipAtmVcVpi and ipAtmVcVci objects must be specified before the ipAtmVcRowStatus object can be set to 'active(1)'. The VPI/VCI values must correspond to those of a PVC established on the same interface indicated by the ipNetToMediaIfIndex using a mechanism outside the scope of this MIB (generally using RFC1695, the AToM MIB)." INDEX { ipNetToMediaIfIndex, ipNetToMediaNetAddress, ipAtmVcVpi, ipAtmVcVci } ::= { ipAtmVcTable 1 } Expires December 1996 [Page 16]
Greene et al. IP over ATM MIB June 1996 IpAtmVcEntry ::= SEQUENCE { ipAtmVcVpi IpAtmVpiInteger, ipAtmVcVci IpAtmVciInteger, ipAtmVcType AtmConnKind, ipAtmVcNegotiatedMtu Integer32, ipAtmVcNegotiatedEncapsType IpAtmEncapsType, ipAtmVcRowStatus RowStatus } ipAtmVcVpi OBJECT-TYPE SYNTAX IpAtmVpiInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value for the Virtual Circuit." ::= { ipAtmVcEntry 1 } ipAtmVcVci OBJECT-TYPE SYNTAX IpAtmVciInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value for the Virtual Circuit." ::= { ipAtmVcEntry 2 } ipAtmVcType OBJECT-TYPE SYNTAX AtmConnKind MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the Virtual Circuit." ::= { ipAtmVcEntry 3 } ipAtmVcNegotiatedEncapsType OBJECT-TYPE SYNTAX IpAtmEncapsType MAX-ACCESS read-create STATUS current DESCRIPTION "The encapsulation type used when communicating over this circuit." ::= { ipAtmVcEntry 4 } ipAtmVcNegotiatedMtu OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The MTU used when communicating over this circuit." ::= { ipAtmVcEntry 5 } Expires December 1996 [Page 17]
Greene et al. IP over ATM MIB June 1996 ipAtmVcRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This objects allows rows to be created and deleted in the ipAtmVcTable." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipAtmVcEntry 6 } -- -- ATMARP Statistics Table -- ipAtmArpStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAtmArpStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of statistics, one entry for each ATMARP server." ::= { ipAtmObjects 4 } ipAtmArpStatsEntry OBJECT-TYPE SYNTAX IpAtmArpStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics for a particular ATMARP server." INDEX { ipAdEntAddr, ipAtmArpSrvrAddr } ::= { ipAtmArpStatsTable 1 } IpAtmArpStatsEntry ::= SEQUENCE { ipAtmArpUnreachable Counter32, ipAtmArpNacks Counter32, ipAtmArpReqsIn Counter32, ipAtmArpReqsOut Counter32, ipAtmArpRepliesIn Counter32, ipAtmArpRepliesOut Counter32 } ipAtmArpUnreachable OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this ATMARP server did not reply to a message." ::= { ipAtmArpStatsEntry 1 } Expires December 1996 [Page 18]
Greene et al. IP over ATM MIB June 1996 ipAtmArpNacks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ATMARP_NAK messages received from this ATMARP server." ::= { ipAtmArpStatsEntry 2 } ipAtmArpReqsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of requests received by this ATMARP server." ::= { ipAtmArpStatsEntry 3 } ipAtmArpReqsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of requests sent to this ATMARP server." ::= { ipAtmArpStatsEntry 4 } ipAtmArpRepliesIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of replies received by this ATMARP server." ::= { ipAtmArpStatsEntry 5 } ipAtmArpRepliesOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of replies sent by this ATMARP server." ::= { ipAtmArpStatsEntry 6 } -- -- Notifications -- ipAtmNotifications OBJECT IDENTIFIER ::= { ipAtmMIB 2 } ipAtmMtuExceeded NOTIFICATION-TYPE OBJECTS { ipNetToMediaIfIndex, Expires December 1996 [Page 19]
Greene et al. IP over ATM MIB June 1996 ipNetToMediaNetAddress, ipAtmVcVpi, ipAtmVcVci } STATUS current DESCRIPTION "A frame was received that exceeds the negotiated MTU size." ::= { ipAtmNotifications 1 } ipAtmDuplicateIpAddress NOTIFICATION-TYPE OBJECTS { ipNetToMediaIfIndex, ipNetToMediaNetAddress, ipNetToMediaPhysAddress, ipNetToMediaPhysAddress } STATUS current DESCRIPTION "The ATMARP server has detected more than one ATM end point attempting to associate the same IP address with different ATM hardware addresses." ::= { ipAtmNotifications 2 } -- -- Conformance Definitions -- ipAtmConformance OBJECT IDENTIFIER ::= { ipAtmMIB 3 } ipAtmGroups OBJECT IDENTIFIER ::= { ipAtmConformance 1 } ipAtmCompliances OBJECT IDENTIFIER ::= { ipAtmConformance 2 } ipAtmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that support the IP-ATM MIB." MODULE -- this module MANDATORY-GROUPS { ipAtmGeneralGroup } OBJECT ipAtmLisDefaultMtu MIN-ACCESS read-only DESCRIPTION "The agent is not required to allow the user to change the default MTU from the value 9180." OBJECT ipAtmLisDefaultEncapsType MIN-ACCESS read-only DESCRIPTION "The agent is not required to allow the user to Expires December 1996 [Page 20]
Greene et al. IP over ATM MIB June 1996 specify the default encapsulation type for the LIS." OBJECT ipAtmArpSrvrVpi MIN-ACCESS read-only DESCRIPTION "Implementations that do not support IP over ATM over PVCs are not required to allow the user to specify the VPI of the connection to the ATMARP server." OBJECT ipAtmArpSrvrVci MIN-ACCESS read-only DESCRIPTION "Implementations that do not support IP over ATM over PVCs are not required to allow the user to specify the VCI of the connection to the ATMARP server." OBJECT ipAtmVcRowStatus MIN-ACCESS read-only DESCRIPTION "Implementations that do not support IP over ATM over PVCs are not required to allow entries in the ipAtmVcTable to be created by the user." GROUP ipAtmStatsGroup DESCRIPTION "Implementation of this group is optional for all systems that support ATMARP." ::= { ipAtmCompliances 1 } ipAtmGeneralGroup OBJECT-GROUP OBJECTS { ipAtmLisNetMask, ipAtmLisAtmAddr, ipAtmLisIfIndex, ipAtmLisIsSrvr, ipAtmLisDefaultMtu, ipAtmLisDefaultEncapsType, ipAtmLisRowStatus, ipAtmArpSrvrVpi, ipAtmArpSrvrVci, ipAtmArpSrvrRowStatus, ipAtmVcNegotiatedEncapsType, ipAtmVcNegotiatedMtu, ipAtmVcRowStatus } STATUS current DESCRIPTION "The required objects." Expires December 1996 [Page 21]
Greene et al. IP over ATM MIB June 1996 ::= { ipAtmGroups 1 } ipAtmStatsGroup OBJECT-GROUP OBJECTS { ipAtmArpUnreachable, ipAtmArpNacks, ipAtmArpReqsIn, ipAtmArpReqsOut, ipAtmArpRepliesIn, ipAtmArpRepliesOut } STATUS current DESCRIPTION "A collection of objects that are statistics maintained about the use of ATMARP." ::= { ipAtmGroups 2 } END 5. Security Considerations Security issues are not discussed in this memo. 6. Acknowledgments This document is a product of the Internetworking Over NBMA Working Group. The authors of this document would like to recognize Keith McCloghrie from Cisco Systems for his support as our mentor from the Network Management Area. 7. References [1] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] K. McCloghrie and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, January 1994. [3] M. Laubach, "Classical IP and ARP over ATM", August 31, 1995. Refer to <draft-ietf-ipatm-classic2-01.txt> for the latest draft of this Expires December 1996 [Page 22]
Greene et al. IP over ATM MIB June 1996 document. [4] ifMib Working Group, Keith McCloghrie, and Frank Kastenholz, "The Interfaces Group MIB", <draft-ietf-ifmib-mib-03.txt>, February 1996 [5] AToMMIB Working Group, Faye Ly, Michael Noto, Andrew Smith, Kaj Tesink, "Definitions of Supplemental Managed Objects for ATM Management", <draft-ietf-atommib-atm2-05.txt>, February 1996 [6] Ahmed, M., Tesink, K., "Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2", RFC 1695, Bell Communications Research, August 1994. 8. Authors' Addresses Maria N. Greene Ascom Nexion 289 Great Rd Acton, MA 01720, USA Phone: +1-508-266-4570 E-mail: greene@nexen.com James Luciani Bay Networks, Inc. 3 Federal St., BL3-04 Billerica, MA 01821, USA Phone: +1-508-439-4734 E-mail: luciani@baynetworks.com Kenneth D. White Dept. G80/Bldg 503 IBM Corporation Research Triangle Park, NC 27709, USA Phone: +1-919-254-0102 E-mail: kennethw@vnet.ibm.com Ted T.I. Kuo Dept. JDG/Bldg 503 IBM Corporation Research Triangle Park, NC 27709, USA Phone: +1-919-254-6214 E-mail: tkuo@raleigh.ibm.com Expires December 1996 [Page 23]
