RFC 1742
AppleTalk Management Information Base II
Network Working Group S. Waldbusser Request for Comments: 1742 Carnegie Mellon University Obsoletes: 1243 K. Frisa Category: Standards Track FORE Systems, Inc. January 1995 AppleTalk Management Information Base II Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing AppleTalk networks. RFC 1243 defines a set of MIB objects for managing the lower layers of the AppleTalk protocol stack, up to the Network layer. This memo defines additional objects that exist in the AppleTalk portion of the MIB. These objects provide for the management of the transport and session layers of the AppleTalk protocol stack, as well as extensions to the lower layers. This is achieved in an upwardly-compatable fashion. Table of Contents 1. The Network Management Framework ...................... 2 2. Additions and Changes ................................. 3 2.1 New Groups ........................................... 3 2.2 Additional Variables ................................. 3 2.2.1 AARP Additions ..................................... 3 2.2.2 ATPort Additions ................................... 3 2.2.3 DDP Addition ....................................... 3 2.2.4 RTMP Additions ..................................... 4 2.2.5 KIP Addition ....................................... 4 2.2.6 ZIP Additions ...................................... 4 2.2.7 NBP Additions ...................................... 4 2.2.8 ATEcho Additions ................................... 4 2.3 Deprecations ......................................... 4 2.4 Changes .............................................. 5 3. Objects ............................................... 6
3.1 Format of Definitions ................................ 6 4. Overview .............................................. 6 4.1 Structure of MIB ..................................... 7 4.2 The LocalTalk Link Access Protocol Group ............. 7 4.3 The AppleTalk Address Resolution Protocol Group ...... 7 4.4 The AppleTalk Port Group ............................. 8 4.5 The Datagram Delivery Protocol Group ................. 8 4.6 The Datagram Delivery Protocol Router Group .......... 8 4.7 The Routing Table Maintenance Protocol Group ......... 8 4.8 The Routing Table Maintenance Protocol Stub Group .... 8 4.9 The Kinetics Internet Protocol Group ................. 8 4.10 The Zone Information Protocol Router Group .......... 9 4.11 The Zone Information Protocol End Node Group ........ 9 4.12 The Name Binding Protocol Group ..................... 9 4.13 The AppleTalk Echo Protocol Group ................... 9 4.14 The AppleTalk Transaction Protocol Group ............ 9 4.15 The Printer Access Protocol Group ................... 9 4.16 The AppleTalk Session Protocol Group ................ 9 4.17 The AppleTalk Data Stream Protocol Group ............ 10 4.18 The AppleTalk Port Point to Point Group ............. 10 4.19 The Per Port Counters Group ......................... 10 4.20 Textual Conventions ................................. 10 5. Definitions ........................................... 11 6. Acknowledgmnts ........................................ 82 7. References ............................................ 83 8. Security Considerations ............................... 84 9. Authors' Addresses .................................... 84 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD 16/RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16/RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. RFC 1156 which defines MIB-I, the core set of managed objects for the Internet suite of protocols. STD 17/RFC 1213 defines MIB- II, an evolution of MIB-I based on implementation experience and new operational requirements. STD 15/RFC 1157 which defines the SNMP, the protocol used for network access to managed objects.
The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. Additions and Changes This MIB includes additions and changes to RFC 1243. These changes are outlined in the following sections. 2.1. New Groups The following groups are introduced in this MIB: - DDP Router - RTMP Stub - ZIP Router - ATP - PAP - ASP - ADSP - ATPortPtoP - Per Port Counters 2.2. Additional Variables Many variables, mostly counters, were added to groups that existed in RFC 1243. These variables are listed in the following sections. 2.2.1. AARP Additions aarpStatus aarpLookups aarpHits 2.2.2. ATPort Additions atportNetFrom atportZoneFrom atportInPkts atportOutPkts atportHome atportCurrentZone atportConflictPhysAddr atportZoneTable 2.2.3. DDP Addition ddpListenerTable
2.2.4. RTMP Additions rtmpInDataPkts rtmpOutDataPkts rtmpInRequestPkts rtmpNextIREqualChanges rtmpNextIRLessChanges rtmpRouteDeletes rtmpRoutingTableOverflows 2.2.5. KIP Addition kipFrom 2.2.6. ZIP Additions zipNetInfoTable zipInErrors 2.2.7. NBP Additions nbpAddress nbpSocket nbpEnumerator nbpInLookUpRequests nbpInLookUpReplies nbpInBroadcastRequests nbpInForwardRequests nbpOutLookUpReplies nbpRegistrationFailures nbpInErrors 2.2.8. ATEcho Additions atechoOutRequests atechoInReplies 2.3. Deprecations The following variables have been deprecated in this version of the MIB: llapInPkts llapOutPkts llapInNoHandlers llapInErrors
These llap variables were duplicated in the interfaces table of MIB- II. 2.4. Changes The IMPORTS list has been updated to reflect the current SNMP documents. New textual conventions have been defined. Hyphens have been removed from enumeration strings. Variables used as INDEXes to new tables have ACCESS not-accessible. This is because the values of the INDEX variables are contained in the object identifier for any of the other variables in the table; therefore, it does not need to be explicitly available as data. The atportNetConfig and atportZoneConfig variables have been changed from read-only to read-write. The atportZone variable has be renamed to atportZoneDefault, and its DESCRIPTION clause has been clarified. The atportType, atportStatus, and kipType variables have had more values added to their enumeration lists. The DDP group has been split into two groups; one includes variables that any AppleTalk node would implement and the other includes variables only a router would implement. The rtmpState variable now includes another enumeration, invalid(5), which is used when deleting rows. The variables rtmpRangeStart, rtmpRangeEnd, rtmpNextHop, rtmpType, rtmpPort, and rtmpHops have been changed from read-write to read- only. The ZIP Group has been renamed the ZIP End Node Group. The DESCRIPTION clause for zipZoneIndex has been clarified. The variables zipZoneName, zipZoneNetStart, and zipZoneNetEnd have been changed from read-write to read-only. The nbpIndex variable has been changed from read-only to read-write. The nbpObject, nbpType, and nbpZone variables now suggest that the agent reregister its service when any of these variables is changed.
The nbpState variable includes new enumerations. 3. Objects 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) [7] 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 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 [3] 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 [8], subject to the additional requirements imposed by the SNMP. 3.1. Format of Definitions Section 5 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 amended by the extensions specified in [9]. 4. Overview AppleTalk is a protocol suite which features an open peer-to-peer architecture that runs over a variety of transmission media. AppleTalk is defined in [10]. This protocol suite interoperates with the IP protocol suite through various encapsulation methods. As large AppleTalk networks are built that coexist with large IP networks, a method to manage the AppleTalk networks with SNMP becomes necessary. This MIB defines managed objects to be used for managing AppleTalk networks.
4.1. Structure of MIB The objects are arranged into the following groups: - LLAP - AARP - ATPort - DDP - DDP Router - RTMP - RTMP Stub - KIP - ZIP Router - ZIP End Node - NBP - ATEcho - ATP - PAP - ASP - ADSP - ATPortPtoP - Per Port Counters These groups are the basic unit of conformance. If the semantics of a group is applicable to an implementation, then it must implement all objects in that group. For example, a managed agent must implement the KIP group if and only if it implements the KIP protocol. These groups are defined to provide a method for managed agents to know which objects they must implement. 4.2. The LocalTalk Link Access Protocol Group The LocalTalk Link Access Protocol (LLAP) is a medium-speed data-link protocol designed for low cost and plug-and-play operation. The LLAP group is designed to manage all interfaces on a managed device that use this protocol. 4.3. The AppleTalk Address Resolution Protocol Group The AppleTalk Address Resolution Protocol (AARP) is used to map between AppleTalk node addresses, used by the Datagram Delivery Protocol, and the addresses of the underlying data link layer. The AARP table allows for management of the Address Mapping Table on the managed device.
4.4. The AppleTalk Port Group An AppleTalk Port is a logical connection to a network over which AppleTalk packets can be transmitted. The "network" could be a tunnel, backbone network, point-to-point link, etc, as well as a native AppleTalk network. This group allows the management of the configuration of these AppleTalk ports. 4.5. The Datagram Delivery Protocol Group The Datagram Delivery Protocol (DDP) is the network-layer protocol that is responsible for the socket-to-socket delivery of datagrams over the AppleTalk Internet. This group manages the DDP layer on the managed device. The DDP group contains statistical counters for the DDP protocol, and a table describing the DDP sockets that have protocol handlers registered. 4.6. The Datagram Delivery Protocol Router Group Some variables relevant to the Datagram Delivery Protocol (DDP) are only applicable to AppleTalk routers. These variables are included in this group. 4.7. The Routing Table Maintenance Protocol Group The Routing Table Maintenance Protocol (RTMP) is used by AppleTalk routers to create and maintain the routing tables that dictate the process of forwarding datagrams on the AppleTalk internet. The RTMP group manages the RTMP protocol as well as the routing tables generated by this protocol. 4.8. The Routing Table Maintenance Protocol Stub Group The RTMP Stub process is implemented by end nodes in order to maintain information about the routers on their networks. The variables in this group apply to both routers and end nodes. This group manages the RTMP stub process. 4.9. The Kinetics Internet Protocol Group The Kinetics Internet Protocol (KIP) is a protocol for encapsulating and routing AppleTalk datagrams over an IP internet. This name is historical. The KIP group manages the KIP routing protocol as well as the routing tables generated by this protocol.
4.10. The Zone Information Protocol Router Group The Zone Information Protocol (ZIP) is used to maintain a mapping between networks and zone names to facilitate the name lookup process performed by the Name Binding Protocol. Some variables relevant to the Zone Information Protocol (ZIP) are only applicable to AppleTalk routers. These variables are included in this group. 4.11. The Zone Information Protocol End Node Group The ZIP End Node group manages the variables relevant to the Zone Information Protocol (ZIP) that are applicable to both routers and end nodes. 4.12. The Name Binding Protocol Group The Name Binding Protocol (NBP) is a transport-level protocol that is used to convert human readable service names into the numeric AppleTalk network addresses needed for communicating across the AppleTalk network. The NBP group manages this protocol and the NBP services that exist on the managed device. 4.13. The AppleTalk Echo Protocol Group The AppleTalk Echo Protocol is a transport-level protocol used to test and verify the status of the AppleTalk internet. The AtEcho group manages this protocol. 4.14. The AppleTalk Transaction Protocol Group The AppleTalk Transaction Protocol (ATP) is a transport-level protocol that is defined to support transaction based communications. The ATP group manages this protocol. 4.15. The Printer Access Protocol Group The Printer Access Protocol (PAP) is a session-level protocol that enables communications between workstations and print servers. The PAP group manages this protocol. 4.16. The AppleTalk Session Protocol Group The AppleTalk Session Protocol (ASP) is a session-level protocol that enables sequences of communications to occur. ASP uses the services of the AppleTalk Transaction Protocol (ATP), but extends these services into the session layer. The ASP group manages this protocol.
4.17. The AppleTalk Data Stream Protocol Group The AppleTalk Data Stream Protocol (ADSP) is a session-level protocol that provides symmetric, connection-oriented, full-duplex communication between two sockets on the AppleTalk internet. In addition, ADSP handles flow-control and reliability. The ADSP group manages this protocol. 4.18. The AppleTalk Port Point to Point Group The AppleTalk Port Point to Point Group manages ports that have one or more associated point-to-point connections. 4.19. The Per Port Counters Group The Per Port Counters Group contains a set of counters which are deemed useful on a per port basis. 4.20. Textual Conventions New data types are introduced as textual conventions 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 these textual conventions has no effect on either the syntax or the semantics of any managed objects. The use of this is merely an artifact of the explanatory method used. Objects defined in terms of this method 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. The new data types are: ATNetworkNumber ::= -- 2 octets of network -- number in network -- byte order OCTET STRING (SIZE (2)) DdpNodeAddress ::= -- 2 octets of net number -- in network byte order, -- 1 octet of node number OCTET STRING (SIZE (3)) DdpSocketAddress ::= -- 2 octets of net number -- in network byte order, -- 1 octet of node number,
-- 1 octet of socket
-- number (0..255)
OCTET STRING (SIZE (4))
ATName ::= -- 0 to 32 octets of
-- AppleTalk ASCII [10]
OCTET STRING (SIZE (0..32))
(page 11 continued on part 2)
