IP over ATM Working Group INTERNET DRAFT: Maria Greene Expiration Date: September, 1996 James Luciani Ascom Nexion Corp. Kenneth White Ted T.I. Kuo IBM Corp. February 1996 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. 1. Table of Contents 1.0 Table of Contents........................................ 1 2.0 Introduction..............................................2 2.1 Change Log............................................... 2 2.2 Related MIBs............................................. 3 3.0 The SNMPv2 Network Management Framework.................. 4 4.0 Object Definitions....................................... 4 4.1 Format of Definitions.................................... 5 4.2 Textual Conventions...................................... 5 5.0 Overview................................................. 5 5.1 Background............................................... 5 5.2 Structure of the MIB..................................... 6 Expires September 1996 [Page 1] Greene et al. IP over ATM MIB 12 February 1996 5.2.1 Application of the IF-MIB to the IPATM-MIB............. 6 5.2.1.1 ifTable and ifXTable................................. 7 5.2.1.1.1 IP over ATM Virtual Interface...................... 7 5.2.1.1.2 AAL5 and ATM Layers................................ 9 5.2.1.2 The Interface Stack Group............................ 9 5.2.1.3 Definition of Interface-Related Traps................ 10 5.2.2 The ATM Logical IP Subnet (LIS) Table.................. 11 5.2.3 The ATM ARP Server Table............................... 11 5.2.4 The ATM Address Resolution and VC Tables............... 11 6.0 Application of other MIBs to the IPATM-MIB............... 11 6.1 MIB II................................................... 11 6.2 ATM Forum UNI ILMI MIB................................... 12 6.3 ATM MIB as Defined by RFC1695............................ 12 6.4 AToMMIB.................................................. 12 7.0 Definitions.............................................. 12 8.0 Security Considerations.................................. 22 9.0 Acknowledgments.......................................... 22 10.0 References.............................................. 22 11.0 Authors' Addresses...................................... 24 2. 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 the Classical IP and ARP over ATM Update (Part Deux), refer to reference [10]. 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 [2]). 2.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. 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 Expires September 1996 [Page 2] Greene et al. IP over ATM MIB 12 February 1996 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 IpAtmListEntry. (3) Added ipAtmArpSrvrRegistrationType to IpAtmArpSrvrEntry. 2.2. Related MIBs MIB related RFCs and Internet Drafts that have been considered in the development of this document are: o RFC 1213 - 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 [4] and its update [13]) by the Interface work group. o RFC 1695 - Definitions of Managed Objects for ATM Management [15]. 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, since the IPATM MIB will focus on MIB modeling above the AAL5 layer. The concept of virtual interfaces will be borrowed from RFC 1695 to define a IP over ATM Virtual Interface. o Internet Draft from AToMMIB working group on the Definitions of Supplemental Managed Objects for ATM Management [14] - "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 [15], to provide additional support for the management of: - ATM Switched Virtual Connections (SVCs) - ATM Permanent Virtual Connections (PVCs)" o Draft IP-MIB - Replacement for the IP set of objects defined in MIB II (RFC 1213). Expires September 1996 [Page 3] Greene et al. IP over ATM MIB 12 February 1996 o ATM UNI 3.1 Specification o RFC 1573 [4] and its Internet Draft Update [13] - The new Interface MIB. Groups from this MIB that must be supported are: ifTable, ifXTable, ifStack and ifRcvAddr. This RFC defines the following tables for extending the current set of RFC 1213+ defined objects for support of IP and ARP over ATM: o ATM Logical IP Subnet (LIS) o ATM ARP Server o ATM Address Resolution o ATM VC 3. The SNMPv2 Network Management Framework The SNMP Network Management Framework consists of three major components. They are: o RFC 1902 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. This RFC will soon be superseded by several different RFCs that redefine RFC 1213's content using the SNMPv2 framework. In addition, the Interface Group have be broken out and enhanced by the IETF Interface work group (refer to RFC 1573). 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. 4. 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) [11] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a Expires September 1996 [Page 4] Greene et al. IP over ATM MIB 12 February 1996 specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [2] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [12] subject to the additional requirements imposed by the SNMP. 4.1. Format of Definitions Section 7 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI as specified in [2]. 4.2. Textual Conventions Several new data types are introduced as a textual convention in this MIB document. These textual conventions enhance the readability of the specification and can ease comparison with other specifications if appropriate. It should be noted that the introduction of the these textual conventions has no effect on either the syntax nor the semantics of any managed objects. The use of these is merely an artifact of the explanatory method used. Objects defined in terms of one of these methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers and writers in pursuit of the elusive goal of clear, concise, and unambiguous MIB documents. 5. Overview 5.1. Background This document is a product of the IP over ATM working group. Its Expires September 1996 [Page 5] Greene et al. IP over ATM MIB 12 February 1996 purpose is to define a MIB module for extending RFC 1213+ object definitions to support IP and ARP over ATM flows. 5.2. Structure of the MIB The Classical ARP and IP over ATM MIB structure is composed of the following: o IP over ATM Virtual Interfaces o ATM Logic IP Subnet (LIS) Table o ATM ARP Server Table o ATM Address Resolution Table o ATM VC Table 5.2.1. Application of the IF-MIB to the IPATM-MIB The interface MIB is being redefined by the IETF interface working group. Their work is reflected in RFC 1573 [4] and its Internet Draft update [13]. Implementation of RFC 1695 is required for modeling the various layers within an ATM Port. This MIB introduces a IP over ATM Virtual Interface layer as a means of connecting a IP layer into a ATM network via a ATM Port. For modeling purposes this documents identifies three layers of interface entries: o IP over ATM Virtual Interface Layer Data being sent outbound from a TCP/IP instance over an ATM Port needs to be associated with a destination subnet (LIS) in order to enable IP routing. The MIB defined in this document creates a ATM Logical IP Subnet (LIS) table entry that has a one to one correspondence with an associating IP over ATM Virtual Interface. The ifIndex of the IP over ATM Virtual Interface would be used in the ipAddrTable as well as the ipForwardTable. o AAL5 The counters at this layer reflect the total traffic into and out of the ATM Port. An ATM Port can be simultaneously used for routing to multiple subnets as well as shared by multiple TCP/IP instances as well as other protocols' data traffic such as SNA and IPX. o ATM Cell Layer Lowest visible layer in an ATM Port. Expires September 1996 [Page 6] Greene et al. IP over ATM MIB 12 February 1996 The relationship between the above interfaces will be modeled via the ifMib's ifStack group. Creating a IP over ATM virtual interface layer has the following benefits: o ifAdminStatus can be used to enable or disable traffic to a particular subnet. o The counters associated with a IP over ATM Virtual Interface will show traffic for the associating subnet. The counts for the AAL5 and ATM layers show total traffic through the corresponding ATM Port. o Enables SNMP creation of IP over ATM Virtual Interfaces for subnet routing via creation of a corresponding IpAtmListEntry. o Enables routing to multiple subnets per ATM Port. 5.2.1.1. ifTable and ifXTable This section will cover use of both the ifTable (Interface Table) and the ifMib added ifXTable (Extension to the interface table). ifXTable AUGMENTS an interface (ifEntry) entry and hence is indexed by ifIndex. 5.2.1.1.1. IP over ATM Virtual Interface Create a IP over ATM Virtual Interface instance when a IpAtmListEntry is created. A ipAtmLisTable entry is created for every destination subnet to be reached over a ATM Port. The counters at this layer reflect the traffic to and from a specific subnet over a particular ATM Port. o ifIndex - Assigned by the agent based on definition order when a IpAtmLisEntry is created. o ifDescr - Assigned by the agent based on propriatary administration policy. o ifType - Set by agent to IP over ATM Virtual Interface (tbd). o ifMtu - This value will be the same as the corresponding ipAtmLisDefaultMtu or a negotiated MTU. o ifSpeed - This is the total bandwidth in bits per second. ifHighSpeed is the speed of the interface in 1,000,000 bits per second units. This value will be the same as what is provided at the AAL5 layer. Expires September 1996 [Page 7] Greene et al. IP over ATM MIB 12 February 1996 o ifPhysAddress - The ATM Port's complete physical address. This value will be the same as what is provided at the AAL5 layer. o ifAdminStatus - The value of this object can be used to enable or disable subnet routing. o ifOperStatus - The value of this field is a combination of successful changes to either ifAdminStatus or the associating ipAtmLisStatus. o ifLastChange - Reflects when ifOperStatus was last changed. o ifInOctets - Interface layer counter. Reflects IP traffic for this subnet. o ifInUcastPkts - Interface layer counter. Reflects IP traffic for this subnet. o ifInNUcastPkts - deprecated o ifInDiscards - Interface layer counter. Reflects IP traffic for this subnet. o ifInErrors - Interface layer counter. Reflects IP traffic for this subnet. o ifInUnknownProtos - Interface layer counter. Reflects IP traffic for this subnet. o ifOutOctets - Interface layer counter. Reflects IP traffic for this subnet. o ifOutUcastPkts - Interface layer counter. Reflects IP traffic for this subnet. o ifOutNUcastPkts - deprecated o ifOutDiscards - Interface layer counter. Reflects IP traffic for this subnet. o ifOutErrors - Interface layer counter. Reflects IP traffic for this subnet. o ifOutQLen - deprecated o ifSpecific - deprecated o ifName - "The textual name of the interface." Administratively set. o ifInMulticastPkts - Interface layer counter. Reflects IP traffic for this subnet. o ifInBroadcastPkts - Interface layer counter. Reflects IP traffic for this subnet. o ifOutMulticastPkts - Interface layer counter. Reflects IP traffic for this subnet. o ifOutBroadcastPkts - Interface layer counter. Reflects IP traffic for this subnet. o ifHCInOctets - High capacity interface layer counter. Reflects IP traffic for this subnet. o ifHCOutOctets - High capacity interface layer counter. Reflects IP traffic for this subnet. o ifLinkUpDownTrapEnable - Will be R/W in order to control trap generation. o ifHighSpeed Expires September 1996 [Page 8] Greene et al. IP over ATM MIB 12 February 1996 o ifPromiscuousMode - Always returned as false. o ifConnectorPresent - Always returned as false. 5.2.1.1.2. AAL5 and ATM Highest and lowest layers for an ATM Port. A IP over ATM Virtual Interface is stacked above a AAL5 physical interface. Multiple IP over ATM Virtual Interfaces can be stacked above the same AAL5 interface. An AAL5 interface typically has a one to one correspondence with the lowest ATM Port layer ATM. The modeling of AAL5 to ATM is outside the scope of this document. The AAL5 layer is identified as the connection point for IP over ATM Virtual Interfaces into a particular ATM Port. The ATM layer is identified as a Port's lowest layer connecting into a ATM Network. IP and ARP over ATM traffic is transparent to either the AAL5 or ATM layers. Counters at the AAL5 and ATM layers reflect the total data transfer activity into and out of the ATM Port. Typically traffic over an ATM Port can be physically started or stop via a SNMP SET to its associating ifAdminStatus. The ifOperStatus at the AAL5 layer is completely independent of the higher layer IP over ATM Virtual Interface ifOperStatus(s). However, a IP over ATM Virtual Interface ifOperStatus is dependent on the state of the AAL5 interface ifOperStatus that it is stacked above. 5.2.1.2. The Interface Stack Group Implementation of this group is required. This group is used to model the relationship between a IP over ATM virtual interface and the associating physical interfaces layers associated with an ATM Port (AAL5 and ATM). The Interface Stack Group defines the ifStackTable that will contain various objects to reflect the relationship between the sublayers of an interface. The highest level interface in our case is a IP over ATM virtual interface. A IP over ATM virtual interface reflects PVC and SVC traffic to a particular subnet for a given ATM Port. For purposes of this document a ATM Port is modeled as two layers below the IP over ATM virtual interface layer: o IP over ATM Virtual Interface o AAL5 Layer Interface o ATM Cell Layer Interface Consider the following definition of ifStackTable as extracted from ifMib: Expires September 1996 [Page 9] Greene et al. IP over ATM MIB 12 February 1996 Given the following definitions: ATMPORT P LIS A ATMPORT P LIS B ATMPORT P The following interface entries will be created: o AAL5 Layer Interface P, ifIndex = 1, ifType = 49 o ATM Cell Layer Interface P, ifIndex = 2, ifType = 37 o IP over ATM Virtual Interface B, ifIndex = 3, ifType = tbd o IP over ATM Virtual Interface A, ifIndex = 4, ifType = tbd Four ifStack entries will be created as follows: o ifStackHigherLayer = 3, ifStackLowerLayer = 1 o ifStackHigherLayer = 4, ifStackLowerLayer = 1 o ifStackHigherLayer = 1, ifStackLowerLayer = 2 Note: All virtual interfaces that are associated with the same ATM Port will have the same ifStackLowerLayer ifIndex, which points to a AAL5 layer interface. 5.2.1.3. Definition of Interface-Related Traps linkup and linkdown traps are generated when an interface is successfully activated or deactivate. Deactivation can occur by changing the ifAdminState of the corresponding interface table entry or in the case of a IP over ATM Virtual Interface via the corresponding ipAtmLisStatus object. Support of linkDown and linkUp traps are required for IP over ATM Virtual Interfaces. Control of trap generation is via the ifXEntry object ifLinkUpDownTrapEnable. o linkDown "A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links is about to transition into the down state." o linkUp "A linkUp trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links has transitional out of the down state." Expires September 1996 [Page 10] Greene et al. IP over ATM MIB 12 February 1996 5.2.2. The 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 ATP transport. The attachment point is modeled as a IP over ATM Virtual Interface. IP over ATM Virtual Interfaces have a one to one correspondence with a LIS table entry. The LIS table is indexed by subnet and not ifIndex. 5.2.3. The 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 [10], minimum number of entries in this table is three. 5.2.4. The ATM Address Resolution and VC Tables The ATM Address Resolution and VC Tables essentially enhance the ipNetToMediaTable to facilitate ATM address resolution. 6. Application of other MIBs to the IPATM MIB 6.1. MIB II MIB II was defined by RFC 1213 and is under revision in order to adhere to the SNMPv2 SMI and will be reflected in several different RFCs. In particular, the interface group as defined by the ifMib will be used instead of the RFC 1213 definition. The ifMib is currently being developed and as such is subject to change. The ifMib provides several very useful constructs over the prior RFC 1213 base that are necessary in proper support of ATM Ports. 6.2. 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 Expires September 1996 [Page 11] Greene et al. IP over ATM MIB 12 February 1996 entity encapsulated in a AAL5 header. Support of the ILMI MIB(s) is out of the scope of this document. 6.3. ATM MIB as defined by RFC 1695 The objects defined by RFC 1695 are required for implementing the layers between AAL5 and ATM but are considered out of the scope of this document. 6.4. AToMMIB Under investigation. 7. Definitions -- Issues/to be done: -- 1. Add REFERENCE clauses -- 2. Fill in document reference numbers -- 3. Get IANA assignment for ifAtmVirtual ifType value -- 4. Should we add some statistics? Which ones? -- 5. What objects should go in the NOTIFICATIONS? -- 6. Get a non-experimental OID number for the root IP-ATM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, experimental, Integer32, IpAddress FROM SNMPv2-SMI TruthValue, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF AtmAddr FROM ATMTC-MIB ipNetToMediaIfIndex, ipNetToMediaNetAddress, ipNetToMediaPhysAddress FROM RFC1213-MIB InterfaceIndex FROM IF-MIB ; ipAtmMIB MODULE-IDENTITY Expires September 1996 [Page 12] Greene et al. IP over ATM MIB 12 February 1996 LAST-UPDATED "9602061200Z" -- February 9, 1996 ORGANIZATION "IETF IP over ATM Working Group" CONTACT-INFO "Maria Greene (greene@nexen.com) Jim Luciani (luciani@nexen.com) Ascom Nexion, Inc. Kenneth White (kennethw@vnet.ibm.com) Ted Kuo (tik@vnet.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 as defined in [RFC1577+] [xx]. It is meant to be used in connection with the ATM-MIB [xx], MIB-II [xx], and optionally the IF-MIB [xx]." ::= { experimental 2001 } -- -- 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 entity is a member of." ::= { ipAtmObjects 1 } ipAtmLisEntry OBJECT-TYPE SYNTAX IpAtmLisEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular LIS that this system is a member of. The attachment point between an IP over ATM entity and a LIS is referred to as a IP over ATM virtual interface. Unlike hardware ports, IP over ATM virtual interfaces can be created by management. However, the RFC 1573 Interfaces table does not directly support row creation. Therefore, creating or deleting a row in the ipAtmLisTable is defined to have the side effect of creating or deleting corresponding rows in Expires September 1996 [Page 13] Greene et al. IP over ATM MIB 12 February 1996 - the MIB-II / RFC 1573 ifTable - the RFC 1573 ifXTable (if supported) - the MIB-II ipAddrTable New Interfaces table rows for IP over ATM virtual interfaces always have 'ifAdminStatus' set to 'down'. A IP over ATM virtual interface will be layered on top of one or more other interfaces as defined in the ATM-MIB [xx]. The ifStackTable from the IF-MIB [xx] can be used to determine the stacking relationships Therefore, support for the ifStackTable is highly recommended. A Note On Indexing ------------------ Most of the tables in this MIB are indexed in whole or in part by 'ipAtmLisSubnet' - not by 'ifIndex'. Why is there a separate index? Traditionally, ifIndex values are chosen by agents, and are permitted to change across restarts. Using ifIndex to index tables in this MIB could complicate row creation and/or cause interoperability problems (if each agent had special restrictions on ifIndex). Having a separate index avoids these problems. A Note On IP Address Assignment ------------------------------- Note that the IP address assigned to the virtual interface (using the ipAddrTable from the IP-MIB [xx] or MIB-II [xx]) must be consistent with this LIS' subnet address." INDEX { ipAtmLisSubnet } ::= { ipAtmLisTable 1 } IpAtmLisEntry ::= SEQUENCE { ipAtmLisSubnet IpAddress, ipAtmLisSubnetMask IpAddress, ipAtmLisIfIndex InterfaceIndex, ipAtmLisVcType INTEGER, ipAtmLisIsSrvr TruthValue, ipAtmLisDefaultMtu Integer32, ipAtmLisStatus RowStatus } ipAtmLisSubnet OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible Expires September 1996 [Page 14] Greene et al. IP over ATM MIB 12 February 1996 STATUS current DESCRIPTION "The identifier of this LIS, which is an IP subnet." ::= { ipAtmLisEntry 1 } ipAtmLisSubnetMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The subnet mask for the LIS." ::= { ipAtmLisEntry 2 } ipAtmLisIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex value of the ifEntry that corresponds to this Logical IP Subnet." ::= { ipAtmLisEntry 3 } ipAtmLisVcType OBJECT-TYPE SYNTAX INTEGER { svc(1), pvc(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This value of this object indicates whether this LIS member uses PVCs or SVCs to communicate with other members of the LIS." ::= { ipAtmLisEntry 4 } ipAtmLisIsSrvr OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether this member is the ATMARP server for this LIS." ::= { ipAtmLisEntry 5 } ipAtmLisDefaultMtu OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current Expires September 1996 [Page 15] Greene et al. IP over ATM MIB 12 February 1996 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." DEFVAL { 9180 } ::= { ipAtmLisEntry 6 } ipAtmLisStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "A control that allows LIS entries to be created and deleted from this table." ::= { ipAtmLisEntry 7 } -- -- The ATMARP Server Table -- ipAtmArpSrvrTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAtmArpSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATMARP servers for a LIS." ::= { ipAtmObjects 2 } ipAtmArpSrvrEntry OBJECT-TYPE SYNTAX IpAtmArpSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "In an SVC environment, the agent must support at least three of these." INDEX { ipAtmLisSubnet, ipAtmArpSrvrAddr } ::= { ipAtmArpSrvrTable 1 } IpAtmArpSrvrEntry ::= SEQUENCE { ipAtmArpSrvrAddr AtmAddr, ipAtmArpSrvrInUse TruthValue, ipAtmArpSrvrPriority Integer32, ipAtmArpSrvrRegistrationType INTEGER, ipAtmArpSrvrStatus RowStatus } ipAtmArpSrvrAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible Expires September 1996 [Page 16] Greene et al. IP over ATM MIB 12 February 1996 STATUS current DESCRIPTION "The ATM Address of the ATMARP server." ::= { ipAtmArpSrvrEntry 1 } ipAtmArpSrvrInUse OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether this ATMARP Server is the one being used on this LIS." ::= { ipAtmArpSrvrEntry 2 } ipAtmArpSrvrPriority OBJECT-TYPE SYNTAX Integer32 (1..10) MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows the network administrator to order the ATMARP servers to control which one will be used by this entity." ::= { ipAtmArpSrvrEntry 3 } ipAtmArpSrvrRegistrationType OBJECT-TYPE SYNTAX INTEGER { implicit(1), explicit(2), explicitAuthenication(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "An object which defines the Type of registration in effect for this ATM Arp Server." ::= { ipAtmArpSrvrEntry 4 } ipAtmArpSrvrStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object which allows entries to be created in this table." ::= { ipAtmArpSrvrEntry 5 } -- -- The Address Resolution Table -- ipAtmNetToMediaTable OBJECT-TYPE Expires September 1996 [Page 17] Greene et al. IP over ATM MIB 12 February 1996 SYNTAX SEQUENCE OF IpAtmNetToMediaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table which caches mappings between ATM and IP addresses that were learned using ATMARP." ::= { ipAtmObjects 3 } ipAtmNetToMediaEntry OBJECT-TYPE SYNTAX IpAtmNetToMediaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single IP to ATM address mapping. This table is an extension of the ipNetToMediaTable defined in the RFC1213-MIB (mib-2). That table includes the following objects: ipNetToMediaIfIndex -- which will be of type ipAtmVirtual(xx) ipNetToMediaPhysAddress -- the ATM address ipNetToMediaNetAddress -- the IP address ipNetToMediaType -- how the entry was added " INDEX { ipNetToMediaIfIndex, ipNetToMediaNetAddress } ::= { ipAtmNetToMediaTable 1 } IpAtmNetToMediaEntry ::= SEQUENCE { ipAtmNetToMediaStatus RowStatus } ipAtmNetToMediaStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries be created and deleted from this table." ::= { ipAtmNetToMediaEntry 1 } -- -- The VC Table -- ipAtmVcTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAtmVcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of open VCs that this client or server has (permanent or switched)." ::= { ipAtmObjects 4 } Expires September 1996 [Page 18] Greene et al. IP over ATM MIB 12 February 1996 ipAtmVcEntry OBJECT-TYPE SYNTAX IpAtmVcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single open VC. A VC is associated with an address resolution table entry, therefore, this table is indexed first by the indices of the corresponding ipAtmNetToMediaEntry, then by the VPI/VCI of the connection." INDEX { ipNetToMediaIfIndex, ipNetToMediaNetAddress, ipAtmVcVpi, ipAtmVcVci } ::= { ipAtmVcTable 1 } IpAtmVcEntry ::= SEQUENCE { ipAtmVcVpi Integer32, ipAtmVcVci Integer32, ipAtmVcType INTEGER, ipAtmVcNegotiatedMtu Integer32, ipAtmVcEncapsType INTEGER, ipAtmVcStatus RowStatus } ipAtmVcVpi OBJECT-TYPE SYNTAX Integer32 (0..4095) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value for the Virtual Circuit." ::= { ipAtmVcEntry 1 } ipAtmVcVci OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value for the Virtual Circuit." ::= { ipAtmVcEntry 2 } ipAtmVcType OBJECT-TYPE SYNTAX INTEGER { pvc(1), svc(2) } MAX-ACCESS read-only STATUS current DESCRIPTION Expires September 1996 [Page 19] Greene et al. IP over ATM MIB 12 February 1996 "The type of the virtual circuit which is either a permanent virtual circuit ('pvc(1)'), or a switched virtual circuit ('svc(2)')." ::= { ipAtmVcEntry 3 } ipAtmVcEncapsType OBJECT-TYPE SYNTAX INTEGER { other(1), llcSnap(2) } 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 negotiated MTU used when communicating over this circuit." ::= { ipAtmVcEntry 5 } ipAtmVcStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object which supports the RowStatus convention for creating and deleting rows in this table." ::= { ipAtmVcEntry 6 } -- -- Notifications -- ipAtmNotifications OBJECT IDENTIFIER ::= { ipAtmMIB 2 } ipAtmMtuExceeded NOTIFICATION-TYPE OBJECTS { ipNetToMediaIfIndex, ipNetToMediaNetAddress } STATUS current DESCRIPTION "A frame was received that exceeds the negotiated MTU size." ::= { ipAtmNotifications 1 } Expires September 1996 [Page 20] Greene et al. IP over ATM MIB 12 February 1996 ipAtmDuplicateIpAddress NOTIFICATION-TYPE OBJECTS { ipNetToMediaIfIndex, ipNetToMediaNetAddress, 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 "[ note about what other MIBs the agent must support ]" MODULE -- this module MANDATORY-GROUPS { ipAtmGeneralGroup } ::= { ipAtmCompliances 1 } ipAtmGeneralGroup OBJECT-GROUP OBJECTS { ipAtmLisIfIndex, ipAtmLisVcType, ipAtmLisIsSrvr, ipAtmLisDefaultMtu, ipAtmLisStatus, ipAtmArpSrvrInUse, ipAtmArpSrvrPriority, ipAtmArpSrvrStatus, ipAtmNetToMediaStatus, ipAtmVcType, ipAtmVcEncapsType, ipAtmVcNegotiatedMtu, ipAtmVcStatus } STATUS current DESCRIPTION "The required objects." ::= { ipAtmGroups 1 } Expires September 1996 [Page 21] Greene et al. IP over ATM MIB 12 February 1996 END 8. Security Considerations Currently, the set of proposed standards that define the SNMPv2 Framework does not provide for security. Even though several experimental models are being defined, this is in the authors opinion a serious flaw. It is recommended that implementers seriously consider whether SET operations should be allowed without providing at a minimum authentication of request origin. 9. Acknowledgments This document is a product of the IP over ATM 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. 10. References [1] K. McCloghrie, and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [2] 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. [3] 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. [4] K. McCloghrie and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, January 1994. [5] 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. Expires September 1996 [Page 22] Greene et al. IP over ATM MIB 12 February 1996 [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [7] ATM Forum, "ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification", November 1994. [8] ATM Forum, "ATM User-Network Interface, Version 4.0 (UNI 4.1) Specification, Part I", 1995. (Note: I think this is TM4.0, instead of UNI4.0 - tik. ) [9] M. Laubach,"Classical IP and ARP over ATM", RFC 1577, January 1994. [10] M. Laubach, "Classical IP and ARP over ATM Update (Part Deux)", August 31, 1995. Refer to for the latest draft of this document. [11] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987. [12] ATM Forum Technical Committee, "LAN Emulation Client Management: Version 1.0 Specification", af-lane-0044.000, ATM Forum, September 1995. [13] ifMib Working Group, Keith McCloghrie, and Frank Kastenholz, "The Interfaces Group MIB", , January 1996 [14] AToMMIB Working Group, Faye Ly, Michael Noto, Andrew Smith, Kaj Tesink, "Definitions of Supplemental Managed Objects for ATM Management", , February 1996 [15] Ahmed, M., Tesink, K., "Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2", RFC 1695, Bell Communications Research, August 1994. Expires September 1996 [Page 23] Greene et al. IP over ATM MIB 12 February 1996 11. 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 Ascom Nexion 289 Great Rd Acton, MA 01720, USA Phone: +1-508-266-4522 E-mail: luciani@nexen.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. E69/Bldg 503 IBM Corporation Research Triangle Park, NC 27709, USA Phone: +1-914-254-6214 E-mail: tik@vnet.ibm.com Expires September 1996 [Page 24]