rfc1795.txt

中、英文RFC文档大全打包下载完全版 .

Network Working Group                                    L. Wells, Chair
Request for Comments: 1795             Internetwork Technology Institute
Obsoletes: 1434                                        A. Bartky, Editor
Category: Informational                              Sync Research, Inc.
                                                              April 1995


             Data Link Switching: Switch-to-Switch Protocol
       AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1.0

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 RFC describes use of Data Link Switching over TCP/IP. The RFC is
   being distributed to members of the Internet community in order to
   solicit their reactions to the proposals contained in it.  While the
   issues discussed may not be directly relevant to the research
   problems of the Internet, they may be interesting to a number of
   researchers and Implementers.

   This RFC was created as a joint effort of the Advanced Peer-to-Peer
   Networking (APPN) Implementers Workshop (AIW) Data Link Switching
   (DLSw) Related Interest Group (RIG).  The APPN Implementers Workshop
   is a group sponsored by IBM and consists of representatives of member
   companies implementing current and future IBM Networking
   interoperable products. The DLSw Related Interest Group was formed in
   this forum in order to produce a single version of the Switch to
   Switch Protocol (SSP) which could be implemented by all vendors,
   which would fix documentation problems with the existing RFC 1434,
   and which would enhance and evolve the protocol to add new functions
   and features.

   This document is based on RFC 1434.  This document contains
   significant changes to RFC 1434 and therefore obsoletes that
   document.

   Any questions or comments relative to the contents of this RFC should
   be sent to the following Internet address:
   [e-mail].

   NOTE 1: This is a widely subscribed mailing list and messages sent to
   this address will be sent to all members of the DLSw mailing list.
   For specific questions relating to subscribing to the AIW and any of



Wells & Bartky                                                  [Page 1]

RFC 1795                  Data Link Switching                 April 1995


   it's working groups send email to: [e-mail]

   Information regarding all of the AIW working groups and the work they
   are producing can be obtained by copying, via anonymous ftp, the file
   aiwinfo.psbin or aiwinfo.txt from the Internet host
   networking.raleigh.ibm.com, located in directory aiw.

   NOTE 2:  These mailing lists and addresses are subject to change.

1.  Introduction

   Data Link Switching (DLSw) is a forwarding mechanism for the IBM SNA
   (Systems Network Architecture) and IBM NetBIOS (Network Basic Input
   Output Services) protocols.  This memo documents the Switch-to-Switch
   Protocol (SSP) that is used between Data Link Switches.  This
   protocol does not provide full routing, but instead provides
   switching at the SNA Data Link layer (i.e., layer 2 in the SNA
   architecture) and encapsulation in TCP/IP for transport over the
   Internet.  This RFC documents the frame formats and protocols for
   multiplexing data between Data Link Switches. The initial
   implementation of SSP uses TCP as the reliable transport between Data
   Link Switches.  However, other transport connections such as OSI TP4
   could be used in the future.

   A Data Link Switch (abbreviated also as DLSw in this document) can
   support  SNA (Physical Unit (PU) 2, PU 2.1 and PU 4) systems and
   optionally NetBIOS systems attached to IEEE 802.2 compliant Local
   Area Networks, as well as SNA (PU 2 (primary or secondary) and PU2.1)
   systems attached to IBM Synchronous Data Link Control (SDLC) links.
   For the latter case, the SDLC attached systems are provided with a
   LAN appearance within the Data Link Switch (each SDLC PU is presented
   to the SSP protocol as a unique MAC/SAP address pair).  For the
   Token-Ring LAN attached systems, the Data Link Switch appears as a
   source-routing bridge.  Token-Ring Remote systems that are accessed
   through the Data Link Switch appear as systems attached to an
   adjacent ring.  This ring is a virtual ring that is manifested within
   each Data Link Switch.

1.1  Backwards Compatibility with RFC 1434

   This document defines significant changes to RFC 1434 and does not
   state details on how to interoperate with RFC 1434 or "enhanced"
   implementations (e.g., those that added enter and exit busy flow
   control).  It is up to the implementer to refer to RFC 1434 and/or
   any other vendor's documentation in order to interoperate with a
   given vendor's implementation, if interoperability with pre-AIW DLSw
   RIG standards is desired.




Wells & Bartky                                                  [Page 2]

RFC 1795                  Data Link Switching                 April 1995


2.  Overview

   Data Link Switching was developed to provide support for SNA and
   NetBIOS in multi-protocol routers.  Since SNA and NetBIOS are
   basically connection oriented protocols, the Data Link Control
   procedure that they use on the LAN is IEEE 802.2 Logical Link Control
   (LLC) Type 2.  Data Link Switching also accommodates SNA protocols
   over WAN (Wide Area Network) links via the SDLC protocol.

   IEEE 802.2 LLC Type 2 was designed with the assumption that the
   network transit delay would be predictable (i.e., a local LAN).
   Therefore the LLC Type 2 elements of procedure use a fixed timer for
   detecting lost frames.  When remote bridging is used over wide area
   lines (especially at lower speeds), the network delay is larger and
   it can vary greatly based upon congestion.  When the delay exceeds
   the time-out value LLC Type 2 attempts to retransmit.  If the frame
   is not actually lost, only delayed, it is possible for the LLC Type 2
   procedures to become confused.  And as a result, the link may be
   eventually taken down if the delay exceeds the T1 timer times N2
   retry count.

   Given the use of LLC Type 2 services, Data Link Switching addresses
   the following bridging problems:

             DLC Time-outs
             DLC Acknowledgments over the WAN
             Flow and Congestion Control
             Broadcast Control of Search Packets
             Source-Route Bridging Hop Count Limits

   NetBIOS also makes extensive use of datagram services that use
   connectionless LLC Type 1 service.  In this case, Data Link Switching
   addresses the last two problems in the above list.

   The principal difference between Data Link Switching and bridging is
   that for connection-oriented data DLSw terminates the Data Link Control
   whereas bridging does not. The following figure illustrates this
   difference based upon two end systems operating with LLC Type 2
   services.












Wells & Bartky                                                  [Page 3]

RFC 1795                  Data Link Switching                 April 1995


   Bridging
   --------

                    Bridge           Bridge
   +------+         +----+           +----+         +------+
   | End  | +-----+ |    +-----/     |    | +-----+ | End  |
   |System+-+ LAN +-+    |    /------+    +-+ LAN +-+System|
   |      | +-----+ |    |  TCP/IP   |    | +-----+ |      |
   +------+         +----+           +----+         +------+
      Info----------------------------------------------->
          <-----------------------------------------------RR


   Data Link Switching
   -------------------

   +------+         +----+           +----+         +------+
   | End  | +-----+ |    +-----/     |    | +-----+ | End  |
   |System+-+ LAN +-+DLSw|    /------+DLSw+-+ LAN +-+System|
   |      | +-----+ |    |  TCP/IP   |    | +-----+ |      |
   +------+         +----+           +----+         +------+
    Info--------------->   -------------> Info
      <---------------RR                 ------------>
                                         <------------RR

   In traditional bridging, the Data Link Control is end-to-end.  Data
   Link Switching terminates the LLC Type 2 connection at the switch.
   This means that the LLC Type 2 connections do not cross the wide area
   network.  The DLSw multiplexes LLC connections onto a TCP connection
   to another DLSw.  Therefore, the LLC connections at each end are
   totally independent of each other.  It is the responsibility of the
   Data Link Switch to deliver frames that it has received from a LLC
   connection to the other end.  TCP is used between the Data Link
   Switches to guarantee delivery of frames.

   As a result of this design, LLC time-outs are limited to the local
   LAN (i.e., they do not traverse the wide area).  Also, the LLC Type 2
   acknowledgments (RR's) do not traverse the WAN, thereby reducing
   traffic across the wide area links.  For SDLC links, polling and poll
   response occurs locally, not over the WAN.  Broadcast of search
   frames is controlled by the Data Link Switches once the location of a
   target system is discovered.  Finally, the switches can now apply
   back pressure to the end systems to provide flow and congestion
   control.

   Only one copy of an Link Protocol Data Unit (LPDU) is sent between
   Data Link Switches in SSP messages (XIDFRAME and INFOFRAME).  Retries
   of the LPDU are absorbed by Data Link Switch that receives it.  The



Wells & Bartky                                                  [Page 4]

RFC 1795                  Data Link Switching                 April 1995


   Data Link Switch that transmits the LPDU received in an SSP message
   to a local DLC, will perform retries in a manner appropriate for the
   local DLC. This may involve running a reply timer and maintaining a
   poll retry count.  The length of the timer and the number of retries
   is an implementation choice based on user configuration parameters
   and the DLC type.

   Data Link Switching uses LAN addressing to set up connections between
   SNA systems.  SDLC attached devices are defined with MAC and SAP
   addresses to enable them to communicate with LAN attached devices.
   For NetBIOS systems, Data Link Switching uses the NetBIOS name to
   forward datagrams and to set up connections for NetBIOS sessions.
   For LLC type 2 connection establishment, SNA systems send TEST (or in
   some cases, XID) frames to the null (0x00) SAP.  NetBIOS systems have
   an address resolution procedure, based upon the Name Query and Name
   Recognized frames, that is used to establish an end-to-end circuit.

   Since Data Link Switching may be implemented in multi-protocol
   routers, there may be situations where both bridging and switching
   are enabled. SNA frames can be identified by their link SAP.  Typical
   SAP values for SNA are 0x04, 0x08, and 0x0C.  NetBIOS always uses a
   link SAP value of 0xF0.





























Wells & Bartky                                                  [Page 5]

RFC 1795                  Data Link Switching                 April 1995


3.  Transport Connection

   Data Link Switches can be in used in pairs or by themselves.

   A Single DLSw internally switches one data link to another without
   using TCP (DLC(1) to DLC(2) in the figure below).  This RFC does not
   go into details on how to implement this feature and it is not a
   requirement to support this RFC.

   A paired DLSw multiplexes data links over a reliable transport using
   a Switch-to-Switch Protocol (SSP).

   +-------------------------------------------+Switch-to-Switch
   |              DLC Interfaces               | Protocol (SSP)
   |+-----------+   DLC Request  +-----------+ |
   ||   Data    |<---------------|           | |Send SSP Frame