rfc2561.txt

RFC 的详细文档！

White & 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
   unknown(0) for tn3270eSrvrConfPortAddrType, and a zero-length octet
   string for tn3270eSrvrConfPortAddress.

3.1.3  tn3270eSrvrStatsTable

   The tn3270eSrvrStatsTable defines a series of objects that provide
   general usage statistics for a TN3270E server.  An entry can
   represent the total activity for a server, or it can represent the
   activity occurring at the server on either a port or a port-and-
   local-address basis.

   An implementation of this table MUST use only one of the three levels
   of refinement that the indexing of this table supports for the
   entries associated with a single TN3270E server.

   The objects in this table reporting maximum, in-use, and spare LUs
   for terminals and printers presuppose an implementation where
   terminal resources and printer resources come from disjoint,
   dedicated pools.  An implementation where resources for the two types
   of LUs come from a single shared pool should return the following
   values:

   o   maximum:  maximum size of the shared pool
   o   in-use:   number currently in use as this type of LU
   o   spare:    maximum - (terminal in-use + printer in-use)

3.2  TN3270E Server Resource Configuration

   The following three tables provide for configuration of resources at
   a TN3270E server:

   o   tn3270eClientGroupTable
   o   tn3270eResPoolTable
   o   tn3270eClientResMapTable

   tn3270eClientGroupTable and tn3270eResPoolTable enable
   implementations to define groupings of both client addresses and
   resource pools for mapping client addresses to resources.  The
   tn3270eClientResMapTable provides a mapping from a client group to a
   resource pool.








White & Moore               Standards Track                     [Page 7]

RFC 2561                TN3270E Using SMIv2 MIB               April 1999


3.3  Resource Name / Client Address Mappings

   The TN3270E-MIB contains three tables for mapping resource names to
   client addresses, and client addresses to resource names:

   o   tn3270eSnaMapTable
   o   tn3270eResMapTable
   o   tn3270eTcpConnTable

3.3.1  tn3270eSnaMapTable

   The tn3270eSnaMapTable is a read-only table that maps a secondary
   LU's SNA network name to the name by which it is known locally at the
   TN3270E server.  For correlation with data from the SNA network, the
   name of the associated primary LU also appears in a
   tn3270eSnaMapEntry.  An entry in this table is created when the
   Activate LU (ACTLU) request carrying the SNA network name of the SLU
   is received from the SSCP.  The entry is deleted when the SLU is
   deactivated.

   A TN3270E server provides a client with access to an SNA application
   by associating a TCP connection from the client with an SNA secondary
   LU (SLU) at the server.  This SLU in turn has an SNA session with a
   primary LU (PLU) running on an SNA host.  This PLU represents the
   application with which the client is communicating.  The TN3270E-MIB
   includes two tables for mapping back and forth among the SNA name
   identifying the PLU, the SNA name identifying the SLU, and the TCP
   connection with the client.

   In order to understand how these name mappings work, it is necessary
   to understand a subtlety involving the names of the SLUs at the
   TN3270E server:  these names are often different from the names by
   which the SLUs are known in the rest of the SNA network.  In the
   TN3270E-MIB, these two types of SLU names are termed "local names"
   and "SSCP-supplied names"; the latter term indicates that the name by
   which the SLU is known in the SNA network comes to the TN3270E server
   from the SNA System Services Control Point.

   SSCPs don't always send SLU names down to secondary LUs; in some
   cases this capability must be turned on.  In the case of SLUs served
   by a Dependent LU Requester (DLUR), an SSCP always sends SLU names to
   the DLUR.  It is necessary, however, to enable the DLUR's PU/LU
   Network Name Forwarding function, so that it forwards the SLU names
   it receives from the SSCP down to the PUs that it serves.







White & Moore               Standards Track                     [Page 8]

RFC 2561                TN3270E Using SMIv2 MIB               April 1999


   For SLUs associated with an SNA type 2.0 node (or with a boundary-
   function-attached type 2.1 node) not served by a DLUR, inclusion of
   SLU names on ACTLU must be enabled explicitly at the SSCP via local
   configuration.

3.3.2  tn3270eResMapTable

   The tn3270eResMapTable is a read-only table that maps a resource name
   to a client's address.  An entry in this table is created when a TCP
   connection is received by a TN3270E server and mapped to a resource.
   The entry is deleted when the resource-to-address association is no
   longer valid.

3.3.3  tn3270eTcpConnTable

   The TCP Connection Table is currently defined by RFC 2012 (Refer to
   reference [20], TCP-MIB Definitions).  It contains the following
   objects:

   o   tcpConnState (INTEGER)
   o   tcpConnLocalAddress (IpAddress)
   o   tcpConnLocalPort (INTEGER)
   o   tcpConnRemAddress (IpAddress)
   o   tcpConnRemPort (INTEGER)

   It is indexed by: tcpConnLocalAddress, tcpConnLocalPort,
   tcpConnRemAddress, and tcpConnRemPort.

   The tn3270eTcpConnTable contains objects for keeping a list of the
   current set of TN3270 and TN3270E sessions at a TN3270E server.  The
   relationship between the tcpConnTable and the Tn3270eTcpConnTable is
   not one-to-one, since the tn3270eTcpConnTable contains information
   pertaining only to TN3270(E) sessions.

   The tn3270eTcpConnTable has a different indexing structure from that
   of the tcpConnTable.  Instead of using IpAddress objects,
   Tn3270eAddress and IANATn3270eAddrType object pairs are used to
   specify client addresses (both local and remote).  This enables
   support of IPv6 addresses.  In addition, the remote address pair
   precedes the local address pair in the index clause, in order to
   enable a GET-NEXT operation using only the remote address pair.

3.4  Advisory Spin Lock Usage

   Within the TN3270E-MIB, tn3270eConfSpinLock is defined as an advisory
   lock that allows cooperating TN3270E-MIB applications to coordinate
   their use of the tn3270eSrvrConfTable, the tn3270eSrvrPortTable, the
   tn3270eClientGroupTable, the tn3270eResPoolTable, and the



White & Moore               Standards Track                     [Page 9]

RFC 2561                TN3270E Using SMIv2 MIB               April 1999


   tn3270eClientResMapTable.  When creating a new entry or altering an
   existing entry in any of these tables, an application SHOULD make use
   of tn3270eConfSpinLock to serialize application changes or additions.
   Since this is an advisory lock, its use by management applications
   SHALL NOT be enforced by agents.  Agents MUST, however, implement the
   tn3270eConfSpinLock object.

3.5  Row Persistence

   The following tables enable remote creation of their entries by
   including RowStatus objects:

   o   tn3270eSrvrConfTable
   o   tn3270eSrvrPortTable
   o   tn3270eClientGroupTable
   o   tn3270eResPoolTable
   o   tn3270eClientResMapTable

   An implementation SHOULD NOT retain SNMP-created entries in these
   tables across reIPLs (Initial Program Loads) of the corresponding
   TN3270E server, since management applications need to see consistent
   behavior with respect to the persistence of the table entries that
   they create.

   It is expected that local, implementation-dependent configuration
   information will be used to define the initial and persistent
   configurations for TN3270E server usage.  Thus it is not necessary to
   enable persistence of table entries by adding StorageType (refer to
   RFC 1903 [6]) objects to these tables.

3.6  IANA Considerations

   The tn3270eSrvrFunctionsSupported, tn3270eTcpConnFunctions,
   tn3270eTcpConnClientIdFormat, and tn3270eTcpConnLogInfo objects, as
   well as a number of objects identifying various address types,
   resource types, and device types, use textual conventions imported
   from the IANATn3270eTC-MIB.  The purpose of defining these textual
   conventions in a separate MIB module is to allow additional values to
   be defined without having to issue a new version of this document.
   The Internet Assigned Numbers Authority (IANA) is responsible for the
   assignment of all Internet numbers, including various SNMP-related
   numbers; it will administer the values associated with these textual
   conventions.

   The rules for additions or changes to the IANATn3270eTC-MIB are
   outlined in the DESCRIPTION clause associated with its MODULE-
   IDENTITY statement.




White & Moore               Standards Track                    [Page 10]

RFC 2561                TN3270E Using SMIv2 MIB               April 1999


   The current version of the IANATn3270eTC-MIB can be accessed from the
   IANA home page at: "http://www.iana.org/".

4.0  Definitions

  TN3270E-MIB DEFINITIONS ::= BEGIN

  IMPORTS
      MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, TimeTicks,
      IpAddress, Counter32, Gauge32, Counter64
          FROM SNMPv2-SMI
      TEXTUAL-CONVENTION, RowStatus, TestAndIncr, DateAndTime,
      TimeStamp
          FROM SNMPv2-TC
      MODULE-COMPLIANCE, OBJECT-GROUP
          FROM SNMPv2-CONF
      snanauMIB
          FROM SNA-NAU-MIB
      Utf8String
          FROM SYSAPPL-MIB
      SnmpAdminString
          FROM SNMP-FRAMEWORK-MIB
      IANATn3270eAddrType, IANATn3270eAddress,
      IANATn3270eClientType, IANATn3270Functions,
      IANATn3270ResourceType, IANATn3270DeviceType,
      IANATn3270eLogData
          FROM IANATn3270eTC-MIB;

    tn3270eMIB MODULE-IDENTITY
        LAST-UPDATED "9807270000Z" -- July 27, 1998
        ORGANIZATION "TN3270E Working Group"
        CONTACT-INFO
            "Kenneth White ([e-mail])
             IBM Corp. - Dept. BRQA/Bldg. 501/G114
             P.O. Box 12195
             3039 Cornwallis
             RTP, NC 27709-2195
             USA

             Robert Moore ([e-mail])
             IBM Corp. - Dept. BRQA/Bldg. 501/G114
             P.O. Box 12195
             3039 Cornwallis
             RTP, NC 27709-2195
             USA
             [phone]"
        DESCRIPTION
            "This module defines a portion of the management



White & Moore               Standards Track                    [Page 11]

RFC 2561                TN3270E Using SMIv2 MIB               April 1999


            information base (MIB) for managing TN3270E servers."
        REVISION  "9807270000Z" -- July 27, 1998
        DESCRIPTION
            "RFC nnnn (Proposed Standard)" -- RFC Editor to fill in
        ::= { snanauMIB 8 }

  -- Textual Conventions

  SnaResourceName ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
          "The textual convention for defining an SNA resource
           name. A fully qualified SNA resource name, consisting
           of a 1 to 8 character network identifier (NetId), a
           period ('.'), and a 1 to 8 character resource name
           (ResName).

           The NetId and ResName are constructed from the
           uppercase letters 'A' - 'Z' and the numerics '0' - '9',
           all encoded in ASCII, with the restriction that the
           first character of each must be a letter.  Blanks are
           not allowed.

           Earlier versions of SNA permitted three additional
           characters in NetIds and ResNames:  '#', '@', and '$'.
           While this use of these characters has been retired,
           a Management Station should still accept them for
           backward compatibility.

           Note: This Textual Convention is not subject to
           internationalization, and does not use the character
           encodings used by the Utf8String Textual Convention."
      SYNTAX     OCTET STRING (SIZE(0..17))

  Tn3270eTraceData ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
          "An octet string representing trace data from the
          Telnet half of a TN3270E session, from the SNA half,
          or from both.  The octet string contains a sequence
          of trace elements, with the trace elements in the
          string ordered from earliest to latest.

          Each trace element has the following form:

                  +---+---+----+----------------------+
                  !length !type!data                  !
                  +---+---+----+----------------------+