rfc2166.txt

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

   - TCP connections on demand

     Two DLSw peers using these enhancements will only establish a TCP
     connection when necessary.  SSP connections to DLSw peers which do
     not implement these enhancements are assumed to be established by
     the means defined in RFC 1795.  DLSws implementing v2.0 utilize UDP
     based transport services to send address resolution packets
     (CANUREACH_ex, NETBIOS_NQ_ex, etc.).  If a positive response is
     received, then a TCP connection is only established to the
     associated DLSw peer if one does not already exist.
     Correspondingly, TCP connections are brought down when there are no
     circuits to a DLSw peer for an implementation defined period of
     time.



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


   - Address resolution through UDP

     The main thrust of this paper is to utilize non-reliable transport
     and the inherent efficiencies of multicast protocols whenever
     possible and applicable to reduce network overhead.  Accordingly,
     the address resolution protocols of SNA and NetBIOS are sent over
     the non-reliable transport of IP, namely UDP.  In addition, IP
     multicast/unicast services are used whenever address resolution
     packets must be sent to multiple destinations. This avoids the need
     to maintain TCP SSP connections between two DLSw peers when no
     circuits are active.  CANUREACH_ex and ICANREACH_ex packets can be
     sent to all the appropriate DLSw peers without the need for pre-
     configured peers or pre-established TCP/IP connections.  In
     addition, most multicast services (including TCP's MOSPF, DVMRP,
     MIP, etc.) replicate and propagate messages only as necessary to
     deliver to all multicast members.   This avoids duplication and
     excessive bandwidth consumption in the transport network.

     To further optimize the use of WAN resources, address resolution
     responses are sent in a directed fashion (i.e., unicast) via UDP
     transport whenever possible.   This avoids the need to setup or
     maintain TCP connections when they are not required.  It also
     avoids the bandwidth costs associated with broadcasting.

     Note: It is also permitted to send some address resolution traffic
     over existing TCP connections.  The conditions under which this is
     permitted are detailed in section 7.

   - NetBIOS broadcasts over UDP

     In the same manner as above, NetBIOS broadcast packets are sent via
     UDP (unicast and multicast) whenever possible and appropriate. This
     avoids the need to establish TCP connections between DLSw peers
     when there are no circuits required.   In addition, bandwidth in
     the transport network is conserved by utilizing the efficiencies
     inherent to multicast service implementation.  Details covering
     identification of these packets and proper propagation methods are
     described in section 10.

5. Multicast Groups and Addressing

   IP multicast services provides an unreliable datagram oriented
   delivery service to multiple parties. Communication is accomplished
   by sending and/or listening to specific 'multicast' addresses.  When
   a given node sends a packet to a specific address (defined to be
   within the multicast address range), the IP network (unreliably)
   delivers the packet to every node listening on that address.




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


   Thus, DLSws can make use of this service by simply sending and
   receiving (i.e., listening for) packets on the appropriate multicast
   addresses. With careful planning and implementation, networks can be
   effectively partitioned and network overhead controlled by sending
   and listening on different addresses groups.  It is not the intent of
   this paper to define or describe the techniques by which this can be
   accomplished.  It is expected that the networking industry (vendors
   and end users alike) will determine the most appropriate ways to make
   use of the functions provided by use of DLSw multicast transport
   services.

5.1 Using Multicast Groups

   The multicast addressing as described above can be effectively used
   to limit the amount of broadcast/multicast traffic in the network.
   It is not the intent of this document to describe how individual
   DLSw/SSP implementations would assign or choose group addresses.  The
   specifics of how this is done and exposed to the end user is an issue
   for the specific implementor.  In order to provide for multivendor
   interoperability and simplicity of configuration, however, this paper
   defines a single IP multicast address, 224.0.10.000, to be used as a
   default DLSw multicast address.  If a given implementation chooses to
   provide a default multicast address, it is recommended this address
   be used.  In addition, this address should be used for both
   transmitting and receiving of multicast SSP messages.  Implementation
   of a default multicast address is not, however, required.

5.2 DLSw Multicast Addresses

   For the purpose of long term interoperability, the AIW has secured a
   block of IP multicast addresses to be used with DLSw.  These
   addresses are listed below:

   Address Range        Purpose
   --------------------------------------------------------------------
   224.0.10.000         Default multicast address
   224.0.10.001-191     User defined DLSw multicast groups
   224.0.10.192-255     Reserved for future use by the DLSw RIG in DLSw
                        enhancements

6. DLSw Message Transports

   With the introduction of DLSw Multicast Protocols, SSP messages are
   now sent over two distinct transport mechanisms: TCP/IP connections
   and UDP services.  Furthermore, the UDP datagrams can be sent to two
   different kinds of IP addresses: unique IP addresses (generally
   associated with a specific DLSw), and multicast IP addresses
   (generally associated with a group of DLSw peers).



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


6.1 TCP/IP Connections on Demand

   As is the case in RFC 1795, TCP/IP connections are established
   between DLSw peers.  Unlike RFC 1795, however, TCP/IP connections are
   only established to carry reliable circuit data (i.e., LLC2 based
   circuits).  Accordingly, a TCP/IP connection is only established to a
   given DLSw peer when the first circuit to that DLSw is required
   (i.e., the origin DLSw must send a CANUREACH_CS to a target DLSw peer
   and there is no existing TCP connection between the two).  In
   addition, the TCP/IP connection is brought down an implementation
   defined amount of time after the last active (not pending) circuit
   has terminated.  In this way, the overhead associated with
   maintaining TCP connections is minimized.

   With the advent of TCP connections on demand, the activation and
   deactivation of TCP connections becomes a normal occurrence as
   opposed to the exception event it constitutes in RFC 1795.  For this
   reason, it is recommended that implementations carefully consider the
   value of SNMP traps for this condition.

6.1.1 TCP Connections on Demand Race Conditions

   Non-circuit based SSP packetsn (e.g.,CANUREACH_ex, etc.) may still be
   sent/received over TCP connections after all circuits have been
   terminated.  Taking this into account implementations should still
   gracefully terminate these TCP connections once the connection is no
   longer supporting circuits.  This may require an implementation to
   retransmit request frames over UDP when no response to a TCP based
   unicast request is received and the TCP connection is brought down.
   This is not required in the case of multicast requests as these are
   received over the multicast transport mechanism.

6.2 Single Session TCP/IP Connections

   RFC 1795 defines the use of two unidirectional TCP/IP sessions
   between any pair of DLSw peers using read port number 2065 and write
   port number 2067.  Additionally, RFC 1795 allows for implementations
   to optionally use only one bi-directional TCP/IP session.  Using one
   TCP/IP session between DLSw peers is believed to significantly
   improve the performance and scalability of DLSw protocols.
   Performance is improved because TCP/IP acknowledgments are much more
   likely to be piggy-backed on real data when TCP/IP sessions are used
   bi-directionally.  Scalability is improved because fewer TCP control
   blocks, state machines, and associated message buffers are required.
   For these reasons, the DLSw enhancements defined in this paper
   REQUIRE the use of single session TCP/IP sessions.





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


   Accordingly, DLSws implementing these enhancements must carry the TCP
   Connections Control Vector in their Capabilities Exchange.  In
   addition, the TCP Connections Control Vector must indicate support
   for 1 connection.

6.2.1 Expedited Single Session TCP/IP Connections

   In RFC 1795, single session TCP/IP connections are accomplished by
   first establishing two uni-directional TCP connections, exchanging
   capabilities, and then bringing down one of the connections.  In
   order to avoid the unnecessary flows and time delays associated with
   this process, a new single session bi-directional TCP/IP connection
   establishment algorithm is defined.

6.2.1.1 TCP Port Numbers

   DLSws implementing these enhancements will use a TCP destination port
   of 2067 (as opposed to RFC 1795 which uses 2065) for single session
   TCP connections.  The source port will be a random port number using
   the established TCP norms which exclude the possibility of either
   2065 or 2067.

6.2.1.2 TCP Connection Setup

   DLSw peers implementing these enhancements will establish a single
   session TCP connection whenever the associated peer is known to
   support this capability.  To do this, the initiating DLSw simply
   sends a TCP setup request to destination port 2067.  The receiving
   DLSw responds accordingly and the TCP three way handshake ensues.
   Once this handshake has completed, each DLSw is notified and the DLSw
   capabilities exchange ensues.  As in RFC 1795, no flows may take
   place until the capabilities exchange completes.

6.2.1.3 Single Session Setup Race Conditions

   The new expedited single session setup procedure described above
   opens up the possibility of a race condition that occurs when two
   DLSw peers attempt to setup single session TCP connections to each
   other at the same time.  To avoid the establishment of two TCP
   connections, the following rules are applied when establishing
   expedited single session TCP connections:

   1.If an inbound TCP connect indication is received on port 2067 while
     an outbound TCP connect request (on port 2067) to the same DLSw (IP
     address) is in process or outstanding, the DLSw with the higher IP
     address will close or reject the connection from the DLSw with the
     lower IP address.




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


   2.To further expedite the process, the DLSw with the lower IP address
     may choose (implementation option) to close its connection request
     to the DLSw with the higher address when this condition is
     detected.
   3.If the DLSw with the lower IP address has already sent its
     capabilities exchange request on its connection to the DLSw with
     the higher IP address, it must resend its capabilities exchange
     request over the remaining TCP connection from its DLSw peer (with
     the higher IP address).
   4.The DLSw with the higher IP address must ignore any capabilities
     exchange request received over the TCP connection to be terminated
     (the one from the DLSw with the lower IP address).

6.2.1.4 TCP Connections with Non-Multicast Capable DLSw peers

   During periods of migration, it is possible that TCP connections
   between multicast capable and non-multicast capable DLSw peers will
   occur.  It is also possible that multicast capable DLSws may attempt
   to establish TCP connections with partners of unknown capabilities
   (e.g., statically defined peers).  To handle these conditions the
   following additional rules apply to expedited single session TCP
   connection setup:

   1.If the capability of a DLSw peer is not known, an implementation
     may choose to send the initial TCP connect request to either port
     2067 (expedited single session setup) or port 2065 (standard RFC
     1795 TCP setup).
   2.If a multicast capable DLSw receives an inbound TCP connect request
     on port 2065 while processing an outbound request on 2067 to the
     same DLSw, the sending DLSw will terminate its 2067 request and
     respond as defined in RFC 1795 with an outbound 2065 request
     (standard RFC 1795 TCP setup).
   3.If a multicast capable DLSw receives an indication that the DLSw
     peer is not multicast capable (the port 2067 setup request times
     out or a port not recognized rejection is received), it will send
     another connection request using port 2065 and the standard RFC
     1795 session setup protocol.














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


6.3 UDP Datagrams

   As mentioned above, UDP datagrams can be sent two different ways:
   unicast (e.g., sent to a single unique IP address) or multicast
   (i.e., sent to an IP multicast address).  Throughout this document,
   the term UDP datagram will be used to refer to SSP messages sent over
   UDP, while unicast and multicast SSP messages will refer to the
   specific type/method of UDP packet transport.  In either case,
   standard UDP services are used to transport these packets.  In order
   to properly parse the inbound UDP packets and deliver them to the SSP
   state machines, all DLSw UDP packets will use the destination port of
   2067.

   In addition, the checksum function of UDP remains optional for DLSw
   SSP messages.  It is believed that the inherent CRC capabilities of
   all data link transports will adequately protect SSP packets during
   transmission.  And the incremental exposure to intermediate nodal
   data corruption is negligible.  For further information on UDP packet
   formats see the 揊rame Formats