rfc2166.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                     D. Bryant
Request for Comments: 2166                                3Com Corp
Category: Informational                                 P. Brittain
                                               Data Connection Ltd.
                                                          June 1997

                      APPN Implementer's Workshop
                         Closed Pages Document

                         DLSw v2.0 Enhancements

Status of this Memo

This memo provides information for the Internet community.  This memo
does not specify an Internet standard of any kind.  Distribution of
this memo is unlimited.

Abstract

   This document specifies

   - a set of extensions to RFC 1795 designed to improve the scalability
     of DLSw
   - clarifications to RFC 1795 in the light of the implementation
     experience to-date.

   It is assumed that the reader is familiar with DLSw and RFC 1795.  No
   effort has been made to explain these existing protocols or
   associated terminology.

   This document was developed in the DLSw Related Interest Group (RIG)
   of the APPN Implementers Workshop (AIW). If you would like to
   participate in future DLSw discussions, please subscribe to the DLSw
   RIG mailing lists by sending a mail to [e-mail]
   specifying 'subscribe aiw-dlsw' as the body of the message.

Table of Contents

   1. INTRODUCTION ................................................    3
   2. HALT REASON CODES............................................    3
   3. SCOPE OF SCALABILITY ENHANCEMENTS............................    4
   4. OVERVIEW OF SCALABILITY ENHANCEMENTS.........................    6
   5. MULTICAST GROUPS AND ADDRESSING..............................    7
   5.1 USING MULTICAST GROUPS......................................    8
   5.2 DLSW MULTICAST ADDRESSES....................................    8
   6. DLSW MESSAGE TRANSPORTS......................................    8
   6.1 TCP/IP CONNECTIONS ON DEMAND................................    9
    6.1.1 TCP CONNECTIONS ON DEMAND RACE CONDITIONS................    9



Bryant & Brittain            Informational                      [Page 1]

RFC 2166              APPN Implementer's Workshop             June 1997


   6.2 SINGLE SESSION TCP/IP CONNECTIONS...........................    9
    6.2.1 EXPEDITED SINGLE SESSION TCP/IP CONNECTIONS..............   10
     6.2.1.1 TCP PORT NUMBERS......................................   10
     6.2.1.2 TCP CONNECTION SETUP..................................   10
     6.2.1.3 SINGLE SESSION SETUP RACE CONDITIONS..................   10
     6.2.1.4 TCP CONNECTIONS WITH NON-MULTICAST CAPABLE DLSW PEERS.   11
   6.3 UDP DATAGRAMS...............................................   12
    6.3.1 VENDOR SPECIFIC FUNCTIONS OVER UDP.......................   12
    6.3.2 UNICAST UDP DATAGRAMS....................................   12
    6.3.3 MULTICAST UDP DATAGRAMS..................................   13
   6.4 UNICAST UDP DATAGRAMS IN LIEU OF IP MULTICAST...............   13
   6.5 TCP TRANSPORT...............................................   14
   7. MIGRATION SUPPORT............................................   14
   7.1 CAPABILITIES EXCHANGE.......................................   14
   7.2 CONNECTING TO NON-MULTICAST CAPABLE NODES...................   15
   7.3 COMMUNICATING WITH MULTICAST CAPABLE NODES..................   15
   8. SNA SUPPORT..................................................   16
   8.1 ADDRESS RESOLUTION..........................................   16
   8.2 EXPLORER FRAMES.............................................   16
   8.3 CIRCUIT SETUP...............................................   17
   8.4 EXAMPLE SNA SSP MESSAGE SEQUENCE............................   17
   8.5 UDP RELIABILITY.............................................   19
    8.5.1 RETRIES..................................................   19
   9. NETBIOS......................................................   20
   9.1 ADDRESS RESOLUTION..........................................   21
   9.2 EXPLORER FRAMES.............................................   21
   9.3 CIRCUIT SETUP...............................................   21
   9.4 EXAMPLE NETBIOS SSP MESSAGE SEQUENCE........................   22
   9.5 MULTICAST RELIABILITY AND RETRIES...........................   24
   10. SEQUENCING..................................................   24
   11. FRAME FORMATS...............................................   25
   11.1 MULTICAST CAPABILITIES CONTROL VECTOR......................   25
    11.1.1 DLSW CAPABILITIES NEGATIVE RESPONSE.....................   26
   11.2 UDP PACKETS................................................   26
   11.3 VENDOR SPECIFIC UDP PACKETS................................   27
   12. COMPLIANCE STATEMENT........................................   28
   13. SECURITY CONSIDERATIONS.....................................   29
   14. ACKNOWLEDGEMENTS............................................   29
   15. AUTHORS' ADDRESSES..........................................   30
   16. APPENDIX - CLARIFICATIONS TO RFC 1795.......................   31











Bryant & Brittain            Informational                      [Page 2]

RFC 2166              APPN Implementer's Workshop             June 1997


   1. Introduction

   This document defines v2.0 of Data Link Switching (DLSw) in the form
   of a set of enhancements to RFC 1795. These enhancements are designed
   to be fully backward compatible with existing RFC 1795
   implementations. As a compatible set of enhancements to RFC 1795,
   this document does not replace or supersede RFC 1795.

   The bulk of these enhancements address scalability issues in DLSw
   v1.0.  Reason codes have also been added to the HALT_DL and
   HALT_DL_NOACK SSP messages in order to improve the diagnostic
   information available.

   Finally, the appendix to this document lists a number of
   clarifications to RFC 1795 where the implementation experience to-
   date has shown that the original RFC was ambiguous or unclear. These
   clarifications should be read alongside RFC 1795 to obtain a full
   specification of the base v1.0 DLSw standard.

2. HALT Reason codes

   RFC 1795 provides no mechanism for a DLSw to communicate to its peer
   the reason for dropping a circuit.  DLSw v2.0 adds reason code fields
   to the HALT_DL and HALT_DL_NOACK SSP messages to carry this
   information.

   The reason code is carried as 6 bytes of data after the existing SSP
   header.  The format of these bytes is as shown below.

   Byte       Description
   0-1        Generic HALT reason code in byte normal format

   2-5        Vendor-specific detailed reason code

   The generic HALT reason code takes one of the following decimal
   values (which are chosen to match the disconnect reason codes
   specified in the DLSw MIB).

   1 - Unknown error
   2 - Received DISC from end-station
   3 - Detected DLC error with end-station
   4 - Circuit-level protocol error (e.g., pacing)
   5 - Operator-initiated (mgt station or local console)

   The vendor-specific detailed reason code may take any value.






Bryant & Brittain            Informational                      [Page 3]

RFC 2166              APPN Implementer's Workshop             June 1997


   All V2.0 DLSws must include this information on all HALT_DL and
   HALT_DL_NOACK messages sent to v2.0 DLSw peers.  For backwards
   compatibility with RFC 1795, DLSw V2.0 implementations must also
   accept a HALT_DL or HALT_DL_NOACK message received from a DLSw peer
   that does not carry this information (i.e. RFC 1795 format for these
   SSP messages).

3. Scope of Scalability Enhancements

   The DLSw Scalability group of the AIW identified a number of
   scalability issues associated with existing DLSw protocols as defined
   in RFC 1795:

   - Administration

     RFC 1795 implies the need to define the transport address of all
     DLSw peers at each DLSw.  In highly meshed situations (such as
     those often found in NetBIOS networks), the resultant
     administrative burden is undesirable.

   - Address Resolution

     RFC 1795 defines point to point TCP (or other reliable transport
     protocol) connections between DLSw peers.  When attempting to
     discover the location of an unknown resource, a DLSw sends an
     address resolution packet to each DLSw peer over these connections.
     In highly meshed configurations, this can result in a very large
     number of packets in the transport network.  Although each packet
     is sent individually to each DLSw peer, they are each identical in
     nature.  Thus the transport network is burdened with excessive
     numbers of identical packets.  Since the transport network is most
     commonly a wide area network, where bandwidth is considered a
     precious resource, this packet duplication is undesirable.

   - Broadcast Packets

     In addition to the address resolution packets described above, RFC
     1795 also propagates NetBIOS broadcast packets into the transport
     network.  The UI frames of NetBIOS are sent as LAN broadcast
     packets.  RFC 1795 propagates these packets over the point to point
     transport connections to each DLSw peer.  In the same manner as
     above, this creates a large number of identical packets in the
     transport network, and hence is undesirable.  Since NetBIOS UI
     frames can be sent by applications, it is difficult to predict or
     control the rate and quantity of such traffic.  This compounds the
     undesirability of the existing RFC 1795 propagation method for
     these packets.




Bryant & Brittain            Informational                      [Page 4]

RFC 2166              APPN Implementer's Workshop             June 1997


   - TCP (transport connection) Overhead

     As defined in RFC 1795, each DLSw maintains a transport connection
     to its DLSw peers.  Each transport connection guarantees in order
     packet delivery.   This is accomplished using acknowledgment and
     sequencing algorithms which require both CPU and memory at the DLSw
     endpoints in direct proportion to the number transport connections.
     The DLSw Scalability group has identified two scenarios where the
     number of transport connections can become significant resulting in
     excessive overhead and corresponding equipment costs (memory and
     CPU).   The first scenario is found in highly meshed DLSw
     configurations where the number of transport connections
     approximates n2 (where n is the number of DLSw peers).  This is
     typically found in DLSw networks supporting NetBIOS.  The second
     scenario is found  in networks  where many remote locations
     communicate to few central sites.  In this case, the central sites
     must support n transport connections  (where n is the number of
     remote sites).    In both scenarios the resultant transport
     connection overhead is considered undesirable depending upon the
     value of n.

   - LLC2 overhead

     RFC 1795 specifies that each DLSw provides local termination for
     the LLC2 (SDLC or other SNA reliable data link  protocol) sessions
     traversing the SSP.   Because these reliable data links provide
     guaranteed in order packet delivery, the memory and CPU overhead of
     maintaining these connections can also become significant.   This
     is particularly undesirable in the second scenario described above,
     because the number of reliable connections maintained at the
     central site is the aggregate of the connections maintained at each
     remote site.

   It is not the intent of this document to address all the undesirable
   scalability issues associated with RFC 1795.  This paper identifies
   protocol enhancements to RFC 1795 using the inherent multicast
   capabilities of the underlying transport network to improve the
   scalability of RFC 1795.  It is believed that the enhancements
   defined, herein, address many of the issues identified above, such as
   administration, address resolution, broadcast packets, and, to a
   lesser extent, transport overhead.  This paper does not address LLC2
   overhead.  Subsequent efforts by the AIW and/or DLSw Scalability
   group may address the unresolved scalability issues.








Bryant & Brittain            Informational                      [Page 5]

RFC 2166              APPN Implementer's Workshop             June 1997


   While it is the intent of this paper to accommodate all transport
   protocols as best as is possible, it is recognized that the multicast
   capabilities of many protocols is not yet well defined, understood,
   or implemented. Since TCP is the most prevalent DLSw transport
   protocol in use today, the DLSw Scalability group has chosen to focus
   its definition around IP based multicast services. This document only
   addresses the implementation detail of IP based multicast services.

   This proposal does not consider the impacts of IPv6 as this was
   considered too far from widespread use at the time of writing.

4. Overview of Scalability Enhancements

   This paper describes the use of multicast services within the
   transport network to improve the scalability of DLSw based
   networking.  There are only a few main components of this proposal:

   - Single session TCP connections

     RFC 1795 defines a negotiation protocol for DLSw peers to choose
     either two unidirectional or one bi-directional TCP connection.
     DLSws implementing the enhancements described in this document must
     support and use(whenever required and possible)a single bi-
     directional TCP connection between DLSw peers. That is to say that
     the single tunnel negotiation support of RFC 1795 is a prerequisite
     function to this set of enhancements. Use of two unidirectional TCP
     connections is only allowed (and required)for migration purposes
     when communicating with DLSw peers that do not implement these
     enhancements.

     This document also specifies a faster method for bringing up a
     single TCP connection between two DLSw peers than the negotiation
     used in RFC 1795.  This faster method, detailed in section 6.2.1,
     must be used where both peers are known to support DLSw v2.0.