Internet Draft Connection Table October 1993 draft-ietf-ifmib-conntable-00.txt Management Information Base for Management of Network Connections October 8, 1993 Frame Relay Service MIB (frnetmib) Working Group Kenneth R. Rodemann AT&T Bell Laboratories krr@qsun.att.com 1. 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 other Internet Draft. 2. Abstract This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines managed objects used for managing Network Connections. Rodemann Expires April 8, 1994 [Page 1] Internet Draft Connection Table October 1993 3. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 3.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. Rodemann Expires April 8, 1994 [Page 2] Internet Draft Connection Table October 1993 4. Overview This MIB consists of a single table, cnTable, that contains configuration and status information for network connections. This table is generic and may include entries for connections of differing datalink protocols as well as for interworked connections. The cnTable does not track connection performance information, such as packet or octet counts. Each entry in cnTable represents a single uni-directional flow of a connection, from the flow's ingress endpoint to its egress endpoint: +------------------------------------+ | ingress egress | | endpt endpt | ingress | +-------+ +-------+ | egress -> - - - - - - - | |----------| | - - - - - - -> | +-------+ +-------+ | | | +------------------------------------+ With this model, a bidirectional point-to-point connection is represented by two entries in cnTable, one entry per flow, with the corresponding ingress and egress ends flipped. The model also extends naturally to handle point-to-multipoint and multipoint-to-multipoint connections. For example, a full-duplex point-to-multipoint connection from point A to points B, C, and D consists of 6 uni-directional flows, so cnTable will have 6 entries for this connection. To accommodate multipoint connections, cnTable is indexed by both ingress and egress endpoints. A connection endpoint is identified by a 2-tuple, (ifIndex, cnId), where ifIndex specifies the endpoint's interface and cnId specifies the connection's unique identification on the interface. The cnTable, therefore, is indexed by four fields: cnIngressIfIndex, cnIngressCnId, cnEgressIfIndex, cnEgressCnId. To aide the NMS operator, cnTable includes cnIngressName and cnEgressName, which contain textual names of the entry's connection flow endpoints. It is suggested that these objects identify the datalink protocol and the protocol-specific address of the associated connection endpoint. Examples include 'Frame Relay DLCI 120' and 'ATM VPI/VCI 100/110'. Rodemann Expires April 8, 1994 [Page 3] Internet Draft Connection Table October 1993 The objects cnAdminStatus, cnOperStatus, and cnLastChange provide connection status information for each uni-directional flow of a connection. Finally, cnSpecific contains an OID that references an instance object in a protocol-specific MIB corresponding to the entry's uni-directional connection flow. This OID references an actual instance, rather than a MIB group, because the protocol-specific connection table may be indexed differently than cnTable. Rodemann Expires April 8, 1994 [Page 4] Internet Draft Connection Table October 1993 5. Object Definitions CONNECTION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Integer32, TimeTicks, experimental FROM SNMPv2-SMI DisplayString, PhysAddress, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; cnMIB MODULE-IDENTITY LAST-UPDATED "9310082355Z" ORGANIZATION "IETF Frame Relay Network MIB WG" CONTACT-INFO "Kenneth R. Rodemann AT&T Bell Laboratories Room 1F-435A 101 Crawfords Corner Road PO Box 3030 Holmdel, NJ 07733-3030 Tel: 1-908-949-6229 Fax: 1-908-949-1726 E-mail: krr@qsun.att.com" DESCRIPTION "The MIB module to describe generic objects for network connections." ::= { experimental xx } -- The Connection Table -- The Connection Table contains information on -- an entity's connections. Each entry represents -- a uni-directional flow of a connection, from the -- ingress to the egress of the flow. cnTable OBJECT-TYPE SYNTAX SEQUENCE OF CnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of uni-directional connection flows". ::= { cnMIB 1 } cnEntry OBJECT-TYPE SYNTAX CnEntry MAX-ACCESS not-accessible STATUS current Rodemann Expires April 8, 1994 [Page 5] Internet Draft Connection Table October 1993 DESCRIPTION "An entry containing management information applicable to a particular connection flow." INDEX { cnIngressIfIndex, cnIngressCnId, cnEgressIfIndex, cnEgressCnId } ::= { cnTable 1 } CnEntry ::= SEQUENCE { cnIngressIfIndex Integer32, cnIngressCnId Integer32, cnEgressIfIndex Integer32, cnEgressCnId Integer32, cnIngressName DisplayString, cnEgressName DisplayString, cnAdminStatus INTEGER, cnOperStatus INTEGER, cnLastChange TimeTicks, cnSpecific OBJECT IDENTIFIER } cnIngressIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex corresponding to the ingress interface of this uni-directional connection flow." ::= { cnEntry 1 } cnIngressCnId OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION The identification of the ingress connection endpoint for this uni-directional connection flow. The endpoint's identification value must be unique per interface." ::= { cnEntry 2 } cnEgressIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex corresponding to the egress interface of this uni-directional connection flow." Rodemann Expires April 8, 1994 [Page 6] Internet Draft Connection Table October 1993 ::= { cnEntry 3 } cnEgressCnId OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION The identification of the egress connection endpoint for this uni-directional connection flow. The endpoint's identification value must be unique per interface." ::= { cnEntry 4 } cnIngressName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The textual name of the ingress connection endpoint for this uni-directional connection flow. The value of this object should identify the datalink protocol and the protocol-specific address of this connection endpoint. Examples include 'Frame Relay DLCI 120' and 'ATM VPI/VCI 100/110'." ::= { cnEntry 5 } cnEgressName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The textual name of the egress connection endpoint for this uni-directional connection flow. The value of this object should identify the datalink protocol and the protocol-specific address of this connection endpoint. Examples include 'Frame Relay DLCI 120' and 'ATM VPI/VCI 100/110'." ::= { cnEntry 6 } cnAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired state of the uni-directional Rodemann Expires April 8, 1994 [Page 7] Internet Draft Connection Table October 1993 connection flow. The testing(3) state indicates that no operational packets can be passed." ::= { cnEntry 7 } cnOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3), -- in some test mode unknown(4) -- status can not be determined -- for some reason. } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of the uni-directional connection flow. The testing(3) state indicates that no operational packets can be passed." ::= { cnEntry 8 } cnLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the uni-directional connection flow entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { cnEntry 9 } cnSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "A reference to a MIB object in the protocol-specific MIB (i.e., an object having the semantics associated with the InstancePointer textual convention defined in RFC 1443), corresponding to this uni-directional connection flow. If no connection-associated MIB definition specific to the particular media is available, the value should be set to the OBJECT IDENTIFIER { 0 0 }." ::= { cnEntry 10 } Rodemann Expires April 8, 1994 [Page 8] Internet Draft Connection Table October 1993 -- Conformance Information cnTableConformance OBJECT IDENTIFIER ::= { cnMIB 2 } cnTableGroups OBJECT IDENTIFIER ::= { cnTableConformance 1 } cnTableCompliances OBJECT IDENTIFIER ::= { cnTableConformance 2 } -- Units of Conformance cnTableGroup OBJECT-GROUP OBJECTS { cnIngressIfIndex, cnIngressCnId, cnEgressIfIndex, cnEgressCnId, cnIngressName, cnEgressName, cnAdminStatus, cnOperStatus, cnLastChange, cnSpecific } STATUS current DESCRIPTION "A collection of objects providing information applicable to Network Connections." ::= { cnTableGroups 1 } Rodemann Expires April 8, 1994 [Page 9] Internet Draft Connection Table October 1993 -- Compliance Statements cnTableCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the Connection Table." MODULE -- this module MANDATORY-GROUPS { cnTableGroup } OBJECT cnIngressName SYNTAX DisplayString MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT cnEgressName SYNTAX DisplayString MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT cnAdminStatus SYNTAX Integer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT cnSpecific SYNTAX OBJECT IDENTIFIER MIN-ACCESS read-only DESCRIPTION "Write access is not required." END Rodemann Expires April 8, 1994 [Page 10] Internet Draft Connection Table October 1993 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [4] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets - MIB-II", RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Inc., Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [6] K. McCloghrie and F. Kastenholz, "Evolution of Interfaces Group of MIB-II", Internet Draft, Interfaces MIB Working Group, September 20, 1993. [7] K. Rodemann, "Service Management Architecture for Virtual Connection Services", Internet Draft, Frame Relay Service MIB Working Group, July 1, 1993. [8] T. Brown, "Definitions of Managed Objects for Frame Relay Service", Internet Draft, Frame Relay Service MIB Working Group, October 1, 1993. [9] M. Ahmed and K. Tesink, "Definitions of Managed Objects for ATM Management Version 1.0", Internet Draft, ATM MIB Working Group, August 9, 1993. Rodemann Expires April 8, 1994 [Page 11] Internet Draft Connection Table October 1993 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Kenneth R. Rodemann AT&T Bell Laboratories Room 1F-435A 101 Crawfords Corner Road PO Box 3030 Holmdel, NJ 07733-3030 908-949-6229 krr@qsun.att.com Rodemann Expires April 8, 1994 [Page 12] Table of Contents 1. Status of this Memo................................. 1 2. Abstract............................................ 1 3. The SNMPv2 Network Management Framework............. 2 3.1 Object Definitions............................. 2 4. Overview............................................ 3 5. Object Definitions.................................. 5 6. References.......................................... 11 7. Security Considerations............................. 12 8. Author's Address.................................... 12 - i -