rfc2562.txt

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

   Section 3.4, Timestamp Calculation, provides specifics on when in the
   sequence of flows between a TN3270E client and its target SNA host a
   TN3270E server takes the required timestamps.  In addition, it
   provides information on how a TN3270 TIMING-MARK request/response
   flow can be used instead of DR for approximating IP network transit
   times.

   The following figure adds a TN3270E server between the client, in
   this case a TN3270E client and the target SNA host:

           ------------------------------------------------
           |                                              |
           | Client            TN3270E           Target   |
           |                    Server          SNA Host  |
           |                   Timestamps                 |
           |                                              |
           | <---IP Network-------><---SNA Network--->    |
           |                                              |
           |      request         D                       |
           | ------------------------------------------>  |
           |      reply(DR)       E                    |  |
           | <----------------------------------------<   |
           | |    +/-RSP          F                       |
           |  >-------------------- - - - - - - - - - >   |
           |                                              |
           ------------------------------------------------

   A TN3270E server can save timestamp D when it receives a client
   request, save timestamp E when the target SNA host replies, and save
   timestamp F when the client responds to the definite response request
   that flowed with the reply.  It doesn't matter whether the target SNA
   host requested a definite response on its reply:  if it didn't, the
   TN3270E server makes the request on its own, to enable it to produce
   timestamp F.  In this case the TN3270E server does not forward the
   response to the target SNA host, as the dotted line in the figure
   indicates.

   Because it is a special case, a transaction in which a target SNA
   host returns an UNBIND in response to a client's request, and the
   TN3270E server forwards the UNBIND to the client, is not included in
   any response time calculations.






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


   In order to generate timestamp F, a TN3270E server MUST insure that
   the transaction specifies DR, and that the TN3270E RESPONSES function
   has been negotiated between itself and the client.  Negotiation of
   the TN3270E RESPONSES function occurs during the client's TN3270E
   session initialization.  The TN3270E servers that the authors are
   aware of do request the RESPONSES function during client session
   initialization.  TN3270E clients either automatically support the
   RESPONSES function, or can be configured during startup to support
   it.

   Using timestamps D, E, and F the following response times can be
   calculated by a TN3270E server:

   o   Total Response time:     Timestamp F - Timestamp D
   o   IP Network Transit Time: Timestamp F - Timestamp E

   Just as in the SNA case presented above, these response times are
   also approximations, since the final +/- RSP from the client is being
   substituted for the request from the client that began the
   transaction.

   The MIB provides an object, tn3270eRtCollCtlType, to control several
   aspects of response time data collection.  One of the available
   options in setting up a response time collection policy is to
   eliminate the IP-network component altogether.  This might be done
   because it is determined either that the additional IP network
   traffic would not be desirable, or that the IP-network component of
   the overall response times is not significant.

   Excluding the IP-network component from response times also has an
   implication for the way in which response time data is aggregated.  A
   TN3270E server may find that some of its clients simply don't support
   any of the functions necessary for the server to calculate the IP-
   network component of response times.  For these clients, the most
   that the server can calculate is the SNA-network component of their
   overall response times; the server records this SNA-network component
   as the TOTAL response time each of these clients' transactions.  If a
   response time collection is aggregating data from a number of
   clients, some of which have the support necessary for including the
   IP-network component in their total response time calculations, and
   some of which do not, then the server aggregates the data differently
   depending on whether the collection has been defined to include or
   exclude the IP-network component:

   o  If the IP-network component is included, then transactions for the
      clients that don't support calculation of the IP-network component
      of their response times are excluded from the aggregation
      altogether.



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


   o  If the IP-network component is excluded, then total response times
      for ALL clients include only the SNA-network component, even
      though the server could have included an IP-network component in
      the overall response times for some of these clients.  The server
      does this by setting timestamp F, which marks the end of a
      transaction's total response time, equal to timestamp E, the end
      of the transaction's SNA-network component.

   The principle here is that all the transactions contributing their
   response times to an aggregated value MUST make the same
   contribution.  If the aggregation specifies that an IP-network
   component MUST be included in the aggregation's response times, then
   transactions for which an IP-network component cannot be calculated
   aren't included at all.  If the aggregation specifies that an IP-
   network component is not to be included, then only the SNA-network
   component is used, even for those transactions for which an IP-
   network component could have been calculated.

   There is one more complication here:  the MIB allows a management
   application to enable or disable dynamic definite responses for a
   response time collection.  Once again the purpose of this option is
   to give the network operator control over the amount of traffic
   introduced into the IP network for response time data collection.  A
   DYNAMIC definite response is one that the TN3270E server itself adds
   to a reply, in a transaction for which the SNA application at the
   target SNA host did not specify DR in its reply.  When the +/-RSP
   comes back from the client, the server uses this response to
   calculate timestamp F, but then it does not forward the response on
   to the SNA application (since the application is not expecting a
   response to its reply).

   The dynamic definite responses option is related to the option of
   including or excluding the IP-network component of response times
   (discussed above) as follows:

   o  If the IP-network component is excluded, then there is no reason
      for enabling dynamic definite responses: the server always sets
      timestamp F equal to timestamp E, so the additional IP-network
      traffic elicited by a dynamic definite response would serve no
      purpose.

   o  If the IP-network component is included, then enabling dynamic
      definite responses causes MORE transactions to be included in the
      aggregated response time values:

      -  For clients that do not support sending of responses, timestamp
         F can never be calculated, and so their transactions are never
         included in the aggregate.



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


      -  For clients that support sending of responses, timestamp F will
         always be calculated for transactions in which the host SNA
         application specifies DR in its reply, and so these
         transactions will always be included in the aggregate.

      -  For clients that support sending of responses, having dynamic
         definite responses enabled for a collection results in the
         inclusion of additional transactions in the aggregate:
         specifically, those for which the host SNA application did not
         specify DR in its reply.

   A TN3270E server also has the option of substituting TIMING-MARK
   processing for definite responses in calculating the IP-network
   component of a transaction's response time.  Once again, there is no
   reason for the server to do this if the collection has been set up to
   exclude the IP-network component altogether in computing response
   times.

   The MIB is structured to keep counts and averages for total response
   times (F - D) and their IP-network components (F - E).  A management
   application can obviously calculate from these two values an average
   SNA-network component (E - D) for the response times.  This SNA-
   network component includes the SNA node processing time at both the
   TN3270E server and at the target application.

   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 an 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) requirements.

   If a host TN3270E server is in the same SNA host as the target
   application, then the SNA-network component of a transaction's
   response time will approximately equal the host transit time (B - A)
   described previously.  A host TN3270E server implementation can,
   however, typically support the establishment of sessions to target
   applications in SNA hosts remote from itself.  In this case the SNA-
   network component of the response time equals the actual SNA-network
   transit time plus two host transit times.







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


3.3  Correlating TN3270E Server and Host Response Times

   It is possible that response time data is collected from TN3270E
   servers at the same time as a management application is monitoring
   the SNA sessions at a host.  For example, a management application
   can be monitoring a secondary logical unit (SLU) while retrieving
   data from a TN3270E server.  Consider the following figure:

           ------------------------------------------------
           |                                              |
           | Client            TN3270E            Target  |
           |                    Server           SNA Host |
           |                   Timestamps         (PLU)   |
           |                    (SLU)           Timestamps|
           | <---IP Network-------><---SNA Network--->    |
           |                                              |
           |      request         D                 A     |
           | ------------------------------------------>  |
           |      reply(DR)       E                 B  |  |
           | <----------------------------------------<   |
           | |    +/-RSP          F                 C     |
           |  >-------------------------------------->    |
           |                                              |
           ------------------------------------------------

   The following response times are available:

   o   Target SNA host transit time:         Timestamp B - Timestamp A
   o   Target SNA host network transit time: Timestamp C - Timestamp B
   o   TN3270E server total response time:   Timestamp F - Timestamp D
   o   TN3270E server IP-network component:  Timestamp F - Timestamp E

   The value added by the TN3270E server in this situation is its
   approximation of the IP-network component of the overall response
   time.  The IP-network component can be subtracted from the total
   network transit time (which can be captured at an SSCP monitoring SNA
   traffic from/to the SLU) to see the actual SNA versus IP network
   transit times.

   The MIB defined by this memo does not specifically address
   correlation of the data it contains with response time data collected
   by direct monitoring of SNA resources:  its focus is exclusively
   response time data collection from a TN3270E server perspective.  It
   has, however, in conjunction with the TN3270E-MIB [10], been
   structured to provide the information necessary for correlation
   between TN3270E server-provided response time information and that
   gathered from directly monitoring SNA resources.




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


   A management application attempting to correlate SNA resource usage
   to Telnet clients can monitor either the tn3270eResMapTable or the
   tn3270eTcpConnTable to determine resource-to-client address mappings.
   Both of these tables are defined by the TN3270E-MIB [10].  Another
   helpful table is the tn3270eSnaMapTable, which provides a mapping
   between SLU names as they are known at the SSCP (VTAM) and their
   local names at the TN3270E server.  Neither the
   tn3270eClientGroupTable, the tn3270eResPoolTable, nor the
   tn3270eClientResMapTable from the TN3270E-MIB can be used for
   correlation, since the mappings defined by these tables can overlap,
   and may not provide one-to-one mappings.

3.4  Timestamp Calculation