Internetworking Over NBMA (ion) Working Group INTERNET DRAFT: Maria Greene Expiration Date: November, 1997 Independent Contractor James Luciani Bay Networks Kenneth White Ted T.I. Kuo IBM Corp. May 1997 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 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. Abstract 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 Expires November 1997 [Page 1]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 Structure of Management Information (SMI) for Version 2 of the Simple Network Management Protocol Version (refer to RFC1902, reference [1]). Table of Contents 1.0 Introduction............................................. 2 2.0 The SNMPv2 Network Management Framework.................. 3 2.1 Object Definitions....................................... 4 3.0 Structure of the MIB..................................... 4 3.1 Basic Support MIB Definitions............................ 5 3.1.1 ATM Logical IP Subnet (LIS) Table...................... 5 3.1.2 ATM Logical IP IF Mapping Table........................ 6 3.1.3 ATMARP Remote Server Table............................. 6 3.1.4 ATM VC Table........................................... 7 3.1.5 ATM Config PVC Table................................... 8 3.1.6 Notifications.......................................... 9 . 3.2 Client Supported MIB Definitions......................... 9 3.2.1 ATMARP Client Table.................................... 9 3.3 Server Supported MIB Definitions......................... 10 3.3.1 ATMARP Server Table.................................... 11 3.3.2 Notifications.......................................... 11 4.0 Definitions.............................................. 12 5.0 Security Considerations.................................. 37 6.0 Acknowledgments.......................................... 37 7.0 References............................................... 39 8.0 Authors' Addresses....................................... 40 1. Introduction This document is a product of the Internetworking Over NBMA Working Group. Its purpose is to define a MIB module for extending the traditional MIBs supported by a TCP/IP implementation to support Classical IP and ARP over ATM. Many MIB related RFCs and Internet Drafts have been considered in the development of this document. The ones that are considered central to the extensions defined by this document are: o RFC 2011 - SNMPv2 Management Information Base for the Internet Protocol using SMIv2 [10]. The IP over ATM (IPOA) MIB provides extensions to the IP Group for handling IP over ATM flows. A basic understanding of the IP Group is essential for understanding this document. Expires November 1997 [Page 2]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 o RFC 1573 - Interfaces Group Evolution [2]. This document is important since it provides several very useful enhancements over the interface group defined in RFC 1213 that aid in handling ATM related interfaces. o RFC 1695 - Definitions of Managed Objects for ATM Management [4]. Support of this MIB is required for implementing the layers between AAL5 and ATM. The contents of this MIB will not explicitly be address here. RFC 1695 provides a basis for managing ATM interface layering and management of: - ATM Switched Virtual Connections (SVCs) - ATM Permanent Virtual Connections (PVCs) The ATM Forum UNI 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 considered out of the scope of this document. 2. The SNMPv2 Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1], - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [5], - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [9] and/or RFC 1905 [7] - the protocol for accessing managed information. Textual conventions are defined in RFC 1903 [6], and conformance statements are defined in RFC 1904 [8]. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A semantically identical MIB conforming to the SNMPv1 SMI can be produced through the appropriate translation. Expires November 1997 [Page 3]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 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. Structure of the MIB The Classical ARP and IP over ATM (IPOA) MIB structure is split into three components: o Basic Support MIB Definitions o Client Supported MIB Definitions o ATMARP Server MIB Definitions All IP and ARP over ATM entities, both clients and ATMARP servers, are required to support the MIB definitions in the Basic Support MIB Definitions section. Clients need to additionally support the MIB definitions outlined in the Client specific section and ATMARP Servers must additionally support the ATMARP Server specific MIB definitions. Implementation of the Definitions of Managed Objects for ATM Management [4] defines the modeling of the various layers within an ATM Interface. This modeling is assumed as a prerequisite for the IPOA MIB. The IPOA MIB makes no assumptions on how this layering is actually implemented within a system. Several of the MIB tables defined by the IPOA MIB, like the base TCP/IP MIBs, requires that an ifIndex exist that points to an ATM Interface. Refer to the Definitions of Managed Objects for ATM Management (RFC 1695) for the definition of an ATM Interface interface layering. The use of an IP over ATM Virtual Interface layer is not explicitly required by the IPOA MIB. The use of virtual layers above an RFC1695 defined interface layer is not absolutely necessary for modeling the attachment of IP to an ATM network. The IPOA MIB uses a generic ifIndex that must related to some ATM related Interface in its MIB definitions. It up to the implementers of this MIB to determine their own ATM interface layering (assuming compliance with RFC 1573 and RFC 1695). The IANA ifType ipOverAtm(114) was created for use by systems that require a virtual IP interface layer. RFC 1573's ifStackTable Expires November 1997 [Page 4]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 should be used to show the relationship between virtual IP over ATM interfaces and the actually ATM Physical interface layers. 3.1. Basic Support MIB Definitions Basic support that must be implemented by both Clients and ATMARP Servers consist of: o ATM Logical IP Subnet (LIS) Table o ATM Logical IP IF Mapping Table o ATMARP Remote Server Table o ATM VC Table o ATM Config PVC Table o Notifications 3.1.1. 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 the subnet address (ipoaLisSubnetAddr) and not ifIndex. The ipoaLisIfMappingTable described in the next section provides the mapping between Logical IP Subnets and the interface layer. It is possible that the same LIS can be reached via different ATM physical interfaces. The ipAddrTable and the ipoaClientTable provides the mapping from a local IP address to a ATM physical interface. One or more ipAddrTable entries can point to the same ipoaLisEntry. An ipAddrEntry's ipAdEntAddr ANDed with its ipAdEntNetMask should equal an ipoaLisEntry's ipoaLisSubnetAddr. Given that a interface can be multi-homed each local IP address associated with an interface requires an entry in the ipAddrTable. Each ipAddrTable entry for a local IP address associated with a ATM physical interface should map to an entry in the ipoaLisTable. The bulk of the objects in a ipoaLisEntry exists to control ATMARP for a particular LIS: ipoaLisInactivityTimer ipoaLisMinHoldingTime ipoaLisQDepth ipoaLisMaxCalls ipoaLisCacheEntryAge ipoaLisRetries ipoaLisTimeout Expires November 1997 [Page 5]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 An ipoaLisMaxCalls defines the maximum number of VCs that can be established simultaneously per LIS. An ipoaLisDefaultPeakCellRate defines the best effort default peak cell rate in both the forward and backwards direction when establishing a VCCs. 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 is different from the ipoaLisTable's ipoaLisDefaultMtu with is the default MTU used within an LIS. Note that this is the default MTU used within the LIS represented by this entry. Note that this is the default MTU not the actual which is represented as ipoaVcNegotiatedMtu in the ipoaVcTable. The ipoaLisRowStatus object enables entries in the ipoaLisTable to be created or deleted via SNMP. Creation of an ipoaLisTable entry results in the adding of a corresponding ipAddrTable entry and a ipoaLisIfMappingTable entry. Creation of multiple ipAddrTable entries and ipoaLisIfMappingTable entries for the same LIS is not addressed by this document. When ipoaLisRowStatus 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 ipoaVcTable entries that were associated with those ipNetToMediaTable entries. Destroying the row removes the corresponding entries in the ipoaArpSrvrTable, ipoaArpClientTable, ipoaLisIfMappingTable and the ipoaArpRemoteSrvrTable. Entries in both the ipNetToMediaTable and the ipoaVcTable that are associated with a ipoaConfigPvcEntry are not effected by changes to ipoaLisRowStatus. 3.1.2. ATM Logical IP IF Mapping Table The ipoaLisIfMappingTable maps a LIS to all ATM physical interfaces that it is configured to be supported from. Each entry in the ipoaLisIfMappingTable should map to a ipAddrTable entry. It is also possible for a system, most commonly a switch, to have multiple LISes associated with the same ATM physical interface. 3.1.3. ATMARP Remote Server Table Entries in the ipoaArpRemoteSrvrTable exists to locally configure the remote ATMARP Servers that exist on a per LIS and interface basis. Classic2 requires that at least one ATMARP server be configured per LIS where SVC traffic is intended. PVC usage doesn't require use of Expires November 1997 [Page 6]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ATMARP. No ipoaArpRemoteSrvrTable entries should be configured for a LIS where only PVCs will be used. An entry in the ipoaArpRemoteSrvrTable is indexed by the subnet address of the LIS (ipoaLisSubnetAddr) the ATM address of the remote ATMARP server (ipoaArpRemoteSrvrAtmAddr) and a interface ifIndex (ipoaArpRemoteSrvrIfIndex). The object ipoaArpRemoteSrvrIpAddr in a ipoaArpRemoteSrvrEntry is set with the IP Address of the Remote ATMARP Server when a VC to the Remote ATMARP Server is established. A value of 0 should be used when the IP address of the Remote ATMARP Server is not known. Once ipoaArpRemoteSrvrIpAddr is set then the ipoaVcTable can be searched using ipoaArpRemoteSrvrIfIndex and ipoaArpRemoteSrvrIpAddr to find the VC in use to the Remote ATMARP Server. ipoaArpRemoteSrvrIfIndex is defined to have the textual convention of InterfaceIndexOrZero. Adding ipoaArpRemoteSrvrIfIndex to the index clause allows a system to have a VC to a ATMARP Remote server on a per LIS and interface basis. An entry in this table should exist for each interface on a per LIS basis. Each interface would then have a separate VC to the Remote ATMARP Server for ATMARP purposes. An implementation that wants to use a single VC should use a ipoaArpRemoteSrvrIfIndex value of 0 when configuring a ipoaArpRemoteSrvrEntry for the associating LIS. If ipoaArpRemoteSrvrIfIndex is 0 then an implementation dependent method should be used for finding the vpi and vci of the VC in use to the Remote ATMARP Server. For example, search the ipoaVcTable for a match between ipNetToMediaNetAddress and ipoaArpRemoteSrvrIpAddr from a ipoaArpRemoteSrvrEntry ignoring ipNetToMediaIfIndex. Since a single VC is being used the first match should correspond to the correct VC. If a PVC is intended to be used to communicate with a remote ATMARP server then the ipoaConfigPvcTable should be used to create and active the PVC prior to activating a ipoaArpRemoteSrvrEntry. The object ipoaArpRemoteSrvrRowStatus should have a value of or if using a PVC the InATMARP reply with the IP Address of the Remote ATMARP Server has completed. The value of 'notInService' should be used to indicate that a VC to the Remote ATMARP Server is not active. 3.1.4. ATM VC Table A entry in the ipoaVcTable should have at least one corresponding ipNetToMediaTable entry. Both tables use the ipNetToMediaTable's indexes ipNetToMediaIfIndex and ipNetToMediaNetAddress. The ipoaVcTable has the additional indexes ipoaVcVpi and ipoaVcVci. A Expires November 1997 [Page 7]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ipoaVcEntry exists for every VC per ATM physical interface per destination IP address. Refer to the following diagram that illustrates the relationship between ipoaVcTable and the ipNetToMediaTable: ipoaVcTable ipNetToMediatable ------------------------------ ---------------------------- | ipNetToMediaIfIndex | | ipNetToMediaIfIndex | | ipNetToMediaNetAddress | | ipNetToMediaNetAddress | | ipoaVcVpi | | | | ipoaVcVci | | | | ipoaVcType | | | | | | ipNetToMediaPhysAddress | | ipoaVcNegotiatedEncapsType | | | | ipoaVcNegotiatedMtu | | | | | | ipNetToMediaType | ------------------------------ ---------------------------- ipoaVcType indicates if the entry is for a SVC or PVC. An ipoaVcEntry corresponding to a PVC is created automatically when a ipoaConfigPvcEntry is created and the IP Address at the end of the PVC disovered. The associating ipNetToMediaTable entry would have its ipNetToMediaType set to static(4). ipNetToMediaTable entries created during the ATMARP processing have a ipNetToMediaType of dynamic(3). The process to locally configuring a ipNetToMediaTable entry and a ipoaVcTable entry for a SVC without using ATMARP is not within the scope of this document. 3.1.5. ATM Config PVC Table An entry in the ipoaVcTable is created after the InATMARP successfully completes for a ipoaConfigPvcEntry during its activation. InATMARP must return the IP Address of the other end of the PVC in order to have the needed indexes to create a ipNetToMediaEntry and a ipoaVcEntry. ipoaConfigPvcRowStatus would then be set to active(1). A Network Management Station wanting to create a PVC at a particular system for use as an IP transport would: o use RFC1695 to create the PVC o use the ipoaConfigPvcTable in the IPOA MIB to configure the PVC for use by IP Refer to the following diagram that illustrates the relationship between the ipoaVcTable and the ipoaConfigPvcTable: Expires November 1997 [Page 8]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ipoaVcTable ipoaConfigPvcTable ------------------------------ ---------------------------- | ipNetToMediaIfIndex | | ipNetToMediaIfIndex | | ipNetToMediaNetAddress | | | | ipoaVcVpi | | ipoaConfigPvcVpi | | ipoaVcVci | | ipoaConfigPvcVci | | ipoaVcType | | | | | | ipoaConfigPvcDefaultMtu | | ipoaVcNegotiatedEncapsType | | | | ipoaVcNegotiatedMtu | | | | | | ipoaConfigPvcRowStatus | ------------------------------ ---------------------------- When the ipoaVcEntry is created its ipoaVcType will be set to pvc(1), its ipoaVcNegotiatedEncapsType set to llcSnap(1), and its ipoaVcNegotiatedMtu set to 9180 octets by default. Classic2 allows use of other MTU values for PVCs but considers how a value other than 9180 could be selected to be out of scope. ipoaConfigPvcDefaultMtu can be used to configure the MTU to be used for the PVC. Both ends must have the same value configured. The associating ipNetToMediaTable entry would have its ipNetToMediaType set to static(4). When ipoaConfigPvcRowStatus is changed from active(1) to notInService(2) or from active(1) to destroy(6), this has the side- effect of removing the corresponding ipNetToMediaEntry, ipoaVcEntry and ipoaConfigPvcEntry. 3.1.6. Notifications Both ATM clients and ATMARP Servers must support generation of a ipoaMtuExceed notification. 3.2. Client Supported MIB Definitions The ATMARP Client Table is the only additional MIB table that a client must implement. 3.2.1. ATMARP Client Table A entry in the ipoaArpClientTable should have a corresponding ipAddrTable entry where both are indexed by the same ipAdEntAddr. Refer to the following diagram that illustrates the relationship between ipoaArpClientTable and ipAddrTable entries: ipoaArpClientTable ipAddrTable Expires November 1997 [Page 9]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ----------------------------------- ------------------------ | ipAdEntAddr | | ipAdEntAddr | | | | ipAdEntNetMask | | | | ipAdEntIfIndex | | ipoaArpClientAtmAddr | | | | ipoaArpClientSrvrInUse | | | | ipoaArpClientInArpReqsIn | | | | ipoaArpClientInArpReqsOut | | | | ipoaArpClientInArpRepliesIn | | | | ipoaArpClientInArpRepliesOut | | | | ipoaArpClientInArpInvalidReqsIn | | | | ipoaArpClientInArpInvalidReqsOut| | | | ipoaArpClientArpReqsIn | | | | ipoaArpClientArpReqsOut | | | | ipoaArpClientArpRepliesIn | | | | ipoaArpClientArpRepliesOut | | | | ipoaArpClientArpNaksIn | | | | ipoaArpClientArpNaksOut | | | | ipoaArpClientArpOpUnknown | | | | ipoaArpClientArpSrvrNoResp | | | | ipoaArpClientRowStatus | | | | | | ipAdEntBcastAddr | | | | ipAdEntReasmMaxSize | ----------------------------------- ------------------------ Both tables use the same index, ipAdEntAddr. The ipAddrTable's ipAdEntNetMask when ANDed with its ipAdEntAddr yield the subnet of the LIS which indexes the ipoaLisTable. The ipAddrTable's ipAdEntIfIndex points to the a physical interface ifTable entry. The attachment point for IP into an ATM network is via an ATM interface's ifIndex. This ifIndex is contained in an ipAddrTable entry. ipoaArpClientAtmAddr is the local ATM address associated with the corresponding ATM ifTable entry. ipoaArpClientSrvrInUse is the ATM address of the ATMARP server being used for a particular client. If SVCs are not being used then the value of this object is 0. 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 with the same ifIndex and with the same subnet address. The mechanism for adding these entries to the ipAddrTable (which is read-only) is beyond the scope of this document. 3.3. Server Supported Objects ATMARP servers must support: Expires November 1997 [Page 10]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 o ATMARP Server Table o Notifications as defined in the following sections. This table exists only on a system where at least one ATMARP server is present. 3.3.1. ATMARP Server Table This table defines the list of ATMARP servers within a LIS. Each entry of the table defines each ATMARP server's ATM address, the LIS it is a member of, and various InATMARP and ATMARP statistics. An entry in this table provides information about an ATMARP server within a LIS and is indexed by ipAdEntAddr and the ipoaArpSrvrAddr (ATM address of the ATMARP server). Entries may be created by a management application using the ipoaArpSrvrRowStatus object. 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 ipoaArpSrvrRowStatus object to destroy(6). This includes entries that were added by the system and not by a management application. 3.3.2. Notifications An ATMARP Server must support the following notifications: o ipoaDuplicateIpAddress o ipoaLisCreate o ipoaLisDelete Generation of ipoaLisCreate and ipoaLisDelete notifications is controlled by the ipoaLisTrapEnable object. These notifications indicated when a ipoaLisEntry is either created or deleted. The purpose of these notifications is to enable Network Management Applications to dynamically discover the existence of ATMARP Server LIS participation in order to eventually determine LIS composition via subsequent SNMP queries. It is permissible for a ATM client only system to support the ipoaLisTrapEnable object and generate ipoaLisCreate and ipoaLisDelete notifications. Expires November 1997 [Page 11]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 4. Definitions IPOA-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, experimental, Integer32, IpAddress, Counter32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF AtmConnKind FROM ATM-TC-MIB ipNetToMediaNetAddress, ipNetToMediaIfIndex, ipNetToMediaPhysAddress, ipAdEntAddr FROM RFC1213-MIB InterfaceIndex, InterfaceIndexOrZero FROM IF-MIB ; ipoaMIB MODULE-IDENTITY LAST-UPDATED "9705130000Z" -- May 13, 1997 ORGANIZATION "IETF Internetworking Over NBMA Working Group (ion)" CONTACT-INFO "Maria Greene (greene@ultranet.com) Independent Contractor Jim Luciani (jluciani@BayNetworks.com) Bay Networks Kenneth White (kennethw@vnet.ibm.com) Ted Kuo (tkuo@eos.ncsu.edu) IBM Corp." DESCRIPTION "This module defines a portion of the management information base (MIB) for managing Classical IP and ARP over ATM entities." ::= { experimental 78 } -- *************************************************************** -- Textual Conventions -- *************************************************************** IpoaEncapsType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Expires November 1997 [Page 12]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 "The encapsulation type used on a VC." SYNTAX INTEGER { llcSnap(1), vcMuxed(2), other(3) } IpoaVpiInteger ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An integer large enough to hold a VPI." SYNTAX Integer32 (0..255) IpoaVciInteger ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An integer large enough to hold a VCI." SYNTAX Integer32 (0..65535) IpoaAtmAddr ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x" STATUS current DESCRIPTION "The ATM address used by the network entity. The address type can be determined by the OCTET STRING size. IpoaAtmAddr can be comprised of both an ATM Address and a subaddress. The ATM Address portion is required and must be first in the OCTET STRING. An implementation must use BCD encoding to represent a E.164 address as a MIB object." SYNTAX OCTET STRING (SIZE(0..40)) -- -- Top-level structure of the MIB -- ipoaObjects OBJECT IDENTIFIER ::= { ipoaMIB 1 } ipoaNotifications OBJECT IDENTIFIER ::= { ipoaMIB 2 } ipoaConformance OBJECT IDENTIFIER ::= { ipoaMIB 3 } -- *************************************************************** -- MIB Objects -- *************************************************************** ipoaLisTrapEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current Expires November 1997 [Page 13]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 DESCRIPTION "Indicates whether ipoaLisCreate and ipoaLisDelete traps should be generated by this system. By default, this object should have the value enabled(1) for systems where ATMARP servers are present and disabled(2) on systems where only clients reside." ::= { ipoaObjects 1 } -- -- The Logical IP Subnet Table -- ipoaLisTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaLisEntry 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." ::= { ipoaObjects 2 } ipoaLisEntry OBJECT-TYPE SYNTAX IpoaLisEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single LIS that this system is a member of. This table is indexed by an IP subnet address. Membership in a LIS is independent of the actual ATM physical interfaces being used. The ipoaLisTable defines all LISes that a system is a member of. The ipAddrTable and the ipoaClientTable provides the mapping from local IP address to ATM physical interface. The ipoaLisIfMappingTable provides the mappings between Logical IP Subnets and interfaces. The ipoaLisTable is indexed by ipoaLisSubnetAddr. An entry in the ipAddrTable should exist for each ipAddrEntry that is associated with an IP over ATM interface. Its ipAdEntAddr and ipAdEntNetMask when ANDed should map to a ipoaLisSubnetAddr." INDEX { ipoaLisSubnetAddr } ::= { ipoaLisTable 1 } IpoaLisEntry ::= SEQUENCE { Expires November 1997 [Page 14]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ipoaLisSubnetAddr IpAddress, ipoaLisDefaultMtu Integer32, ipoaLisDefaultEncapsType IpoaEncapsType, ipoaLisInactivityTimer Integer32, ipoaLisMinHoldingTime Integer32, ipoaLisQDepth Integer32, ipoaLisMaxCalls Integer32, ipoaLisCacheEntryAge Integer32, ipoaLisRetries Integer32, ipoaLisTimeout Integer32, ipoaLisDefaultPeakCellRate Integer32, ipoaLisActiveVcs Counter32, ipoaLisRowStatus RowStatus } ipoaLisSubnetAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP subnet address associated with this LIS." ::= { ipoaLisEntry 1 } ipoaLisDefaultMtu 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 ipoaVcNegotiatedMtu object indicates the actual MTU in use for a particular VC." DEFVAL { 9180 } ::= { ipoaLisEntry 2 } ipoaLisDefaultEncapsType OBJECT-TYPE SYNTAX IpoaEncapsType 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 ipoaVcNegotiatedEncapsType object indicates the actual encapsulation in use for a particular VC." DEFVAL { llcSnap } ::= { ipoaLisEntry 3 } Expires November 1997 [Page 15]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ipoaLisInactivityTimer OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The time, in seconds, before a call established for an ipNetToMediaEntry on a client will timeout due to no traffic being passed on the VC. A value of 0 implies no time out." REFERENCE "RFC1755, Sec. 3.4 VC Teardown" DEFVAL { 300 } ::= { ipoaLisEntry 4 } ipoaLisMinHoldingTime OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum amount of time, in seconds, that a call will remain open. If 0 then ipoaInactivityTimer will completely determine when a call is terminated." REFERENCE "RFC1755, Sec. 3.4 VC Teardown" DEFVAL { 60 } ::= { ipoaLisEntry 5 } ipoaLisQDepth OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "packets" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of outstanding requests that are allowed while waiting for ATMARP replies and In_ATMARP replies for this LIS." DEFVAL { 1 } ::= { ipoaLisEntry 6 } ipoaLisMaxCalls OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of SVCs that can be established simultaneously." Expires November 1997 [Page 16]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 DEFVAL { 500 } ::= { ipoaLisEntry 7 } ipoaLisCacheEntryAge OBJECT-TYPE SYNTAX Integer32 (60..1200) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The time, in seconds, before an ipNetToMediaEntry will age out of the table. Note that the default value will be different for a client and a server. A ATMARP server should use a default of 1200 and a client should use 900." DEFVAL { 900 } ::= { ipoaLisEntry 8 } ipoaLisRetries OBJECT-TYPE SYNTAX Integer32 (0..10) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of times the ATMARP request will be retried when no response is received in the timeout interval indicated by ipoaLisTimeout." DEFVAL { 2 } ::= { ipoaLisEntry 9 } ipoaLisTimeout OBJECT-TYPE SYNTAX Integer32 (1..60) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The time to wait, in seconds, before retransmission of an ARP PDU." DEFVAL { 10 } ::= { ipoaLisEntry 10 } ipoaLisDefaultPeakCellRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object is the signalling parameter that should be used when setting up all best effort VCCs. This parameter applies to the forward and backward direction on a per best effort VCC basis. A value of zero implies that no configured default Expires November 1997 [Page 17]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 exists and that local policy should be used to determine the actual default to used during call setup. ATM Signaling Support for IP over ATM (RFC 1755) recommends 1/10th of the ATM interface's speed." ::= { ipoaLisEntry 11 } ipoaLisActiveVcs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of active SVCs." ::= { ipoaLisEntry 12 } ipoaLisRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the ipoaLisTable. When the ipoaLisRowStatus deleted (by setting this object 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 ipoaVcTable entries that were associated with those ipNetToMediaTable entries. Destroying the row also removes the corresponding entries in the ipoaArpSrvrTable, ipoaArpClientTable, ipoaLisIfMappingTable and ipoaArpRemoteSrvrTable. Entries in both the ipNetToMediaTable and the ipoaVcTable that are associated with a ipoaConfigPvcEntry are not effected by changes to ipoaLisRowStatus." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaLisEntry 13 } -- -- The Logical IP Interface Mapping Table -- ipoaLisIfMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaLisIfMappingEntry MAX-ACCESS not-accessible STATUS current Expires November 1997 [Page 18]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 DESCRIPTION "There is one entry in this table for every combination of ipoaLisEntry and IP over ATM interface." ::= { ipoaObjects 3 } ipoaLisIfMappingEntry OBJECT-TYPE SYNTAX IpoaLisIfMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipoaLisIfMappingTable." INDEX { ipoaLisSubnetAddr, ipoaLisIfMappingIfIndex } ::= { ipoaLisIfMappingTable 1 } IpoaLisIfMappingEntry ::= SEQUENCE { ipoaLisIfMappingIfIndex InterfaceIndex, ipoaLisIfMappingStatus RowStatus } ipoaLisIfMappingIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ipAdEntIfIndex object from a ipAddrEntry is used as an index to this table when its ipAdEntAddr is in the subnet implied by ipoaLisSubnetAddr." ::= { ipoaLisIfMappingEntry 1 } ipoaLisIfMappingStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the ipoaLisIfMappingTable." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaLisIfMappingEntry 2 } -- -- The ATMARP Client Table -- ipoaArpClientTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaArpClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires November 1997 [Page 19]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 "The ATMARP clients running on this system." ::= { ipoaObjects 4 } ipoaArpClientEntry OBJECT-TYPE SYNTAX IpoaArpClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single ATMARP Client. Clients can be started and stopped by adding and removing entries from this table. Note that adding and removing entries from this table may have the same effect on the corresponding ipAddrTable entry. An entry in the ipoaArpClientTable has a corresponding entry in the ipAddrTable. Both are indexed by ipAdEntAddr. The ifIndex and subnet mask of a client entry are the ipAddrEntry's ipAdEntIfIndex and ipAdEntNetMask respectively. A remote creation of an object in this table requires that either the corresponding ipAddrTable entry exists or that ipAdEntIfIndex and ipAdEntNetMask be specified in the creation of a ipoaArpClientEntry at a minimum in order to create the corresponding ipAddrEntry. Specification of ipAdEntBcastAddr and ipAdEntReasmMaxSize to complete a ipAddrEntry is implementation dependent." INDEX { ipAdEntAddr } ::= { ipoaArpClientTable 1 } IpoaArpClientEntry ::= SEQUENCE { ipoaArpClientAtmAddr IpoaAtmAddr, ipoaArpClientSrvrInUse IpoaAtmAddr, ipoaArpClientInArpReqsIn Counter32, ipoaArpClientInArpReqsOut Counter32, ipoaArpClientInArpRepliesIn Counter32, ipoaArpClientInArpRepliesOut Counter32, ipoaArpClientInArpInvalidReqsIn Counter32, ipoaArpClientInArpInvalidReqsOut Counter32, ipoaArpClientArpReqsIn Counter32, ipoaArpClientArpReqsOut Counter32, ipoaArpClientArpRepliesIn Counter32, ipoaArpClientArpRepliesOut Counter32, ipoaArpClientArpNaksIn Counter32, ipoaArpClientArpNaksOut Counter32, ipoaArpClientArpOpUnknown Counter32, ipoaArpClientArpSrvrNoResp Counter32, ipoaArpClientRowStatus RowStatus } ipoaArpClientAtmAddr OBJECT-TYPE SYNTAX IpoaAtmAddr MAX-ACCESS read-create Expires November 1997 [Page 20]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 STATUS current DESCRIPTION "The ATM address of the client." ::= { ipoaArpClientEntry 1 } ipoaArpClientSrvrInUse OBJECT-TYPE SYNTAX IpoaAtmAddr MAX-ACCESS read-only STATUS current DESCRIPTION "The ATM address of the ATMARP Server, ipoaArpRemoteSrvrAtmAddr, in use by this client. A null octet string implies that communication with a Remote ATMARP Server is not in effect." DEFVAL { ''H } ::= { ipoaArpClientEntry 2 } ipoaArpClientInArpReqsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP requests received by this client." ::= { ipoaArpClientEntry 3 } ipoaArpClientInArpReqsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP requests sent by this client." ::= { ipoaArpClientEntry 4 } ipoaArpClientInArpRepliesIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP replies received by this client." ::= { ipoaArpClientEntry 5 } ipoaArpClientInArpRepliesOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of InATMARP replies sent by this client." ::= { ipoaArpClientEntry 6 } Expires November 1997 [Page 21]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ipoaArpClientInArpInvalidReqsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this client detected an invalid InATMARP request." ::= { ipoaArpClientEntry 7 } ipoaArpClientInArpInvalidReqsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this client did not receive a InATMARP reply." ::= { ipoaArpClientEntry 8 } ipoaArpClientArpReqsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ATMARP requests received by this client." ::= { ipoaArpClientEntry 9 } ipoaArpClientArpReqsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ATMARP requests sent by this client." ::= { ipoaArpClientEntry 10 } ipoaArpClientArpRepliesIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ATMARP replies received by this client." ::= { ipoaArpClientEntry 11 } ipoaArpClientArpRepliesOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ATMARP replies sent by this client." Expires November 1997 [Page 22]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ::= { ipoaArpClientEntry 12 } ipoaArpClientArpNaksIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of negative ATMARP replies received by this client." ::= { ipoaArpClientEntry 13 } ipoaArpClientArpNaksOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of negative ATMARP replies send by this client." ::= { ipoaArpClientEntry 14 } ipoaArpClientArpOpUnknown OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this client received an ATMARP message with an operation code for which it is not coded to support." ::= { ipoaArpClientEntry 15 } ipoaArpClientArpSrvrNoResp OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this client failed to receive a response from a ATMARP Server within the ipoaLisTimeout value for ipoaLisRetries times. This may imply that the client will re-elect a primary ATMARP server for this LIS from the ipoaArpRemoteSrvrTable." ::= { ipoaArpClientEntry 16 } ipoaArpClientRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Expires November 1997 [Page 23]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 "This object allows entries to be created and deleted from the ipoaArpClientTable." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaArpClientEntry 17 } -- -- The ATMARP Server Table -- ipoaArpSrvrTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaArpSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATMARP servers running on this system." ::= { ipoaObjects 5 } ipoaArpSrvrEntry OBJECT-TYPE SYNTAX IpoaArpSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about an ATMARP server within a 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 ipoaArpSrvrAddr, which is the ATM address of the ATMARP server. Entries may be created by a management application using the ipoaArpSrvrRowStatus object. 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 ipoaArpSrvrRowStatus object to 'destroy(6)'. This includes entries that were added by the system and not by a management application." INDEX { ipAdEntAddr, ipoaArpSrvrAddr } ::= { ipoaArpSrvrTable 1 } IpoaArpSrvrEntry ::= SEQUENCE { ipoaArpSrvrAddr IpoaAtmAddr, ipoaArpSrvrLis IpAddress, ipoaArpSrvrInArpReqsIn Counter32, ipoaArpSrvrInArpReqsOut Counter32, ipoaArpSrvrInArpRepliesIn Counter32, ipoaArpSrvrInArpRepliesOut Counter32, ipoaArpSrvrInArpInvalidReqsIn Counter32, Expires November 1997 [Page 24]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ipoaArpSrvrInArpInvalidReqsOut Counter32, ipoaArpSrvrArpReqsIn Counter32, ipoaArpSrvrArpRepliesOut Counter32, ipoaArpSrvrArpNaksOut Counter32, ipoaArpSrvrArpDupIpAddr Counter32, ipoaArpSrvrArpOpUnknown Counter32, ipoaArpSrvrRowStatus RowStatus } ipoaArpSrvrAddr OBJECT-TYPE SYNTAX IpoaAtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM address of the ATMARP server." ::= { ipoaArpSrvrEntry 1 } ipoaArpSrvrLis OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The subnet address that identifies the LIS this server is associated with." ::= { ipoaArpSrvrEntry 2 } ipoaArpSrvrInArpReqsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP requests received by this ATMARP server." ::= { ipoaArpSrvrEntry 3 } ipoaArpSrvrInArpReqsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP requests sent by this ATMARP server." ::= { ipoaArpSrvrEntry 4 } ipoaArpSrvrInArpRepliesIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP replies received by this ATMARP Expires November 1997 [Page 25]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 server." ::= { ipoaArpSrvrEntry 5 } ipoaArpSrvrInArpRepliesOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP replies sent by this ATMARP server." ::= { ipoaArpSrvrEntry 6 } ipoaArpSrvrInArpInvalidReqsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid InATMARP requests received by this ATMARP server." ::= { ipoaArpSrvrEntry 7 } ipoaArpSrvrInArpInvalidReqsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this server did not receive a InATMARP reply." ::= { ipoaArpSrvrEntry 8 } ipoaArpSrvrArpReqsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ATMARP requests received by this ATMARP server." ::= { ipoaArpSrvrEntry 9 } ipoaArpSrvrArpRepliesOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ATMARP replies sent by this ATMARP server." ::= { ipoaArpSrvrEntry 10 } ipoaArpSrvrArpNaksOut OBJECT-TYPE SYNTAX Counter32 Expires November 1997 [Page 26]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of negative ATMARP replies sent by this ATMARP server." ::= { ipoaArpSrvrEntry 11 } ipoaArpSrvrArpDupIpAddr OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a duplicate IP address was detected by this ATMARP server." ::= { ipoaArpSrvrEntry 12 } ipoaArpSrvrArpOpUnknown OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this ATMARP server received an ATMARP message with an operation code for which it is not coded to support." ::= { ipoaArpSrvrEntry 13 } ipoaArpSrvrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted from the ipoaArpSrvrTable." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaArpSrvrEntry 14 } -- -- The Remote ATMARP Server Table -- ipoaArpRemoteSrvrTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaArpRemoteSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of non-local ATMARP servers associated with a LIS. An entry in this table has three indexes: first the ipoaLisSubnetAddr of the LIS that the corresponding Expires November 1997 [Page 27]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ATMARP server provides ATMARP services for, then the ipoaArpRemoteSrvrAtmAddr, which is the ATM address of the remote ATMARP server and finally the ifIndex of the interface on which the VC to the ATMARP Remote Server will be opened. A ifIndex value of 0 should be used when a single VC is to be shared for ATMARP purposes by multiple interfaces." ::= { ipoaObjects 6 } ipoaArpRemoteSrvrEntry OBJECT-TYPE SYNTAX IpoaArpRemoteSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about one non-local ATMARP server." INDEX { ipoaLisSubnetAddr, ipoaArpRemoteSrvrAtmAddr, ipoaArpRemoteSrvrIfIndex } ::= { ipoaArpRemoteSrvrTable 1 } IpoaArpRemoteSrvrEntry ::= SEQUENCE { ipoaArpRemoteSrvrAtmAddr IpoaAtmAddr, ipoaArpRemoteSrvrRowStatus RowStatus, ipoaArpRemoteSrvrIfIndex InterfaceIndexOrZero, ipoaArpRemoteSrvrIpAddr IpAddress } ipoaArpRemoteSrvrAtmAddr OBJECT-TYPE SYNTAX IpoaAtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM address of the remote ATMARP server." ::= { ipoaArpRemoteSrvrEntry 1 } ipoaArpRemoteSrvrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted from the ipoaArpRemoteSrvrTable as well as indicating the weather a VC exists to the Remote ATMARP Server. ipoaArpRemoteSrvrRowStatus states: active(1) - VC exists to Remote ATMARP Server who's IP Address is stored in ipoaArpRemoteSrvrIpAddr. This VC can be determined by searching the ipoaVcTable using ipoaArpRemoteSrvrIfIndex Expires November 1997 [Page 28]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 (if not 0 otherwise ignore ipNetToMediaIfIndex index) and ipoaArpRemoteSrvrIpAddr. A ipoaArpClientEntry should exist were its ipoaArpClientSrvrInUse object has the same value as ipoaArpRemoteSrvrAtmAddr. notInService(2) - Entry exists without an active VC to the Remote ATMARP Server. notReady(3) - ipoaArpRemoteSrvrEntry is incomplete. createAndGo(4) - Value used to remotely create an entry and then active it. createAndWait(4) - Value used to remotely create an entry and leave entry inactive with either notInService or notReady state. destroy(6) - When ipoaArpRemoteSrvrRowStatus is set with this value the corresponding table entry is deleted." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaArpRemoteSrvrEntry 2 } ipoaArpRemoteSrvrIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex of the interface that the VC to the Remote ATMARP Server is associated with." ::= { ipoaArpRemoteSrvrEntry 3 } ipoaArpRemoteSrvrIpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address of the Remote ATMARP Server. A value of 0 implies that this address isn't known." DEFVAL { 0 } ::= { ipoaArpRemoteSrvrEntry 4 } -- -- The VC Table -- ipoaVcTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaVcEntry MAX-ACCESS not-accessible STATUS current Expires November 1997 [Page 29]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 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 ipoaVcTable 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. The ipoaVcTable doesn't augment the ipNetToMediaTable (ARP Cache) since the the correspondence between tables is not one-to-one." ::= { ipoaObjects 7 } ipoaVcEntry OBJECT-TYPE SYNTAX IpoaVcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A VC (permanent or switched) that this host or server has opened with another member of a LIS. Additional information can be determined about the VC from RFC1695, the AToM MIB. In an SVC environment, entries can not be created in this table by a management application. Entries are automatically added by the system as the result of ATMARP processing. In a PVC environment, an entry is automatically added to this table when an entry is created in the ipoaConfigPvcTable and the IP Address at the end of the PVC is discovered using In_ATMARP. An entry also is added to the ipNetToMediaTable." INDEX { ipNetToMediaIfIndex, ipNetToMediaNetAddress, ipoaVcVpi, ipoaVcVci } ::= { ipoaVcTable 1 } IpoaVcEntry ::= SEQUENCE { ipoaVcVpi IpoaVpiInteger, ipoaVcVci IpoaVciInteger, ipoaVcType AtmConnKind, ipoaVcNegotiatedEncapsType IpoaEncapsType, ipoaVcNegotiatedMtu Integer32 } ipoaVcVpi OBJECT-TYPE SYNTAX IpoaVpiInteger MAX-ACCESS read-only STATUS current Expires November 1997 [Page 30]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 DESCRIPTION "The VPI value for the Virtual Circuit." ::= { ipoaVcEntry 1 } ipoaVcVci OBJECT-TYPE SYNTAX IpoaVciInteger MAX-ACCESS read-only STATUS current DESCRIPTION "The VCI value for the Virtual Circuit." ::= { ipoaVcEntry 2 } ipoaVcType OBJECT-TYPE SYNTAX AtmConnKind MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the Virtual Circuit." ::= { ipoaVcEntry 3 } ipoaVcNegotiatedEncapsType OBJECT-TYPE SYNTAX IpoaEncapsType MAX-ACCESS read-only STATUS current DESCRIPTION "The encapsulation type used when communicating over this circuit." ::= { ipoaVcEntry 4 } ipoaVcNegotiatedMtu OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The MTU used when communicating over this circuit." ::= { ipoaVcEntry 5 } ipoaConfigPvcTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaConfigPvcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table must be supported when PVCs are intended to be supported in order to enable the setup of PVCs for use by IP." ::= { ipoaObjects 8 } ipoaConfigPvcEntry OBJECT-TYPE Expires November 1997 [Page 31]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 SYNTAX IpoaConfigPvcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines a single PVC that exists at this host for use by IP. " INDEX { ipoaConfigPvcIfIndex, ipoaConfigPvcVpi, ipoaConfigPvcVci } ::= { ipoaConfigPvcTable 1 } IpoaConfigPvcEntry ::= SEQUENCE { ipoaConfigPvcIfIndex InterfaceIndex, ipoaConfigPvcVpi IpoaVpiInteger, ipoaConfigPvcVci IpoaVciInteger, ipoaConfigPvcDefaultMtu Integer32, ipoaConfigPvcRowStatus RowStatus } ipoaConfigPvcIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex of the ATM Interface that this PVC is associated with." ::= { ipoaConfigPvcEntry 1 } ipoaConfigPvcVpi OBJECT-TYPE SYNTAX IpoaVpiInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value for the Virtual Circuit." ::= { ipoaConfigPvcEntry 2 } ipoaConfigPvcVci OBJECT-TYPE SYNTAX IpoaVciInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value for the Virtual Circuit." ::= { ipoaConfigPvcEntry 3 } ipoaConfigPvcDefaultMtu OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current Expires November 1997 [Page 32]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 DESCRIPTION "Classic2 allows use of other MTU values for PVCs but considers the how a value other than 9180 could be selected to be out of scope. ipoaConfigPvcDefaultMtu can be used to configure the MTU to be used for the PVC. Both ends must have the same value configured." DEFVAL { 9180 } ::= { ipoaConfigPvcEntry 4 } ipoaConfigPvcRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows rows to be created and deleted in the ipoaConfigPvcTable. Creation of a entry in this table should eventually result in the creation of a ipNetToMediaEntry and a corresponding ipoaVcEntry after InATMARP has determined the destination address of system that the PVC is connected to. Setting this object to destroy(6) should remove the corresponding ipNetToMediaTable and ipoaVcTable entries." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaConfigPvcEntry 5 } -- *************************************************************** -- Notifications -- *************************************************************** ipoaMtuExceeded NOTIFICATION-TYPE OBJECTS { ipNetToMediaIfIndex, ipNetToMediaNetAddress, ipoaVcVpi, ipoaVcVci } STATUS current DESCRIPTION "A frame was received that exceeds the negotiated MTU size." ::= { ipoaNotifications 1 } ipoaDuplicateIpAddress NOTIFICATION-TYPE OBJECTS { ipNetToMediaIfIndex, Expires November 1997 [Page 33]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 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." ::= { ipoaNotifications 2 } ipoaLisCreate NOTIFICATION-TYPE OBJECTS { ipoaLisSubnetAddr } STATUS current DESCRIPTION "Generation of this trap occurs when a ipoaLisEntry is created and ipoaLisTrapEnable is enabled(1)." ::= { ipoaNotifications 3 } ipoaLisDelete NOTIFICATION-TYPE OBJECTS { ipoaLisSubnetAddr } STATUS current DESCRIPTION "Generation of this trap occurs when a ipoaLisEntry is deleted and ipoaLisTrapEnable is enabled(1)." ::= { ipoaNotifications 4 } -- *************************************************************** -- Conformance Definitions -- *************************************************************** ipoaGroups OBJECT IDENTIFIER ::= { ipoaConformance 1 } ipoaCompliances OBJECT IDENTIFIER ::= { ipoaConformance 2 } -- compliance statements ipoaCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that support the IPOA MIB." MODULE -- this module MANDATORY-GROUPS { ipoaGeneralGroup, ipoaBasicNotificationsGroup } GROUP ipoaClientGroup Expires November 1997 [Page 34]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 DESCRIPTION "This group is mandatory for all hosts where ip over ATM client support is required." GROUP ipoaSrvrGroup DESCRIPTION "This group is mandatory for all hosts where ATMARP servers are present." GROUP ipoaSrvrNotificationsGroup DESCRIPTION "This group is mandatory for all hosts where ATMARP servers are present." OBJECT ipoaLisDefaultMtu MIN-ACCESS read-only DESCRIPTION "The agent is not required to allow the user to change the default MTU from the value 9180." OBJECT ipoaLisDefaultEncapsType MIN-ACCESS read-only DESCRIPTION "The agent is not required to allow the user to specify the default encapsulation type for the LIS." OBJECT ipoaLisDefaultPeakCellRate MIN-ACCESS read-only DESCRIPTION "Implementations that do not support IP over ATM over PVCs are not required to allow the user to specify a best effort default peak cell rate." ::= { ipoaCompliances 1 } -- units of conformance ipoaGeneralGroup OBJECT-GROUP OBJECTS { ipoaLisSubnetAddr, ipoaLisDefaultMtu, ipoaLisDefaultEncapsType, ipoaLisInactivityTimer, ipoaLisMinHoldingTime, ipoaLisQDepth, ipoaLisMaxCalls, ipoaLisCacheEntryAge, ipoaLisRetries, ipoaLisTimeout, ipoaLisDefaultPeakCellRate, ipoaLisActiveVcs, ipoaLisRowStatus, ipoaLisIfMappingStatus, Expires November 1997 [Page 35]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ipoaArpRemoteSrvrRowStatus, ipoaArpRemoteSrvrIpAddr, ipoaVcVpi, ipoaVcVci, ipoaVcType, ipoaVcNegotiatedEncapsType, ipoaVcNegotiatedMtu, ipoaConfigPvcDefaultMtu, ipoaConfigPvcRowStatus } STATUS current DESCRIPTION "The required objects." ::= { ipoaGroups 1 } ipoaClientGroup OBJECT-GROUP OBJECTS { ipoaArpClientAtmAddr, ipoaArpClientSrvrInUse, ipoaArpClientInArpReqsIn, ipoaArpClientInArpReqsOut, ipoaArpClientInArpRepliesIn, ipoaArpClientInArpRepliesOut, ipoaArpClientInArpInvalidReqsIn, ipoaArpClientInArpInvalidReqsOut, ipoaArpClientArpReqsIn, ipoaArpClientArpReqsOut, ipoaArpClientArpRepliesIn, ipoaArpClientArpRepliesOut, ipoaArpClientArpNaksIn, ipoaArpClientArpNaksOut, ipoaArpClientArpOpUnknown, ipoaArpClientArpSrvrNoResp, ipoaArpClientRowStatus } STATUS current DESCRIPTION "This group is mandatory for all hosts where ip over ATM client support is required." ::= { ipoaGroups 2 } ipoaSrvrGroup OBJECT-GROUP OBJECTS { ipoaLisTrapEnable, ipoaArpSrvrLis, ipoaArpSrvrInArpReqsIn, ipoaArpSrvrInArpReqsOut, ipoaArpSrvrInArpRepliesIn, Expires November 1997 [Page 36]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 ipoaArpSrvrInArpRepliesOut, ipoaArpSrvrInArpInvalidReqsIn, ipoaArpSrvrInArpInvalidReqsOut, ipoaArpSrvrArpReqsIn, ipoaArpSrvrArpRepliesOut, ipoaArpSrvrArpNaksOut, ipoaArpSrvrArpDupIpAddr, ipoaArpSrvrArpOpUnknown, ipoaArpSrvrRowStatus } STATUS current DESCRIPTION "This group is mandatory for all hosts where ATMARP servers are present." ::= { ipoaGroups 3 } ipoaBasicNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { ipoaMtuExceeded } STATUS current DESCRIPTION "The notifications which an IP over ATM entity is required to implement." ::= { ipoaGroups 4 } ipoaSrvrNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { ipoaDuplicateIpAddress, ipoaLisCreate, ipoaLisDelete } STATUS current DESCRIPTION "The notifications which an IP over ATM ATMARP server is required to implement." ::= { ipoaGroups 5 } END 5. Security Considerations Certain management information defined in this MIB may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information should be employed in such environments. The method for this Expires November 1997 [Page 37]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 authentication is a function of the SNMP Administrative Framework, and has not been expanded by this MIB. Several objects in this MIB allow write access or provide for remote creation. Allowing this support in a non-secure environment can have a negative effect on network operations. It is recommended that implementers seriously consider whether set operations should be allowed without providing, at a minimum, authentication of request origin. It it recommended that without such support that the following objects be implemented as read-only: o ipoaLisDefaultMtu o ipoaLisDefaultEncapsType o ipoaLisInactivityTimer o ipoaLisMinHoldingTime o ipoaLisQDepth o ipoaLisMaxCalls o ipoaLisCacheEntryAge o ipoaLisRetries o ipoaLisTimeout o ipoaLisDefaultPeakCellRate o ipoaLisIfMappingStatus, show state as being either active(1) or notInService(2) depending on the associating interface entry's ifOperStatus. Don't allow set support. o ipoaArpClientAtmAddr o ipoaArpClientAtmAddr o ipoaArpSrvrLisAddr o ipoaArpRemoteSrvrRowStatus, show state as being either active(1) when a VC exists to the Remote ATMARP Server or notInService(2). Don't allow set support. o ipoaConfigPvcDefaultMtu The following objects should either be implemented as read-only or not implemented when security is an issue as previously discussed: o ipoaLisRowStatus o ipoaArpClientRowStatus o ipoaArpSrvrRowStatus o ipoaConfigPvcRowStatus 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. Expires November 1997 [Page 38]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 7. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and Waldbusser S., "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [3] Network Working Group, Laubach M., and Halpern J., "Classical IP and ARP over ATM", Internet Draft, March 26, 1997 [4] Ahmed, M., and Tesink, K., "Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2", RFC 1695, Bell Communications Research, August 1994. [5] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996. [9] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. Expires November 1997 [Page 39]~ Greene et al. IP and ARP over ATM (IPOA) MIB 13 May 1997 [10] Network Working Group, and McCloghrie K., "SNMPv2 MIB for IP", RFC 2011, November 1996. 8. Authors' Addresses Maria N. Greene Independent Contractor E-mail: greene@ultranet.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 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-859-3524 E-mail: tkuo@eos.ncsu.edu Expires November 1997 [Page 40]~