Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1795

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

Pages: 91
Informational
Obsoletes:  1434
Part 1 of 4 – Pages 1 to 18
None   None   Next

ToP   noToC   RFC1795 - Page 1
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:
   aiw-dlsw@networking.raleigh.ibm.com.

   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
ToP   noToC   RFC1795 - Page 2
   it's working groups send email to: appn@vnet.ibm.com

   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.
ToP   noToC   RFC1795 - Page 3
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.
ToP   noToC   RFC1795 - Page 4
   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
ToP   noToC   RFC1795 - Page 5
   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.
ToP   noToC   RFC1795 - Page 6
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
   ||   Link    | DLC Indication |           | |-------------->
   || Control 1 |--------------->|           | |
   |+-----------+                | Data Link | |
   |+-----------+   DLC Request  |  Switch   | |
   ||   Data    |<-------------- |           | |Rec. SSP Frame
   ||   Link    | DLC Indication |           | |<-------------
   || Control 2 | -------------->|           | |
   |+-----------+                +-----------+ |
   |            Multi-Protocol Router          |
   +-------------------------------------------+

   Before Data Link Switching can occur between two routers, they must
   establish two TCP connections between them.  Each Data Link Switch
   will maintain a list of DLSw capable routers and their status
   (active/inactive).  After the TCP connection is established, SSP
   messages are exchanged to establish the capabilities of the two Data
   Link Switches.  Once the exchange is complete,  the DLSw will employ
   SSP control messages to establish end-to-end circuits over the
   transport connection.  Within the transport connection, DLSw SSP
   messages are exchanged.  The message formats and types for these SSP
   messages are documented in the following sections.

   The default parameters associated with the TCP connections between
   Data Link Switches are as follows:

   Socket Family     AF_INET        (Internet protocols)
   Socket Type       SOCK_STREAM    (stream socket)
   Read Port Number  2065
   Write Port Number 2067
ToP   noToC   RFC1795 - Page 7
   Two or more Data Link Switches may be attached to the same LAN,
   consisting of a number of token-ring segments interconnected by
   source-routing bridges.  In this case, a TCP connection is not
   defined between bridges attached to the same LAN.  This will allow
   using systems to select one of the possible Data Link Switches in a
   similar manner to the selection of a bridge path through a source-
   routed bridged network.  The virtual ring segment in each Data Link
   Switch attached to a common LAN must be configured with the same ring
   number.  This will prevent LAN frames sent by one Data Link Switch
   from being propagated through the other Data Link Switches.
ToP   noToC   RFC1795 - Page 8
3.1  SSP Frame Formats

   The following diagrams show the two message header formats exchanged
   between Data Link Switches, Control and Information.  The Control
   message header is used for all messages except Information Frames
   (INFOFRAME) and Independent Flow Control Messages (IFCM), which are
   sent in Information header format.  The INFOFRAME, KEEPALIVE and IFCM
   message headers are 16 bytes long, and the control message header is
   72 bytes long.  The fields in the first sixteen bytes of all message
   headers are the same.

    CONTROL MESSAGES (72 Bytes)
    (zero based offsets below shown in decimal (xx) )
   +-----------------------------+-----------------------------+
   | (00) Version Number         | (01) Header Length (= 72)   |
   +-----------------------------+-----------------------------+
   | (02) Message Length                                       |
   +-----------------------------+-----------------------------+
   | (04) Remote Data Link Correlator                          |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | (08) Remote DLC Port ID                                   |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | (12) Reserved Field                                       |
   +-----------------------------+-----------------------------+
   | (14) Message Type           | (15) Flow Control Byte      |
   +-----------------------------+-----------------------------+
   | (16) Protocol ID            | (17) Header Number          |
   +-----------------------------+-----------------------------+
   | (18) Reserved                                             |
   +-----------------------------+-----------------------------+
   | (20) Largest Frame Size     | (21) SSP Flags              |
   +-----------------------------+-----------------------------+
   | (22) Circuit Priority       | (23) Message Type (see note)|
   +-----------------------------+-----------------------------+
   | (24) Target MAC Address  (non-canonical format)           |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -|
   |                                                           |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | (30) Origin MAC Address  (non-canonical format)           |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -|
ToP   noToC   RFC1795 - Page 9
   |                                                           |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |            .                              .               |
   +-----------------------------+-----------------------------+
   | (36) Origin Link SAP        | (37) Target Link SAP        |
   +-----------------------------+-----------------------------+
   | (38) Frame Direction        | (39) Reserved               |
   +-----------------------------+-----------------------------+
   | (40) Reserved                                             |
   +-----------------------------+-----------------------------+
   | (42) DLC Header Length                                    |
   +-----------------------------+-----------------------------+
   | (44) Origin DLC Port ID                                   |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | (48) Origin Data Link Correlator                          |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | (52) Origin Transport ID                                  |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | (56) Target DLC Port ID                                   |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | (60) Target Data Link Correlator                          |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | (64) Target Transport ID                                  |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | (68) Reserved Field                                       |
   +-----------------------------+-----------------------------+
   | (70) Reserved Field                                       |
   +-----------------------------+-----------------------------+
            (Even Byte)                     (Odd Byte)
ToP   noToC   RFC1795 - Page 10
    INFORMATION MESSAGE (16 Bytes)
   +-----------------------------+-----------------------------+
   | (00) Version Number         | (01) Header Length (= 16)   |
   +-----------------------------+-----------------------------+
   | (02) Message Length                                       |
   +-----------------------------+-----------------------------+
   | (04) Remote Data Link Correlator                          |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | (08) Remote DLC Port ID                                   |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | (12) Reserved Field                                       |
   +-----------------------------+-----------------------------+
   | (14) Message Type           | (15) Flow Control Byte      |
   +-----------------------------+-----------------------------+
            (Even Byte)                    (Odd Byte)

   The first sixteen bytes of control and information message headers
   contain identical fields.  A brief description of some of the fields
   in an SSP message are shown below (if not defined below, the fields
   and/or their values are described in subsequent sections).

   The Version Number field (offset 0) is set to 0x31 (ASCII '1'),
   indicating a decimal value of 49.  This is used to indicate DLSw
   version 1.

   The Header Length field (offset 1) is 0x48 for control messages,
   indicating a decimal value of 72 bytes, and 0x10 for information and
   Independent Flow Control messages, indicating a decimal value of 16
   bytes.

   The Message Length field (offset 2) defines the number of bytes
   within the data field following the header.

   The Flow Control Byte field (offset 15)  is described in section 8.

   The Header Number field (offset 17) is 0x01, indicating a value of
   one.

   The Circuit Priority field (offset 22) is described in section 4.

   The Frame Direction field (offset 38) is set to 0x01 for frames sent
   from the origin DLSw to the target DLSw, and is set to 0x02 for
   frames sent from the target DLSw to the origin DLSw.
ToP   noToC   RFC1795 - Page 11
   Note:  The Remote Data Link Correlator and Remote DLC Port ID are set
   equal to the Target Data Link Correlator and Target DLC Port ID if
   the Frame Direction field is set to 0x01, and are set equal to the
   Origin Data Link Correlator and Origin DLC Port ID if the Direction
   Field is set to 0x02.

   The Protocol ID field is set to 0x42, indicating a decimal value of
   66.

   The DLC Header Length is set to zero for SNA and is set to 0x23 for
   NetBIOS datagrams, indicating a length of 35 bytes.  This includes
   the Access Control (AC) field, the Frame Control (FC) field,
   Destination MAC Address (DA), the Source MAC Address (SA), the
   Routing Information (RI) field (padded to 18 bytes), the Destination
   link SAP (DSAP), the Source link SAP (SSAP), and the LLC control
   field (UI).

   NOTE:  The values for the Message Type field are defined in section
   3.5. Note that this value is specified in two different fields
   (offset 14 and 23 decimal) of the control message header.  Only the
   first field is to be used when parsing a received SSP message.  The
   second field is to be ignored by new implementations on reception.
   The second field was left in for backwards compatibility with RFC
   1434 implementations and this field may be used in future versions if
   needed.

   The SSP Flags field contains additional information related to the
   SSP message.  The flags are defined as follows (bit 7 being the most
   significant bit and bit 0 the least significant bit of the octet):

   Bit(s)
   76543210    Name    Meaning
   ---------   -----   -------
   x.......    SSPex   1 = explorer message (CANUREACH and ICANREACH)

   Reserved fields are set to zero upon transmission and should be
   ignored upon receipt.

3.2  Address Parameters

   A data link is defined as a logical association between the two end
   stations using Data Link Switching.  It is identified by a Data Link
   ID (14 bytes) consisting of the pair of attachment addresses
   associated with each end system.  Each attachment address is
   represented by the concatenation of the MAC address (6 bytes) and the
   LLC address (1 byte).  Each attachment address is classified as
   either "Target" in the context of the Destination MAC/SAP addresses
   of an explorer frame sent in the first frame used to establish a
ToP   noToC   RFC1795 - Page 12
   circuit, or "Origin" in the context of the Source MAC/SAP addresses.
   All MAC addresses are expressed in non-canonical (Token-Ring) format.

    DATA LINK ID  (14 Bytes @ Control message offset 24 decimal)
   +-----------------------------+-----------------------------+
   | Target MAC Address                                        |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | Origin MAC Address                                        |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | Origin Link SAP             | Target Link SAP             |
   +-----------------------------+-----------------------------+


   An end-to-end circuit is identified by a pair of Circuit ID's.  A
   Circuit ID is a 64 bit number that identifies the DLC circuit within
   a single DLSw.  It consists of a DLC Port ID (4 bytes), and a Data
   Link Correlator (4 bytes).  The Circuit ID must be unique in a single
   DLSw and is assigned locally.  The pair of Circuit ID's along with
   the Data Link IDs,  uniquely identify a single end-to-end circuit.
   Each DLSw must keep a table of these Circuit ID pairs, one for the
   local end of the circuit and the other for the remote end of the
   circuit.  In order to identify which Data Link Switch originated the
   establishment of a circuit, the terms, "Origin" DLSw and "Target"
   DLSw, will be employed in this document.

    CIRCUIT ID   (8 Bytes)
   +-----------------------------+-----------------------------+
   | DLC Port ID                                               |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | Data Link Correlator                                      |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+

   The Origin Transport ID and the Target Transport ID fields in the
   message header are used to identify the individual TCP/IP port on a
   Data Link Switch.  The values have only local significance.  However,
   each Data Link Switch is required to reflect the values contained in
ToP   noToC   RFC1795 - Page 13
   these two fields, along with the associated values for DLC Port ID
   and the Data Link Correlator, when returning a message to the other
   Data Link Switch.

   The following figure shows the use of the addressing parameters
   during the establishment of an end-to-end connection.  The CANUREACH,
   ICANREACH, and REACH_ACK message types all carry the Data Link ID,
   consisting of the MAC and Link SAP addresses associated with the two
   end stations.  The CANUREACH and ICANREACH messages are qualified by
   the SSPex flag into CANUREACH_ex, ICANREACH_ex (explorer messages)
   and CANUREACH_cs, ICANREACH_cs (circuit start).  The CANUREACH_ex is
   used to find a remote MAC and Link SAP address without establishing
   an SSP circuit.  Upon receipt of a CANUREACH_cs message, the target
   DLSw starts a data link for each port, thereby obtaining a Data Link
   Correlator.  If the target station can be reached, an ICANREACH_cs
   message is returned to the origin DLSw containing the Target Circuit
   ID parameter.  Upon receipt, the origin DLSw starts a data link and
   returns the Origin Circuit ID to the target DLSw within the REACH_ACK
   message.  (Note for a full list of message types, see section 3.5.)

   +------------+                                +------------+
   |Disconnected|                                |Disconnected|
   +------------+   CANUREACH_cs (Data Link ID)  +------------+
       ------------------------------------------------->
         ICANREACH_cs (Data Link ID, Target Circuit ID)
       <------------------------------------------------
     REACH_ACK (Data Link ID, Origin Cir ID, Target Cir ID)
       ------------------------------------------------->
   +------------+                                +------------+
   |Circuit Est.|                                |Circuit Est.|
   +------------+                                +------------+
     XIDFRAME (Data Link ID, Origin Cir ID, Target Cir ID)
       <------------------------------------------------>
      CONTACT (Data Link ID, Origin Cir ID, Target Cir ID)
       ------------------------------------------------->
     CONTACTED (Data Link ID, Origin Cir ID, Target Cir ID)
       <-------------------------------------------------
   +------------+                                +------------+
   | Connected  |                                | Connected  |
   +------------+                                +------------+
        INFOFRAME (Remote Circuit ID = Target Circuit ID)
       ------------------------------------------------->
        INFOFRAME (Remote Circuit ID = Origin Circuit ID)
       <-------------------------------------------------

   During the exchange of the XIDFRAME, CONTACT, and CONTACTED messages,
   the pair of Circuit ID parameters is included in the message format
   along with the DATA LINK ID parameter.  Once the connection has been
ToP   noToC   RFC1795 - Page 14
   established, the INFOFRAME messages are exchanged with the shorter
   header.  This header contains only the Circuit ID associated with the
   remote DLSw.  The Remote Data Link Correlator and the Remote DLC Port
   ID are set equal to the Data Link Correlator and the DLC Port ID that
   are associated with the origin or target Data Link Switch, dependent
   upon the direction of the packet.

3.3  Correlators

   The local use, and contents of the Data Link Correlator, Port ID and
   Transport ID fields in SSP messages is an implementation choice.
   These fields have local significance only.  The values received from
   a partner DLSw must not be interpreted by the DLSw that receives them
   and should be echoed "as is" to a partner DLSw in subsequent
   messages.  All implementations must obey the following rules in this
   section (3.3) on the assignment and fixing of these correlator fields
   for each transport connection or circuit:

   The Transport ID fields are learned from the first SSP message
   exchanged with a DLSw partner (the Capabilities exchange).  This
   field should not be varied by a DLSw after the capabilities exchange
   and must be reflected to the partner DLSw in every SSP control
   message.

   The Target Data Link Correlator, Target Port ID and Target Transport
   ID must remain the same once the Target DLSw has sent the
   ICANREACH_cs for a given circuit.  The Origin DLSw must store the
   values specified in the ICANREACH_cs and use these on all subsequent
   SSP messages for this circuit.

   The Origin DLSw must allow these fields to vary until the
   ICANREACH_cs is received.  Each SSP message issued for a circuit must
   reflect the values specified by the Target DLSw in the last SSP
   message for this circuit received by the Origin DLSw.  Binary zero
   should be used if no such message has yet been received for a given
   circuit (apart from the Target Transport ID which will have been
   learnt as specified above).

   The Origin Data Link Correlator, Origin Port ID and Origin Transport
   ID must remain the same once the Origin DLSw has issued the REACH_ACK
   for a given circuit.  The Target DLSw must store the values specified
   in the REACH_ACK and use these on all subsequent SSP messages for
   this circuit.

   The Target DLSw must allow these fields to vary until the REACH_ACK
   is received.  Each SSP message issued for a circuit must reflect the
   values specified by the Origin DLSw in the last SSP message for this
   circuit received by the Target DLSw.  Binary zero should be used if
ToP   noToC   RFC1795 - Page 15
   no such message has yet been received for a given circuit (apart from
   the Origin Transport ID which will have been learnt as specified
   above).

   For the purposes of correlator exchange, explorer messages form a
   separate circuit.  Both DLSw partners must reflect the last received
   correlator values as specified above.  However correlators learned on
   explorer messages need not be carried over to a subsequent circuit
   setup attempt.  In particular, the Origin DLSw may elect to use the
   same values for the Origin Data Link Correlator and Origin Port ID
   when it issues a CANUREACH_cs after receiving an ICANREACH_ex or
   NETBIOS_NR_ex. However the Target DLSw must not assume that the
   CANUREACH_cs will specify any of the Target Data Link Correlator or
   Target Port ID that were exchanged on the explorer messages.

   Received SSP messages that require a valid Remote Circuit ID but
   cannot be associated with an existing circuit should be rejected with
   a HALT_DL_NOACK message.  This is done to prevent a situation where
   one DLSw partner has a circuit defined while the other partner does
   not. The exception would be a HALT_DL_NOACK message with an invalid
   Remote Circuit ID.  The HALT_DL_NOACK message is typically used in
   error situations where a response is not appropriate.

   The SSP messages requiring a valid Remote Circuit ID are all messages
   except the following: CANUREACH_ex, CANUREACH_cs, ICANREACH_ex,
   ICANREACH_cs, NETBIOS_NQ_cs, NETBIOS_NR_cs, DATAFRAME, NETBIOS_ANQ,
   NETBIOS_ANR, KEEPALIVE and CAP_EXCHANGE.

3.4  Largest Frame Size Field

   The Largest Frame Size (LF Size) field in the SSP Control Header is
   used to carry the LF Size bits across the DLSw connection.  This
   should be used to ensure that the two end-stations always negotiate a
   frame size to be used on a circuit that does not require the Origin
   and Target DLSw partners to re-segment frames.

   This field is valid on CANUREACH_ex, CANUREACH_cs, ICANREACH_ex,
   ICANREACH_cs, NETBIOS_NQ_ex and NETBIOS_NR_ex messages only. The
   contents of this field should be ignored on all other frames.

   Every DLSw forwarding a SSP frame to its DLSw partner must ensure
   that the contents of this frame reflect the minimum capability of the
   route to its local end-station or any limit imposed by the DLSw
   itself.

   The bit-wise definition of this field is as follows (bit 7 is the
   most significant bit, bit 0 is the least significant bit):
ToP   noToC   RFC1795 - Page 16
     7   6   5   4   3   2   1   0
   +-------------------------------+
   | c | r | b | b | b | e | e | e |
   +-------------------------------+

     c   .   .   .   .   .   .   .  LF Size Control flag
                                    (significant on messages
                                    from Origin to Target
                                    DLSw only)

                                    0=fail circuit if route
                                      obtained requires a
                                      smaller LF size
                                    1=don't fail the circuit
                                      but return the LF size
                                      obtained even if it is
                                      smaller

     .   r   .   .   .   .   .   .  Reserved
     .   .   b   .   .   .   .   .  Largest Frame Bit Base
     .   .   .   b   .   .   .   .  Largest Frame Bit Base
     .   .   .   .   b   .   .   .  Largest Frame Bit Base
     .   .   .   .   .   e   .   .  Largest Frame Bit Extended
     .   .   .   .   .   .   e   .  Largest Frame Bit Extended
     .   .   .   .   .   .   .   e  Largest Frame Bit Extended

             <----- LF Bits ----->

   Refer to IEEE 802.1D Standard, Annex C for encoding of Largest Frame
   base and extended bit values.

   The Origin DLSw "Size Control" flag informs a Target DLSw that
   chooses to reply to *_cs messages on the basis of cached information
   that it may safely return a smaller LF Size on the ICANREACH_cs frame
   if it has had to choose an alternative route on which to initialize
   the circuit.  If this bit is set to 1, the Origin DLSw takes
   responsibility for ensuring that the end-stations negotiate a
   suitable frame size for the circuit. If this bit is set to 0, the
   Target DLSw must not reply to the CANUREACH_cs if it cannot obtain a
   route to the Target end station that support an LF Size at least as
   large as that specified in the CANUREACH_cs frame.

3.5  Message Types

   The following table lists the protocol data units that are exchanged
   between Data Link Switches.  All values not listed are reserved for
   potential use in follow-on releases.
ToP   noToC   RFC1795 - Page 17
   Command          Description                       Type   flags/notes
   -------          --------                         ------  -----------
   CANUREACH_ex     Can U Reach Station-explorer      0x03   SSPex
   CANUREACH_cs     Can U Reach Station-circuit start 0x03
   ICANREACH_ex     I Can Reach Station-explorer      0x04   SSPex
   ICANREACH_cs     I Can Reach Station-circuit start 0x04
   REACH_ACK        Reach Acknowledgment              0x05
   DGRMFRAME        Datagram Frame                    0x06   (note 1)
   XIDFRAME         XID Frame                         0x07
   CONTACT          Contact Remote Station            0x08
   CONTACTED        Remote Station Contacted          0x09
   RESTART_DL       Restart Data Link                 0x10
   DL_RESTARTED     Data Link Restarted               0x11
   ENTER_BUSY       Enter Busy                        0x0C   (note 2)
   EXIT_BUSY        Exit Busy                         0x0D   (note 2)
   INFOFRAME        Information (I) Frame             0x0A
   HALT_DL          Halt Data Link                    0x0E
   DL_HALTED        Data Link Halted                  0x0F
   NETBIOS_NQ_ex    NETBIOS Name Query-explorer       0x12   SSPex
   NETBIOS_NQ_cs    NETBIOS Name Query-circuit setup  0x12   (note 3)
   NETBIOS_NR_ex    NETBIOS Name Recognized-explorer  0x13   SSPex
   NETBIOS_NR_cs    NETBIOS Name Recog-circuit setup  0x13   (note 3)
   DATAFRAME        Data Frame                        0x14   (note 1)
   HALT_DL_NOACK    Halt Data Link with no Ack        0x19
   NETBIOS_ANQ      NETBIOS Add Name Query            0x1A
   NETBIOS_ANR      NETBIOS Add Name Response         0x1B
   KEEPALIVE        Transport Keepalive Message       0x1D   (note 4)
   CAP_EXCHANGE     Capabilities Exchange             0x20
   IFCM             Independent Flow Control Message  0x21
   TEST_CIRCUIT_REQ Test Circuit Request              0x7A
   TEST_CIRCUIT_RSP Test Circuit Response             0x7B

   Note 1: Both the DGRMFRAME and DATAFRAME messages are used to carry
   information received by the DLC entity within UI frames.  The
   DGRMFRAME message is addressed according to a pair of Circuit IDs,
   while the DATAFRAME message is addressed according to a Data Link ID,
   being composed of a pair of MAC addresses and a pair of link SAP
   addresses. The latter is employed prior to the establishment of an
   end-to-end circuit when Circuit IDs have yet to be established or
   during circuit restart when Data Links are reset.

   Note 2: These messages are not used for the DLSw Standard but may be
   used by older DLSw implementations.  They are listed here for
   informational purposes.  These messages were added after publication
   of RFC 1434 and were deleted in this standard (adaptive pacing is now
   used instead).
ToP   noToC   RFC1795 - Page 18
   Note 3: These messages are not normally issued by a Standard DLSw,
   which uses the NB_*_ex messages as shown in section 5.4.  However if
   a Standard DLSw attempts to interoperate with older DLSw
   implementations, these messages correspond to the NETBIOS_NQ and
   NETBIOS_NR messages used in RFC1434 both to locate the resource and
   to setup a circuit.  This document does not attempt to provide a
   complete specification of the use of these messages.

   Note 4:  A KEEPALIVE message may be sent by a DLSw to a partner DLSw
   in order to verify the TCP connection (or other future SSP carrying
   protocol) is still functioning.  If received by a DLSw, this message
   is discarded and ignored.  Use of this message is optional.

   For the exchange of NetBIOS control messages, the entire DLC header
   is carried as part of the message unit.  This includes the MAC
   header, with the routing information field padded to 18 bytes, and
   the LLC header. The following message types are affected:
   NETBIOS_NQ, NETBIOS_NR, NETBIOS_ANQ, NETBIOS_ANR, and DATAFRAME when
   being used by NetBIOS systems.  The routing information in the DLC
   header is not used by the remote Data Link Switch upon receiving the
   above five messages.

   Any SSP message types not defined above if received by a DLSw are to
   be ignored (i.e., no error action is to be performed).  A Data Link
   Switch should quietly drop any SSP message with a Message Type that
   is not recognized or not supported.  Receipt of such a message should
   not cause the termination of the transport connection to the message
   sender.



(page 18 continued on part 2)

Next Section