📄 rfc2561.txt
字号:
Network Working Group K. WhiteRequest for Comments: 2561 IBM Corp.Category: Standards Track R. Moore IBM Corp. April 1999 Base Definitions of Managed Objects for TN3270E Using SMIv2Status 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.Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved.Abstract This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC 1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. A TN3270E server connects a Telnet client performing 3270 emulation to a target SNA host over both a client-side network (client to TN3270E server) and an SNA Network (TN3270E server to target SNA host). The client-side network is typically TCP/IP, but it need not be. A host TN3270E server refers to an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA) System Services Control Point (SSCP) for the dependent Secondary Logical Units (SLUs) that the server makes available to its clients for connecting into a SNA network. A gateway TN3270E server resides on an SNA node other than an SSCP, either an SNA type 2.0 node, a boundary-function-attached type 2.1 node, or an APPN node acting in the role of a Dependent LU Requester (DLUR). Host and gateway TN3270E server implementations typically differ greatly as to their internal implementation and system definition (SYSDEF) methods.White & Moore Standards Track [Page 1]RFC 2561 TN3270E Using SMIv2 MIB April 1999 It is the intent that the MIB defined herein be extended by subsequent memos. For example, one such extension enables collection of TN3270E response time data.Table of Contents 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 The SNMP Network Management Framework . . . . . . . . . . 3 3.0 Structure of the MIB . . . . . . . . . . . . . . . . . . . 4 3.1 TN3270E Server Control . . . . . . . . . . . . . . . . . . 5 3.1.1 tn3270eSrvrConfTable . . . . . . . . . . . . . . . . . 5 3.1.2 tn3270eSrvrPortTable . . . . . . . . . . . . . . . . . 6 3.1.3 tn3270eSrvrStatsTable . . . . . . . . . . . . . . . . 7 3.2 TN3270E Server Resource Configuration . . . . . . . . . . 7 3.3 Resource Name / Client Address Mappings . . . . . . . . . 8 3.3.1 tn3270eSnaMapTable . . . . . . . . . . . . . . . . . . 8 3.3.2 tn3270eResMapTable . . . . . . . . . . . . . . . . . . 9 3.3.3 tn3270eTcpConnTable . . . . . . . . . . . . . . . . . 9 3.4 Advisory Spin Lock Usage . . . . . . . . . . . . . . . . . 9 3.5 Row Persistence . . . . . . . . . . . . . . . . . . . . . 10 3.6 IANA Considerations . . . . . . . . . . . . . . . . . . . 10 4.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 5.0 Security Considerations . . . . . . . . . . . . . . . . . 51 6.0 Intellectual Property . . . . . . . . . . . . . . . . . . 52 7.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 53 8.0 References . . . . . . . . . . . . . . . . . . . . . . . . 53 9.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 55 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 561.0 Introduction This document is a product of the TN3270E Working Group. Its purpose is to define a MIB module for support by a TCP/IP implementation for configuration and management of TN3270E servers. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [22].White & Moore Standards Track [Page 2]RFC 2561 TN3270E Using SMIv2 MIB April 19992.0 The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.White & Moore Standards Track [Page 3]RFC 2561 TN3270E Using SMIv2 MIB April 19993.0 Structure of the MIB The TN3270E-MIB is split into the following components: o TN3270E Server Control o TN3270E Server Resource Configuration o Resource/Client Address Mappings There are three additional sections to address: o Advisory Spin Lock Usage o Row Persistence o IANA Considerations The TN3270E-MIB is defined primarily for TN3270E servers. This memo does not explicitly address use of the MIB by TN3270 servers that do not support the TN3270E protocol. Even though a significant number of the objects in the MIB do apply in the TN3270-only case, the case was not addressed, since it is unlikely that a TN3270-only server would implement this MIB. The SYSAPPL-MIB, reference [24], contains the Utf8String textual convention (TC) that the TN3270E-MIB imports. This TC, which is used for some MIB objects containing textual information, enables internationalization of text strings, whereas the DisplayString TC does not. The SNMP-FRAMEWORK-MIB, reference [1], contains the SnmpAdminString TC that the TN3270E-MIB also imports. Like the Utf8String TC, this TC also enables internationalization of text strings; in addition, it provides some guidelines on the length and content of the strings. It is important to note that implementation of the SYSAPPL-MIB is not actually a prerequisite for implementing the TN3270E-MIB. On the other hand, implementation of the TN3270E-MIB does not preclude implementing the SYSAPPL-MIB as well. When both MIBs are implemented, the primary index into most of the TN3270E-MIB tables, tn3270eSrvrConfIndex, SHOULD equal one of the SYSAPPL-MIB's sysApplElmtRunIndex values. In this case the entry in the sysApplElmtRunTable provides additional information on a TN3270E server. The MIB defined by this memo supports use of both IPv4 and IPv6 addressing. Two textual conventions, IANATn3270eAddrType and Tn3270eAddress, are defined for this purpose. IANATn3270eAddress is essentially equivalent to the TAddress TC, defined by RFC 1903. The difference between the two is that IANATn3270eAddress allows a zero- length octet string, while TAddress doesn't. It is important that IANATn3270eAddress allow for the absence of an address, because someWhite & Moore Standards Track [Page 4]RFC 2561 TN3270E Using SMIv2 MIB April 1999 objects with this syntax are used as table indexes, and have special meanings when they contain zero-length strings. The IANATn3270eAddrType textual convention is used rather than the TDomain TC (defined by RFC 1903) for identifying the contents of a tn3270eTAddress object. TDomain uses an OID to characterize the contents of an associated TAddress object. IANATn3270eAddrType was chosen over TDomain because, with a SYNTAX of Unsigned32 (enumeration type), it is much simpler to use as a component in an instance identifier. It was placed in the IANA-administered module to allow for the addition of values to cover cases (such as proxy servers) not covered by the TN3270E-MIB itself.3.1 TN3270E Server Control This group of objects provides for TN3270E server configuration and control. It consists of three tables: o tn3270eSrvrConfTable o tn3270eSrvrPortTable o tn3270eSrvrStatsTable The tn3270eSrvrConfTable is the primary table within the entire TN3270E-MIB. As section 3.1.1 indicates, each TN3270E server is represented by an entry in this table, indexed by tn3270eSrvrConfIndex. Most of the other tables defined by the TN3270E-MIB have tn3270eSrvrConfIndex as their primary index. Entries in these tables MUST NOT exist for a TN3270E server when it does not have a tn3270eSrvrConfigEntry.3.1.1 tn3270eSrvrConfTable The tn3270eSrvrConfTable contains a set of objects primarily used for configuring and managing TN3270E servers. As with most of the other tables in the TN3270E-MIB, this table is indexed by an unsigned integer, tn3270eSrvrConfIndex. This primary index element enables support of multiple TN3270E servers by a single SNMP agent. Within the set of MIB objects returned by one SNMP agent, tn3270eSrvrConfIndex values MUST be unique, and need not be contiguous. The tn3270eSrvrConfInactivityTimer object defines the inactivity period for user traffic on TN3270 and TN3270E sessions.White & Moore Standards Track [Page 5]RFC 2561 TN3270E Using SMIv2 MIB April 1999 The four objects: o tn3270eSrvrConfConnectivityChk o tn3270eSrvrConfTmNopInterval o tn3270eSrvrConfTmNopInactTime o tn3270eSrvrConfTmTimeout define the parameters for performing the "Telnet Timing Mark Option" as defined by RFC 860 [17]. The object tn3270eSrvrConfConnectivityChk allows a Management Station to select either a NOP command or a TIMING-MARK command. Sending a NOP command results in less overhead then a TIMING-MARK command, since a client doesn't send a reply. The objects tn3270eSrvrConfAdminStatus and tn3270eSrvrConfOperStatus enable remote starting and stopping of a TN3270E server, and report the current state of the server. The object tn3270eSrvrConfFunctionsSupported indicates which of the TN3270 and TN3270E options a server supports. The object tn3270eSrvrConfSessionTermState defines as a TN3270E server-wide option what SHOULD occur when the SNA portion of a TN3270 or TN3270E session terminates with respect to the associated TCP connection. The object tn3270eSrvrConfSrvrType indicates whether the TN3270E server represented by a tn3270eSrvrConfEntry is a host or a gateway server. The object tn3270eSrvrConfContact provides a scratch pad area for a TN3270E server administrator to store information for later retrieval. The object tn3270eSrvrConfLastActTime reports the DateAndTime when the server was most recently activated. The special value of all '00'Hs indicates that the server has never been active. The object tn3270eSrvrConfRowStatus provides the capability to perform row creation and deletion operations on this table.3.1.2 tn3270eSrvrPortTable The tn3270eSrvrPortTable represents the local TCP ports associated with a TN3270E server. This information is important because some TN3270E server implementations support usage of multiple local ports. A tn3270eSrvrPortEntry is indexed by: o tn3270eSrvrConfIndex o tn3270eSrvrConfPort o tn3270eSrvrConfPortAddrType o tn3270eSrvrConfPortAddress Certain TN3270E server implementations restrict a local TCP port to a particular local IP address, instead of allowing connections for any local IP address to occur via the port. tn3270eSrvrConfPortAddrTypeWhite & Moore Standards Track [Page 6]RFC 2561 TN3270E Using SMIv2 MIB April 1999 and tn3270eSrvrConfPortAddress allow this restriction to be represented in the MIB. A TN3270E server that doesn't restrict connections over a port to a local IP Address SHALL use the value
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -