rfc2562.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,449 行 · 第 1/5 页

Network Working Group                                          K. White
Request for Comments: 2562                                    IBM Corp.
Category: Standards Track                                      R. Moore
                                                              IBM Corp.
                                                             April 1999


            Definitions of Protocol and Managed Objects for
              TN3270E Response Time Collection Using SMIv2
                            (TN3270E-RT-MIB)

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.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This memo defines the protocol and the Management Information Base
   (MIB) for performing response time data collection on TN3270 and
   TN3270E sessions by a TN3270E server.  The response time data
   collected by a TN3270E server is structured to support both
   validation of service level agreements and performance monitoring of
   TN3270 and TN3270E Sessions.  This MIB has as a prerequisite the
   TN3270E-MIB, reference [20].

   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.

Table of Contents

   1.0  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
   2.0  The SNMP Network Management Framework   . . . . . . . . . .  2
   3.0  Response Time Collection Methodology  . . . . . . . . . . .  3
   3.1  General Response Time Collection  . . . . . . . . . . . . .  3
   3.2  TN3270E Server Response Time Collection   . . . . . . . . .  5
   3.3  Correlating TN3270E Server and Host Response Times  . . . . 10
   3.4  Timestamp Calculation   . . . . . . . . . . . . . . . . . . 11
     3.4.1  DR Usage  . . . . . . . . . . . . . . . . . . . . . . . 12



White & Moore               Standards Track                     [Page 1]

RFC 2562                     TN3270E-RT-MIB                   April 1999


     3.4.2  TIMING-MARK Usage   . . . . . . . . . . . . . . . . . . 13
   3.5  Performance Data Modelling  . . . . . . . . . . . . . . . . 15
     3.5.1  Averaging Response Times  . . . . . . . . . . . . . . . 15
     3.5.2  Response Time Buckets   . . . . . . . . . . . . . . . . 18
   4.0  Structure of the MIB  . . . . . . . . . . . . . . . . . . . 19
   4.1  tn3270eRtCollCtlTable   . . . . . . . . . . . . . . . . . . 19
   4.2  tn3270eRtDataTable  . . . . . . . . . . . . . . . . . . . . 23
   4.3  Notifications   . . . . . . . . . . . . . . . . . . . . . . 24
   4.4  Advisory Spin Lock Usage  . . . . . . . . . . . . . . . . . 26
   5.0  Definitions   . . . . . . . . . . . . . . . . . . . . . . . 26
   6.0  Security Considerations   . . . . . . . . . . . . . . . . . 45
   7.0  Intellectual Property   . . . . . . . . . . . . . . . . . . 45
   8.0  Acknowledgments   . . . . . . . . . . . . . . . . . . . . . 46
   9.0  References  . . . . . . . . . . . . . . . . . . . . . . . . 46
   10.0  Authors' Addresses   . . . . . . . . . . . . . . . . . . . 48
   11.0  Full Copyright Statement   . . . . . . . . . . . . . . . . 49

1.0  Introduction

   This document is a product of the TN3270E Working Group.  It defines
   a protocol and a MIB module to enable a TN3270E server to collect and
   keep track of response time data for both TN3270 and TN3270E clients.
   Basis for implementing this MIB:

   o   TN3270E-MIB, Base Definitions of Managed Objects for TN3270E
       Using SMIv2 [20]

   o   TN3270E RFCs

   o   Telnet Timing Mark Option RFC [17].

   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
   [23].

2.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



White & Moore               Standards Track                     [Page 2]

RFC 2562                     TN3270E-RT-MIB                   April 1999


       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.

3.0  Response Time Collection Methodology

   This section explains the methodology and approach used by the MIB
   defined by this memo for response time data collection by a TN3270E
   server.

3.1  General Response Time Collection

   Two primary methods exist for measuring response times in SNA
   networks:

   o   The Systems Network Architecture Management Services (SNA/MS)
       Response Time Monitoring (RTM) function.



White & Moore               Standards Track                     [Page 3]

RFC 2562                     TN3270E-RT-MIB                   April 1999


   o   Timestamping using definite response flows.

   This memo defines an approach using definite responses to timestamp
   the flows between a client and its TN3270E server, rather than by use
   of the RTM method. Extensions to the SNA/MS RTM flow were considered,
   but this approach was deemed unsuitable since not all TN3270E server
   implementations have access to their underlying SNA stacks.  The RTM
   concepts of keeping response time buckets for service level
   agreements and of interval-based response time collection for
   performance monitoring are preserved in the MIB module defined in
   this memo.

   As mentioned, this memo focuses on using definite responses to
   timestamp the flows between a client and its TN3270E server for
   generating performance data.  Use of a definite response flow
   requires that the client supports TN3270E with the RESPONSES function
   negotiated.  The TN3270 TIMING-MARK option can be used instead of
   definite response for supporting TN3270 clients or TN3270E clients
   that don't support RESPONSES.  This document focuses first on
   defining the protocol and methods for generating performance data
   using definite responses, and then describes how the TIMING-MARK
   option can be used instead of definite response.

   In an SNA network, a transaction between a client Logical Unit (LU)
   and a target host in general looks as follows:

           ------------------------------------------------
           |                                              |
           | Client LU                    Target SNA Host |
           |                                              |
           |                               Timestamps     |
           |              request              A          |
           | ----------------------------------------->   |
           |              reply(DR)            B      |   |
           | <---------------------------------------<    |
           | |            +/-RSP               C          |
           | >--------------------------------------->    |
           |                                              |
           | DR:     Definite Response requested          |
           | +/-RSP: Definite Response                    |
           |                                              |
           ------------------------------------------------

   This transaction is a simple one, and is being used only to
   illustrate how timestamping at a target SNA host can be used to
   generate response times.  An IBM redbook [12] provides a more
   detailed description of response time collection for a transaction of
   this type.  Note that for the purpose of calculating an approximation



White & Moore               Standards Track                     [Page 4]

RFC 2562                     TN3270E-RT-MIB                   April 1999


   for network transit time, it doesn't matter if the response is
   positive or negative.  Two response time values are typically
   calculated:

   o   Host Transit Time:    Timestamp B - Timestamp A
   o   Network Transit Time: Timestamp C - Timestamp B

   Network transit time is an approximation for the amount of time that
   a transaction requires to flow across a network, since the response
   flow is being substituted for the request flow at the start of the
   transaction.  Network transit time, timestamp C - timestamp B, is the
   amount of time that the definite response request and its response
   required.  Host time, timestamp B - timestamp A, is the actual time
   that the host required to process the transaction.  Experience has
   shown that using the response flow to approximate network transit
   times is useful, and does correlate well with actual network transit
   times.

   A client SHOULD respond to a definite response request when it
   completes processing the transaction.  This is important since it
   increases the accuracy of a total response time.  Clients that
   immediately respond to a definite response request will be attributed
   with lower total response times then those that actually occurred.

   The TN3270E-RT-MIB describes a method of collecting performance data
   that is not appropriate for printer (LU Type 1 or LU Type 3)
   sessions; thus collection of performance data for printer sessions is
   excluded from this MIB.  This exclusion of printer sessions is not
   considered a problem, since these sessions are not the most important
   ones for response time monitoring, and since historically they were
   excluded from SNA/MS RTM collection.  The tn3270eTcpConnResourceType
   object in a tn3270eTcpConnEntry (in the TN3270E-MIB) can be examined
   to determine if a client session is ineligible for response time data
   collection for this reason.

3.2  TN3270E Server Response Time Collection

   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.  For ease of exposition this document uses the term "IP network"
   to refer to the client-side network, since IP is by far the most
   common protocol for these networks.

   A TN3270E server can use SNA definite responses and the TN3270
   Enhancement (RFC 2355 [19]) RESPONSES function to calculate response
   times for a transaction, by timestamping when a client request



White & Moore               Standards Track                     [Page 5]

RFC 2562                     TN3270E-RT-MIB                   April 1999


   arrives at the server, when the reply arrives from the target host,
   and when the response acknowledging this reply arrives from the
   client.