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 3 of 4 – Pages 44 to 67
First   Prev   Next

ToP   noToC   RFC1795 - Page 44   prevText
5.4.2  NETBIOS_NQ/NR Explorer FSM

   The FSM described below is used to handle explorer frames routed by
   NetBIOS names  There is one instance of this FSM for each unique
   combination of Source Name, Destination Name, Data 2 field and
   Response Correlator.

   State Name            Description
   ----------            -----------
   RESET                 The initial state.

   SENT_EX               Local DLSw has issued an explorer
                         message

   RECEIVED_EX           Local DLSw has received an explorer
                         message

   SENT_REC_EX           An explorer frame has been both sent
                         and received for the same (potential)
                         NetBIOS circuit.

5.4.2.1  RESET State

   +----------------------+---------------------+----------------------+
   |        Event         |      Action(s)      |      Next State      |
   +----------------------+---------------------+----------------------+
   | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX          |
   |                      | Optionally update   |                      |
   |                      | cache.              |                      |
   +----------------------+---------------------+----------------------+
   | Receive NETBIOS_NR_ex| Optionally update   | RESET                |
   |                      | cache               |                      |
   +----------------------+---------------------+----------------------+
   | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_EX              |
   +----------------------+---------------------+----------------------+

   The RESET state is the initial state for the NETBIOS_NQ/NR explorer
   FSM. It is exited when the DLC receives either a NETBIOS_NQ_ex or a
   DLC_DGRM containing a NetBIOS NAME_QUERY frame.  If a NETBIOS_NQ_ex
   message is received, the NAME_QUERY is propagated to the DLC and this
   FSM moves to state RECEIVED_EX.  If a NetBIOS NAME_QUERY frame is
   received, the NETBIOS_NQ_ex is propagated either to the appropriate
   DLSw partners (see below), and this FSM moves to state SENT_EX.

   Unlike SNA traffic where the CANUREACH_ex/ICANREACH_ex exchange can
   be omitted if the MAC location is already cached,
   NETBIOS_NQ_ex/NETBIOS_NR_ex frames must always be issued during
   NetBIOS session setup in order that the NetBIOS session numbers are
ToP   noToC   RFC1795 - Page 45
   exchanged correctly between the DLC end stations.  If the location of
   a NetBIOS name is known from cached data, the NETBIOS_NQ_ex need only
   be issued to the cached DLSw partners.  Otherwise the NETBIOS_NQ_ex
   should be issued to all partners that support NetBIOS.

5.4.2.2  SENT_EX State

   +----------------------+---------------------+----------------------+
   |        Event         |      Action(s)      |      Next State      |
   +----------------------+---------------------+----------------------+
   | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX          |
   |                      | Optionally update   |                      |
   |                      | cache               |                      |
   +----------------------+---------------------+----------------------+
   | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RECOG)| RESET                |
   |                      | Optionally update   |                      |
   |                      | cache               |                      |
   +----------------------+---------------------+----------------------+
   | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_EX              |
   | (different local     | Optionally update   |                      |
   |  session number than | cache               |                      |
   |  existing searches)  |                     |                      |
   +----------------------+---------------------+----------------------+

   SENT_EX is entered when the local DLSw issues a NETBIOS_NQ_ex to its
   remote DLSw partners.  This state is exited when a NETBIOS_NR_ex is
   received from a remote DLSw, or if a matching NETBIOS_NQ_ex is
   received from a remote DLSw (i.e., a NETBIOS_NQ_ex crossover case).
   If the local NetBIOS end station issues a NAME_QUERY with a different
   session number from any previous NAME_QUERY for this search, the
   NAME_QUERY is propagated to the DLSw partners to ensure that the
   exchange of NetBIOS session numbers is handled correctly.
ToP   noToC   RFC1795 - Page 46
5.4.2.3  RECEIVED_EX State

   +----------------------+---------------------+----------------------+
   |        Event         |      Action(s)      |      Next State      |
   +----------------------+---------------------+----------------------+
   | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX          |
   |                      | Optionally update   |                      |
   |                      | cache               |                      |
   +----------------------+---------------------+----------------------+
   | Receive NETBIOS_NR_ex|                     | RECEIVED_EX          |
   +----------------------+---------------------+----------------------+
   | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_REC_EX          |
   |                      | Optionally update   |                      |
   |                      | cache               |                      |
   +----------------------+---------------------+----------------------+
   | DLC_DGRM (NAME_RECOG)| Send NETBIOS_NR_ex  | RESET                |
   |                      | Optionally update   |                      |
   |                      | cache               |                      |
   +----------------------+---------------------+----------------------+

   RECEIVED_EX is entered when the local DLSw receives a NETBIOS_NQ_ex
   message from a remote DLSw.  This state is exited when a
   NAME_RECOGNIZED NetBIOS frame is received from the DLC, completing
   the query, or when a matching NAME_QUERY is received from DLC (i.e.,
   NAME_QUERY crossover).

5.4.2.4  SENT_REC_EX State

   +----------------------+---------------------+----------------------+
   |        Event         |      Action(s)      |      Next State      |
   +----------------------+---------------------+----------------------+
   | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX          |
   |                      | Optionally update   |                      |
   |                      | cache               |                      |
   +----------------------+---------------------+----------------------+
   | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RECOG)| RECEIVED_EX          |
   |                      | Optionally update   |                      |
   |                      | cache               |                      |
   +----------------------+---------------------+----------------------+
   | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_REC_EX          |
   | (different local     | Optionally update   |                      |
   |  session number than | cache               |                      |
   |  existing searches)  |                     |                      |
   +----------------------+---------------------+----------------------+
   | DLC_DGRM (NAME_RECOG)| Send NETBIOS_NR_ex  | SENT_EX              |
   |                      | Optionally update   |                      |
   |                      | cache               |                      |
   +----------------------+---------------------+----------------------+
ToP   noToC   RFC1795 - Page 47
   This state is required if an implementation wishes to manage NQ/NR
   crossover cases from a single FSM instance by detecting 'opposite'
   NAME_QUERY attempts between the same two NetBIOS names.  If separate
   FSM instances are used instead, this state is not required and the
   transitions to it from other states can be removed.

   SENT_RCV_EX is exited when the NAME_QUERY search in either direction
   is resolved.  If the local NetBIOS end station issues a NAME_QUERY
   with a different session number from any previous NAME_QUERY it has
   issued for this search, the NAME_QUERY is propagated to the DLSw
   partners to ensure that the exchange of NetBIOS session numbers is
   correctly handled.

5.4.2.5  NetBIOS Session Numbers

   NetBIOS NAME_QUERY and NAME_RECOGNIZED frames exchange NetBIOS session
   numbers between the end stations.  For correct NetBIOS operation over
   DLSw, it is important that all SSP NETBIOS_NQ_ex frames received by a
   DLSw cause NetBIOS NAME_QUERY frames to flow on the LAN with the new
   session number from the NETBIOS_NQ_ex.  These frames cannot be replied
   to from a cache of locally available NetBIOS names in the same way that
   MAC addresses and CANUREACH_ex messages can be handled.

   Also, NAME_QUERY messages are normally retried several times on the LAN.
   The generation and absorption of such frames is outside the scope of the
   FSM defined above.

6.  Protocol Flow Diagrams

   The Switch-to-Switch Protocol is used to setup and take down circuits
   between a pair of Data Link Switches.  Once a circuit is established,
   the end stations on the local networks can employ LLC Type 1
   (connectionless UI frames) protocols end-to-end.  In addition, the end
   systems can establish an end-to-end connection for support of LLC Type 2
   (connection oriented I frames) protocols (Type 2 I frames go end-to-end,
   supervisory frames are handled locally).

   The term, Data Link, is used in this document to refer to both a
   "logical data link" when supporting Type 1 LLC services, and a "data
   link connection" when supporting Type 2 LLC services.  In both cases,
   the Data Link is identified by the Data Link ID defined in section 3.2.

   NOTE:  THIS SECTION CONTAINS EXAMPLES ONLY.  IT CANNOT AND DOES NOT SHOW
   ALL POSSIBLE VARIATIONS AND OPTIONS ON PROTOCOL FLOWS FOR SNA/SDLC, SSP,
   AND LLC PROTOCOLS.
ToP   noToC   RFC1795 - Page 48
6.1  Connect Protocols

   The two basic startup flows from a pure FSM perspective are shown below.
   The first flow is a startup involving XIDs and the second is one without
   XIDs.

Flow #1 - DLSw Startup With XIDs
 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                    disconnected

              DLC_RESOLVE_C   CANUREACH_ex
              ----------->    ----------->
              DLC_RESOLVE_R     ICANREACH_ex
               <-----------     <-----------

              DLC_XID         CANUREACH_cs    DLC_START_DL
              ----------->    ----------->    ----------->
              circuit_start                   resolve_pending

                                ICANREACH_cs    DLC_DL_STARTED
                                <-----------    <-----------
          circuit_established                 circuit_pending
                              REACH_ACK
                              ----------->   circuit_established

                              XIDFRAME        DLC_XID
                              ----------->    ----------->

                     DLC_XID        XIDFRAME         DLC_XID
                <-----------    <-----------    <-----------
              DLC_XID         XIDFRAME        DLC_XID
              ----------->    ----------->    ----------->

                 DLC_XIDs       XIDFRAMEs        DLC_XIDs
              <------------>  <------------>  <------------>

              DLC_CONTACTED   CONTACT         DLC_CONTACT
              ----------->    ----------->    ----------->
              connect_pending                 contact_pending
ToP   noToC   RFC1795 - Page 49
                 DLC_CONTACT       CONTACTED    DLC_CONTACTED
                <-----------    <-----------    <-----------
                 connected                       connected

                DLC_INFOs        IFRAMEs        DLC_INFOs
              <------------>  <------------>  <------------>

   Mapping LAN events to the DLC events and actions on Flow #1 produces
   the following flows shown below:

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                    disconnected

TEST_cmd      DLC_RESOLVE_C    CANUREACH_ex               TEST_cmd
----------->  ----------->     ----------->               ---------->
   TEST_rsp   DLC_RESOLVE_R     ICANREACH_ex                 TEST_rsp
 <---------    <-----------   <-----------             <-----------
null XID      DLC_XID          CANUREACH_cs    DLC_START_DL
----------->  ----------->     ----------->    ----------->
              circuit_start                   resolve_pending

                                ICANREACH_cs    DLC_DL_STARTED
                                <-----------    <-------------
           circuit_established                circuit_pending
                              REACH_ACK
                              ----------->  circuit_established

                              XIDFRAME         DLC_XID       null XID
                              ----------->     --------->    -------->
        XID        DLC_XID        XIDFRAME         DLC_XID          XID
  <--------   <-----------    <-----------    <-----------    <--------
    XIDs         DLC_XIDs      XIDFRAMEs        DLC_XIDs         XIDs
<---------->  <---------->  <------------>  <------------>  <--------->
SABME         DLC_CONTACTED   CONTACT         DLC_CONTACT     SABME
----------->  ----------->    ----------->    ----------->    -------->
              connect_pending                 contact_pending

          UA     DLC_CONTACT     CONTACTED    DLC_CONTACTED          UA
  <---------   <-----------   <-----------    <-----------    <--------
                  connected                        connected
ToP   noToC   RFC1795 - Page 50
  IFRAMEs       DLC_INFOs        IFRAMEs        DLC_INFOs       IFRAMEs
<---------->  <----------->  <------------>  <------------>  <-------->

Those implementations that prefer to respond to the SABME immediately
could use the same events to do that:

SABME         DLC_CONTACTED   CONTACT         DLC_CONTACT     SABME
----------->  ----------->    ----------->    ----------->    -------->
          UA  connect_pending                 contact_pending
  <---------
RR
----------->
         RNR
  <---------

          RR    DLC_CONTACT       CONTACTED    DLC_CONTACTED          UA
  <---------   <-----------    <-----------    <-----------    <--------
                 connected                        connected

   IFRAMEs      DLC_INFOs        IFRAMEs        DLC_INFOs      IFRAMEs
<---------->  <------------>  <------------>  <------------>  <-------->

Flow #2 - DLSw Startup Without XIDs (circuit setup)

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                    disconnected

              DLC_CONTACTED   CANUREACH_cs    DLC_START_DL
              ----------->    ----------->    ----------->
              circuit_start                   resolve_pending

                                ICANREACH_cs    DLC_DL_STARTED
                                <-----------    <-----------
          circuit_established                 circuit_pending
                              REACH_ACK
                              ----------->   circuit_established

                              CONTACT         DLC_CONTACT
                              ----------->    ----------->
              connect_pending                 contact_pending
ToP   noToC   RFC1795 - Page 51
                 DLC_CONTACT       CONTACTED    DLC_CONTACTED
                <-----------    <-----------    <-----------
                 connected                       connected

                DLC_INFOs        IFRAMEs        DLC_INFOs
              <------------>  <------------>  <------------>

   Mapping LAN events to the DLC events and actions on Flow #2 (and
   adding a NETBIOS_NQ and NETBIOS_NR_ex) produces:

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                     disconnected

NAME_QUERY    DLC_DGRM        NETBIOS_NQ_ex   DLC_DGRM       NAME_QUERY
----------->  ----------->    ----------->    ----------->   --------->

   NAME_RECOG    DLC_DGRM      NETBIOS_NR_ex     DLC_DGRM    NAME_RECOG
 <-----------  <------------   <-----------    <-----------  <---------

SABME         DLC_CONTACTED   CANUREACH_cs    DLC_START_DL
----------->  ----------->    ----------->    ----------->
               circuit_start                 resolve_pending

                                ICANREACH_cs    DLC_DL_STARTED
                                <-----------    <-----------
            circuit_established                circuit_pending
                              REACH_ACK
                              ----------->   circuit_established

                              CONTACT         DLC_CONTACT     SABME
                              ----------->    ----------->    --------->
             connect_pending                 contact_pending

          UA   DLC_CONTACT       CONTACTED    DLC_CONTACTED           UA
  <---------  <-----------    <-----------    <-----------    <---------
                connected                       connected

   IFRAMEs       DLC_INFOs       IFRAMEs        DLC_INFOs       IFRAMEs
<------------> <------------> <------------>  <------------>  <-------->
ToP   noToC   RFC1795 - Page 52
   In keeping with a paradigm of 'DLSw is a big 802.2 LAN', all other
   DLC types (SDLC for now, QLLC, channel, or whatever in the future)
   would be handled by a 'DLC transformation layer' that would transform
   the specific protocol's events into the appropriate DLSw DLC events
   and DLSw DLC actions into the appropriate protocol actions.  The XIDs
   that flow in the SSP XIDFRAME should stay 802.2ish (i.e., ABM bit
   set) and leave it up to the DLC transformation layer to suit the XID
   to its particular DLC type.

   Here is an example of a leased SDLC PU 2.0 device as the origin
   station. It should use Flow #2 since it is not known if the other
   side is a LAN, a switched line or a leased line.

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                     disconnected

implementer's  DLC_RESOLVE_C   CANUREACH_ex
choice (power  ----------->    ----------->
up, configuration
change,        DLC_RESOLVE_R   ICANREACH_ex
never,          <-----------    <-----------
connect timer,etc.)

PU 2.0 is
configured
in DLSw to    DLC_XID(null)   CANUREACH_cs    DLC_START_DL
call in       ----------->    ----------->    ----------->
              circuit_start                   resolve_pending

                                ICANREACH_cs   DLC_DL_STARTED
                                <-----------   <-----------
           circuit_established                circuit_pending
                                REACH_ACK
                                ----------->   circuit_established

                              XIDFRAME        DLC_XID
                              ----------->    ----------->

                    DLC_XID        XIDFRAME         DLC_XID
respond with   <-----------    <-----------    <-----------
XID configured
ToP   noToC   RFC1795 - Page 53
for station or
forward XID to
station and
send response  DLC_XID        XIDFRAME        DLC_XID
               ----------->   ----------->    ----------->

        SNRM    DLC_CONTACT       CONTACT      DLC_CONTACTED
  <---------   <-----------    <-----------    <------------
              contact_pending                    connect_pending

UA            DLC_CONTACTED    CONTACTED       DLC_CONTACT
---------->    ----------->    ----------->    ----------->
                connected                       connected

   IFRAMEs       DLC_INFOs        IFRAMEs        DLC_INFOs
<----------->  <------------>  <------------>  <------------>

   Here is an example of a switched SDLC PU 2.0 device as the origin
   station.

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                     disconnected

implementer's  DLC_RESOLVE_C   CANUREACH_ex
choice (power  ----------->    ----------->
up, configuration
change,        DLC_RESOLVE_R   ICANREACH_ex
never,          <-----------    <-----------
connect timer,etc.)

XID(null)     DLC_XID(null)   CANUREACH_cs    DLC_START_DL
----------->  ----------->    ----------->    ----------->
              circuit_start                   resolve_pending

                                ICANREACH_cs    DLC_DL_STARTED
                                <-----------    <-----------
            circuit_established                 circuit_pending
                                REACH_ACK
                                ----------->   circuit_established
ToP   noToC   RFC1795 - Page 54
                                XIDFRAME      DLC_XID
                                ----------->  ----------->
         XID        DLC_XID         XIDFRAME         DLC_XID
  <---------   <-----------     <-----------    <-----------
XID           DLC_XID         XIDFRAME        DLC_XID
--------->    ----------->    ----------->    ----------->

        SNRM    DLC_CONTACT       CONTACT      DLC_CONTACTED
  <---------   <-----------    <-----------    <-----------
              contact_pending                 connect_pending

UA            DLC_CONTACTED   CONTACTED       DLC_CONTACT
--------->    ----------->    ----------->    ----------->
                 connected                      connected

   IFRAMEs      DLC_INFOs        IFRAMEs        DLC_INFOs
<---------->  <------------>  <------------>  <------------>

   Here is an example of a leased SDLC PU 2.0 device as the target
   station.

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw       Target
 Station        partner                          partner         Station
                                                                 (SDLC)
              disconnected                    disconnected

              DLC_RESOLVE_C   CANUREACH_ex
              ----------->    ----------->   reply if virtual MAC/SAP
                                             for SDLC station is
                                             configured, if SDLC
                                             station responds to
              DLC_RESOLVE_R    ICANREACH_ex  TEST/SNRM/DISC, etc.
               <-----------    <-----------
              DLC_XID         CANUREACH_cs    DLC_START_DL    SNRM
              ----------->    ----------->    ----------->    --------->
              circuit_start                   resolve_pending

                                ICANREACH_cs    DLC_DL_STARTED        UA
                                <-----------    <-----------    <-------
          circuit_established                 circuit_pending
                                                              RNR
                              REACH_ACK                       --------->
                              ----------->   circuit_established
ToP   noToC   RFC1795 - Page 55
                              XIDFRAME        DLC_XID
                              ----------->    -----------> respond with
                                                           XID configured
                                                           for station
                                                           or forward
                                                           XID to
                                                           station and
                                                           send
                   DLC_XID        XIDFRAME         DLC_XID response
              <-----------    <-----------    <-----------
              DLC_CONTACTED   CONTACT         DLC_CONTACT     RR
              ----------->    ----------->    ----------->    --------->
             connect_pending                contact_pending

                 DLC_CONTACT       CONTACTED    DLC_CONTACTED
                <-----------    <-----------    <-----------
                connected                        connected

                DLC_INFOs        IFRAMEs        DLC_INFOs       IFRAMEs
              <------------>  <------------>  <------------>  <------->

   Here is an example of a switched SDLC PU 2.0 device as the target
   station.

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw       Target
 Station        partner                          partner         Station
                                                                 (SDLC)
              disconnected                    disconnected

              DLC_RESOLVE_C   CANUREACH_ex
              ----------->    ----------->    reply if virtual MAC/SAP
                                              for SDLC station is
                                              configured, if SDLC
                                              station responds to
              DLC_RESOLVE_R     ICANREACH_ex  TEST/XID/SNRM/DISC, etc.
               <-----------     <-----------
              DLC_XID         CANUREACH_cs    DLC_START_DL    XID
              ----------->    ----------->    ----------->    --------->
              circuit_start                   resolve_pending

                                ICANREACH_cs   DLC_DL_STARTED        XID
                                <-----------   <-----------    <--------
          circuit_established                 circuit_pending
ToP   noToC   RFC1795 - Page 56
                              REACH_ACK
                              ----------->   circuit_established

                                XIDFRAME        DLC_XID
                                ----------->    -----------> respond
                                                             with XID
                                                             received
                     DLC_XID        XIDFRAME        DLC_XID  above
                <-----------    <-----------     <---------
             DLC_CONTACTED   CONTACT         DLC_CONTACT     SNRM
             ----------->    ----------->    ----------->    --------->
             connect_pending                  contact_pending

                DLC_CONTACT       CONTACTED    DLC_CONTACTED          UA
               <-----------    <-----------    <-----------    <--------
                connected                        connected

                DLC_INFOs        IFRAMEs        DLC_INFOs       IFRAMEs
              <------------>  <------------>  <------------>  <-------->

   Here is an example of an SDLC T2.1 device as the target station.
   (SDLC T2.1 origin station would look just like the LAN T2.1 origin
   station)

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                    disconnected

              DLC_RESOLVE_C   CANUREACH_ex
              ----------->    ----------->    implementer's choice
                                              (virtual MAC/SAP
                                               configured,
                                               check to see if station
                                               is powered up using
              DLC_RESOLVE_R     ICANREACH_ex   TEST/XID/DISC, etc.)
               <-----------     <-----------
              DLC_XID         CANUREACH_cs    DLC_START_DL    null XID
              ----------->    ----------->    ----------->    --------->
              circuit_start                   resolve_pending

                                ICANREACH_cs    DLC_DL_STARTED       XID
                                <-----------    <-----------    <-------
ToP   noToC   RFC1795 - Page 57
          circuit_established                 circuit_pending
                              REACH_ACK
                              ----------->   circuit_established
                              XIDFRAME        DLC_XID
                              ----------->    ----------->  respond with
                                                            XID received
                     DLC_XID        XIDFRAME        DLC_XID above
                <-----------    <-----------    <----------
                 DLC_XIDs       XIDFRAMEs        DLC_XIDs         XIDs
              <------------>  <------------>  <------------>  <-------->
              DLC_CONTACTED   CONTACT         DLC_CONTACT     SNRM
              ----------->    ----------->    ----------->    --------->
              connect_pending                 contact_pending

                 DLC_CONTACT       CONTACTED    DLC_CONTACTED         UA
                <-----------    <-----------    <-----------    <-------
                connected                        connected

                DLC_INFOs        IFRAMEs        DLC_INFOs       IFRAMEs
              <------------>  <------------>  <------------>  <-------->
ToP   noToC   RFC1795 - Page 58
6.2  Link Restart Protocols

   The following figure depicts the protocol flows that result from
   restarting the end-to-end connection.  This causes the Data Link
   Switches to terminate the existing connection and to enter the
   Circuit Established state awaiting the start of a new connection.

     Data Link   Data Link                     Data Link   Data Link
      Control     Switch                        Switch      Control
     ---------------------                     ---------------------
          +-----------+                             +-----------+
          | Connected |                             | Connected |
    SABME +-----------+                             +-----------+
   ----------->                 RESTART_DL
      DM           ------------------------------------->     DISC
   <-----------                                               -------->
                                                               UA
                         DL_RESTARTED (Case 1)              <--------
                   <-------------------------------------
          +-----------+                             +-----------+
          |Circuit Est|                             |Circuit Est|
          +-----------+                             +-----------+
                        ........... or ...........
    SABME
   ----------->           DL_RESTARTED (Case 2)
       UA          <-------------------------------------
   <-----------                                     +-----------+
                                                    |Circuit Est|
                                CONTACT             +-----------+
      RNR           ------------------------------------>
   <----------

              Figure 5.  DLSw Link Restart Message Protocols

   Upon receipt of a SABME command from the origin station, the origin
   DLSw will send a RESTART_DL message to the target DLSw.  A DM
   response is also returned to the origin station and the data link is
   restarted.

   Upon receipt of the RESTART_DL message, the target DLSw will issue a
   DISC command to the target station.  The target station is expected
   to return a UA response.  The target DLSw will then restart its data
   link and send an DL_RESTARTED message back to the origin DLSw.
   During this exchange of messages, both Data Link Switches change
   states from Connected state to Circuit Established state.

   If the origin station now resends the SABME command, the origin DLSw
   will send a CONTACT message to the target DLSw.  If the SABME command
ToP   noToC   RFC1795 - Page 59
   is received prior to the receipt of the DL_RESTARTED message (case 2
   in the figure), the CONNECT message is delayed until the DL_RESTARTED
   message is received.  The resulting protocol flows at this point
   parallel those given above for the connect sequence.

6.3  Disconnect Protocols

   The following figure depicts the protocol flows that result from the
   end system terminating an existing connection.  Not only is the
   connection terminated, but the circuit between the Data Link Switches
   is taken down.

     Data Link  Data Link                      Data Link  Data Link
      Control    Switch                         Switch     Control
     --------------------                      --------------------
          +-----------+                             +-----------+
          | Connected |                             | Connected |
          +-----------+                             +-----------+
      DISC
   ---------->                  HALT_DL
       UA         ------------------------------------->      DISC
   <----------                                              --------->
                                                               UA
                               DL_HALTED                    <--------
                  <-------------------------------------
          +-----------+                             +-----------+
          |Disconnectd|                             |Disconnectd|
          +-----------+                             +-----------+

                          ......... or ..........

          +-----------+                             +-----------+
          | Connected |                             | Connected |
          +-----------+                             +-----------+
       DISC              TCP Connection Failure               DISC
   <--------     <------------------------------------>    --------->
        UA                                                     UA
    -------->                                               <--------
          +-----------+                             +-----------+
          |Disconnectd|                             |Disconnectd|
          +-----------+                             +-----------+

               Figure 6.  DLSw Disconnect Message Protocols

   Upon receipt of a DISC command from the origin station, the origin
   DLSw will reply with a UA response and issue a HALT_DL message to the
   target DLSw.  Upon receipt of the HALT_DL message, the target DLSw
   will send a DISC command to the target station.  The target station
ToP   noToC   RFC1795 - Page 60
   will then respond with a UA response, causing the target DLSw to
   return a DL_HALTED message to the origin DLSw.  During this exchange
   of messages, both Data Link Switches change states from the Connected
   state to the Disconnected state.

   If the TCP connection between two Data Link Switches fails, all
   connections that are currently multiplexed on the failed TCP
   connection will be taken down.  This implies that both Data Link
   Switches will send DISC commands to all the local systems that are
   associated with the failed connections.  Upon sending the DISC
   command, the Data Link Switch will enter the DISCONNECTED state for
   each circuit.

7.0  Capabilities Exchange Formats/Protocol

   The Data Link Switching Capabilities Exchange is a special DLSw
   Switch-to-Switch control message that describes the capabilities of
   the sending data link switch. This control message is sent after the
   switch-to-switch connection is established and optionally during run
   time if certain operational parameters have changed and need to be
   communicated to the partner switch.

   The actual contents of the Capabilities Exchange is in the data field
   following the SSP message header.  The Capabilities Exchange itself
   is formatted as a single General Data Stream (GDS) Variable with
   multiple type "LT" structured subfields.

   The SSP Message Header has the following fields set for the
   Capabilities Exchange:

   Offset   Field                 Value
   ------   -----                 -----
   0x00     Version Number        0x31
   0x01     Header Length         0x48 (decimal 72)
   0x02     Message Length        same as LL in GDS Variable
   0x14     Message Type          0x20 (CAP_EXCHANGE)
   0x16     Protocol Id           0x42
   0x17     Header Number         0x01
   0x23     Message Type          0x20 (CAP_EXCHANGE)
   0x38     Direction             0x01 for CapEx request
                                  0x02 for CapEx response

   Other fields in the SSP header are not referenced and should be set
   to zero.
ToP   noToC   RFC1795 - Page 61
   The DLSw Capabilities Exchange Request has the following overall
   format:

   +----+----+-----------------+
   | LL | ID | Control Vectors |
   +----+----+-----------------+

   0-1         Length, in binary, of the DLSw Capabilities
               Exchange
               Request GDS Variable.  The value of LL is
               the sum of the length of all fields in the
               GDS Variable (i.e., length of LL + length of ID
               + length of Control Vectors).

   2-3         GDS Id: 0x1520

   4-n         Control Vectors consisting of type LT structured
               subfields (i.e., the DLSw Capabilities Exchange
               Structured Subfields)

   Type LT structured subfields consist of a 1-byte length field (the
   "L"), a 1-byte type field (the "T") and n-bytes of data.  The length
   field includes itself as well as the structured subfield.  The
   structured subfield consists of the type field and data so the length
   is n + 2. This imposes a length restriction of 253 bytes on all data
   contained in a structured subfield.
ToP   noToC   RFC1795 - Page 62
7.1  Control Vector Id Range

   Control Vector identifiers (i.e., Type) in the range of 0x80 through
   0xCF are reserved for use by the Data Link Switching standard.

   Control Vector identifiers (i.e., Type) in the range of 0xD0 through
   0xFD are used for vendor-specific purposes.

   Currently defined vectors are:

   Vector Description                       Hex Value

   Vendor Id Control Vector                 0x81
   DLSw Version Control Vector              0x82
   Initial Pacing Window Control Vector     0x83
   Version String Control Vector            0x84
   Mac Address Exclusivity Control Vector   0x85
   Supported SAP List Control Vector        0x86
   TCP Connections Control Vector           0x87
   NetBIOS Name Exclusivity Control Vector  0x88
   MAC Address List Control Vector          0x89
   NetBIOS Name List Control Vector         0x8A
   Vendor Context Control Vector            0x8B
   Reserved for future use                  0x8C - 0xCF
   Vendor Specific                          0xD0 - 0xFD

7.2  Control Vector Order and Continuity

   Since their contents can greatly affect the parsing of the
   Capabilities Exchange GDS Variable, the required control vectors must
   occur first and appear in the following order:  Vendor Id, DLSw
   Version Number, Initial Pacing Window, Supported SAP List. The
   remainder of the Control Vectors can occur in any order.

   Control Vectors that can be repeated within the same message (e.g.,
   MAC Address List Control Vector and NetBIOS Name List Control Vector)
   are not necessarily adjacent.  It is advisable, but not required, to
   have the Exclusivity Control Vector occur prior to either of the
   above two vectors so that the use of the individual MAC addresses or
   NetBIOS names will be known prior to parsing them.

   Both the Vendor Context and Vendor Specific control vectors can be
   repeated.  If there are multiple instances of the Vendor Context
   control vector, the specified context remains in effect for all
   Vendor Specific control vectors until the next Vendor Context control
   vector is encountered in the Capabilities Exchange.
ToP   noToC   RFC1795 - Page 63
7.3  Initial Capabilities Exchange

   Capabilities exchange is always the first SSP message sent on a new
   SSP connection between two DLSw switches.  This initial Capabilities
   Exchange is used to identify the DLSw version that each switch is
   running and other required information, plus details of any optional
   extensions that the switches are capable of supporting.

   If a DLSw receives an initial capabilities message that is
   incorrectly formatted or contains invalid or unsupported data that
   prevents correct interoperation with the partner DLSw, it should
   issue a Capabilities Exchange negative response.

   If a DLSw receives a negative response to its initial capabilities
   message, it should take down its TCP connections with the offended
   partner.

   Note:  Pre v1.0 DLSw implementations do not send or respond to
   capabilities messages and can be identified by the lack of
   capabilities exchange as the first message on a new SSP connnection.
   This document does not attempt to specify how to interoperate with
   back-level DLSw implementations.

7.4  Run-Time Capabilities Exchange

   Capabilities exchange always occurs when the SSP connection is
   started between two DLSw switches.  Capabilities Exchange can also
   occur at run-time, typically when a configuration change is made.

   Support for run-time Capabilities Exchange is optional.  If a node
   does not support receiving/using Run-Time Capabilities Exchange and
   receives one, it should discard it quietly (not send back a negative
   response).  If a node supports receipt of run-time capabilities, it
   should send a positive or negative response as appropriate.  The
   receiver of a negative response to a run-time capabilities message is
   not required to take down its TCP connections with the offended
   partner.

   Run-time Capabilities Exchange can consist of one or more of the
   following control vectors.  Note that the control vectors required at
   start-up are not present in a run-time Capabilities Exchange.
ToP   noToC   RFC1795 - Page 64
        1. MAC Address Exclusivity CV,
        2. NetBIOS Name Exclusivity CV,
        3. MAC Address List CV,
        4. NetBIOS Name List CV,
        5. Supported SAP List CV,
        6. Vendor Context CV,
        7. Vendor Specific CVs

   A run-time capabilities exchange is a replacement operation.  As
   such, all pertinent MAC addresses and NetBIOS names must be specified
   in the run-time exchange. In addition, run-time changes in
   capabilities will not effect existing link station circuits.

7.5  Capabilities Exchange Filtering Responsibilities

   Recipients of the SAP, MAC, and NetBIOS lists are not required to
   actually use them to filter traffic, etc., either initially or at
   run-time.

7.6  DLSw Capabilities Exchange Structured Subfields

   The Capabilities Exchange Subfields are listed in the table below and
   are described in the following sections:

         Required                      Allowed @
    ID   @ Startup  Length  Repeatable* Runtime  Order  Content
   ====  =========  ======  ==========  =======  =====  ===============
   0x81     Y        0x05        N         N       1    Vendor ID

   0x82     Y        0x04        N         N       2    DLSw Version

   0x83     Y        0x04        N         N       3    Initial pacing
                                                        window

   0x84     N      >=0x02        N         N       5+   Version String

   0x85     N        0x03        N         Y       5+   MAC Address
                                                        Exclusivity

   0x86     Y        0x12        N         Y       4    Supported SAP
                                                        List

   0x87     N        0x03        N         N       5+   TCP Connections

   0x88     N        0x03        N         Y       5+   NetBIOS Name
                                                        Exclusivity
ToP   noToC   RFC1795 - Page 65
   0x89     N        0x0E        Y         Y       5+   MAC Address
                                                        List

   0x8A     N      <=0x13        Y         Y       5+   NetBIOS Name
                                                        List

   0x8B     N        0x05        Y         Y       5+   Vendor Context

   0xD0     N       varies       Y         Y       5+   Vendor Specific

   *Note: "Repeatable" means a Control Vector is repeatable within a single
   message.

7.6.1  Vendor Id (0x81) Control Vector

   The Vendor Id control vector identifies the manufacturer's IEEE
   assigned Organizationally Unique Identifier (OUI) of the Data Link
   Switch sending the DLSw Capabilities Exchange.  The OUI is sent in
   non-canonical (Token-Ring) format.  This control vector is required
   and must be the first control vector.

   Offset  Length  Value  Contents
   ------  ------  -----  --------
      0       1    0x05   Length of the Vendor Id structured
                          subfield

      1       1    0x81   key = 0x81  that identifies this as the
                          Vendor Id structured subfield

     2-4      3           the 3-byte Organizationally Unique
                          Identifier (OUI) for the vendor
                          (non-canonical format)

7.6.2  DLSw Version (0x82) Control Vector

   The DLSw Version control vector identifies the particular version of
   the DLSw standard supported by the sending Data Link Switch.  This
   control vector is required and must follow the Vendor Id Control
   Vector.

   Offset  Length  Value  Contents
   ------  ------  -----  --------
      0       1    0x04   Length of the Version String structured
                          subfield

      1       1    0x82   key = 0x82  that identifies this as the
                          DLSw Version structured subfield
ToP   noToC   RFC1795 - Page 66
      2       1           the hexadecimal value representing the
                          DLSw standard Version number of the
                          sending Data Link Switch.
                            0x01 (indicates version 1 - closed pages)

      3       1           the hexadecimal value representing the
                          DLSw standard Release number of the
                          sending Data Link Switch.
                            0x00 (indicates release 0)

7.6.3  Initial Pacing Window (0x83) Control Vector

   The Initial Pacing Window control vector specifies the initial value
   of the receive pacing window size for the sending Data Link Switch.
   This control vector is required and must follow the DLSw Version
   Control Vector.

   Offset  Length  Value  Contents
   ------  ------  -----  --------
      0       1    0x04   Length of the Initial Pacing Window
                          structured subfield

      1       1    0x83   key = 0x83  that identifies this
                          as the Initial Pacing Window
                          structured subfield

     2-3      2           the pacing window size, specified
                          in byte normal form..

   Note:  The pacing window size must be non-zero.

7.6.4  Version String (0x84) Control Vector

   The Version String control vector identifies the particular version
   number of the sending Data Link Switch.  The format of the actual
   version string is vendor-defined.  This control vector is optional.

   Offset  Length  Value  Contents
   ------  ------  -----  --------
      0       1    0xn    Length of the Version String
                          structured subfield

      1       1    0x84   key = 0x84  that identifies
                          this as the Version String
                          structured subfield
ToP   noToC   RFC1795 - Page 67
     2-n     n-2          the ASCII string that identifies
                          the software version for the
                          sending DLSw.

7.6.5  MAC Address Exclusivity (0x85) Control Vector

   The MAC Address Exclusivity control vector identifies how the MAC
   Address List control vector data is to be interpreted.  Specifically,
   this control vector identifies whether the MAC addresses in the MAC
   Address List control vectors are the only ones accessible via the
   sending Data Link Switch.

   If a MAC Address List control vector is specified and the MAC Address
   Exclusivity control vector is missing, then the MAC addresses are not
   assumed to be the only ones accessible via this switch.

   A node may specify that it supports no local MAC addresses by
   including in its capabilities the MAC Address List Exclusivity CV
   (with byte 2 == 0x01), and not including any instances of the MAC
   Address List CV.

   Offset  Length  Value  Contents
   ------  ------  -----  --------
      0       1    0x03   Length of the Exclusivity structured
                          subfield

      1       1    0x85   key = 0x85 that identifies this as the
                          MAC address Exclusivity structured
                          subfield

      2       1           an indicator of the relationship of the
                          MAC addresses to the sending Data Link
                          Switch.
                            0x00     the MAC addresses specified in
                                     this Capabilities Exchange
                                     can be accessed via this
                                     switch but are not the
                                     exclusive set (i.e., other
                                     entities are accessible in
                                     addition to the ones specified)
                            0x01     the MAC addresses specified in
                                     this Capabilities Exchange
                                     are the only ones accessible
                                     via this switch.


(next page on part 4)

Next Section