RFCs in HTML Format


RFC 1434

Network Working Group                                          R. Dixon
Request for Comments: 1434                                     D. Kushi
                                                                    IBM
                                                             March 1993


             Data Link Switching: Switch-to-Switch Protocol

Table of Contents

   1. Introduction                                                     2
   2. Overview                                                         2
   3. Transport Connection                                             4
      3.1. SSP Frame Formats                                           5
      3.2. Address Parameters                                          8
      3.3. Message Types                                              10
   4. Protocol Specification                                          11
      4.1. Protocol Flow Diagrams                                     11
           4.1.1. Connect Protocols                                   11
           4.1.2. Link Restart Protocols                              13
           4.1.3. Disconnect Protocols                                15
      4.2. DLS State Machine                                          16
           4.2.1 Data Link Switch States                              16
           4.2.2 State Transition Tables                              21
      4.3. NetBIOS Datagrams                                          30
   Acknowledgments                                                    32
   References                                                         32
   Security Considerations                                            32
   Authors' Addresses                                                 33




Dixon & Kushi                                                   [Page 1]

RFC 1434 DLS: Switch-to-Switch Protocol March 1993 1. Introduction Data Link Switching (DLS) is a forwarding mechanism for the IBM SNA and IBM NetBIOS protocols. It does not provide full routing, but instead provides switching at the Data Link layer and encapsulation in TCP/IP for transport over the Internet. This memo documents the Switch-to-Switch Protocol (SSP) that is used between IBM 6611 Network Processors. Today, the IBM 6611 supports SNA (PU 2 and PU 4) systems and NetBIOS systems attached to token-ring networks, as well as SNA (PU 2) systems attached to SDLC links. For the later case, the SDLC attached systems are provided with a LAN appearance within the IBM 6611. For the LAN attached systems, the IBM 6611 appears as a source-routing bridge. Remote systems that are accessed through the IBM 6611 appear as systems attached to an adjacent ring. This ring is a virtual ring that is manifested within each IBM 6611. 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 links via the SDLC protocol. IEEE 802.2 LLC Type 2 was designed with the assumption that the network transit delay would be small and predictable (i.e., a local LAN). Therefore the LLC elements of procedure use a fixed timer for detecting lost frames. When 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 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 is eventually taken down. 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 LLC Dixon & Kushi [Page 2]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 Type 1. 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 DLS 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. Bridging -------- Bridge Bridge +------+ +----+ +----+ +------+ | End | +---------+ | +-----/ | | +---------+ | End | |System+-+ LAN +-+ | /------+ +-+ LAN +-+System| | | +---------+ | | TCP/IP | | +---------+ | | +------+ +----+ +----+ +------+ Info-------------------------------------------------------> <-------------------------------------------------------RR Data Link Switching ------------------- +------+ +----+ +----+ +------+ | End | +---------+ | +-----/ | | +---------+ | End | |System+-+ LAN +-+DLS | /------+ DLS+-+ LAN +-+System| | | +---------+ | | TCP/IP | | +---------+ | | +------+ +----+ +----+ +------+ Info-------------------> -------------> Info <-------------------RR ----------------> <----------------RR Figure 1. Data Link Switching Contrasted to Bridging 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 DLS multiplexes LLC connections onto a TCP connection to another DLS. 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 Dixon & Kushi [Page 3]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 back pressure to the end systems to provide flow and congestion control. Data Link Switching uses LAN addressing to set up connections between SNA systems. SDLC attached devices are defined with MAC 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 circuit establishment, SNA systems send TEST (or in some cases, XID) frames to the null (x'00') 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 x'04', x'08', and x'0C'. NetBIOS always uses a link SAP value of x'F0'. 3. Transport Connection Data Link Switches can be in used in pairs or by themselves. A Single DLS internally switches one data link to another without using TCP (DLC(1) to DLC(2) in the figure below). A paired DLS multiplexes data links over a reliable transport using a Switch-to-Switch Protocol (SSP). This RFC will document the frame formats and protocols for this multiplexing 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. +-----------------------------------------------+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 | +-----------------------------------------------+ Figure 2. DLS System Diagram Dixon & Kushi [Page 4]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 Before Data Link Switching can occur between two routers, they must establish a TCP connection between them. Each DLS will maintain a list of DLS capable routers and their status (active/inactive). Once this connection is established, the DLS will employ SSP to establish end-to-end circuits over the transport connection. Within the transport connection is a specific set of DLS message units. The message formats and types for these PDUs 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 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. 3.1. SSP Frame Formats The following diagrams show the two message headers for traffic between Data Link Switches. The control message header is used for all messages except information messages. The information message header is 16 bytes long, and the control message header is 72 bytes long. The first sixteen bytes of the control message header are identical to the information message header. Dixon & Kushi [Page 5]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 CONTROL MESSAGES (72 Bytes) +-----------------------------------------------------------------+ | Version Number Reserved Field | | Message Length ----> . | | Remote Data Link Correlator ----> . | | . . | | Remote DLC Port ID ----> . | | . . | | Reserved Field ----> . | | Message Type Reserved Field | | Protocol ID Header Number | | Header Length ----> . | | Reserved Field ----> . | | Reserved Field Message Type | | Target MAC Address ----> . | | . . | | . . | | Origin MAC Address ----> . | | . . | | . . | | Origin Link SAP Target Link SAP | | Frame Direction Reserved Field | | Message Length ----> . | | DLC Header Length ----> . | | Origin DLC Port ID ----> . | | . . | | Origin Data Link Correlator ----> . | | . . | | Origin Transport ID ----> . | | . . | | Target DLC Port ID ----> . | | . . | | Target Data Link Correlator ----> . | | . . | | Target Transport ID ----> . | | . . | | Reserved Field ----> . | | . . | +-----------------------------------------------------------------+ (Even Byte) (Odd Byte) Dixon & Kushi [Page 6]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 INFORMATION MESSAGE (16 Bytes) +-----------------------------------------------------------------+ | Version Reserved Field | | Message Length ----> . | | Remote Data Link Correlator ----> . | | . . | | Remote DLC Port ID ----> . | | . . | | Reserved Field ----> . | | Message Type Reserved Field | +-----------------------------------------------------------------+ (Even Byte) (Odd Byte) The Version Number is set to x'4B', indicating a numeric value of 75. The Header Length is x'00 48', indicating a numeric value of 72 bytes. The Header Number is x'01', indicating a value of one. The Frame Direction field is set to x'01' for frames sent from the origin DLS to the target DLS, and is set to x'02' for frames sent from the target DLS to the origin DLS. 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 x'01', and are set equal to the Origin Data Link Correlator and Origin DLC Port ID if the Direction Field is set to x'02'. The Protocol ID field is set to x'42', indicating a numeric value of 66 The Message Length field defines the number of bytes within the data field following the header. Note that this value is specified in two different fields of the message header. The DLC Header Length is set to zero for SNA and is set to x'23' 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). The values for the Message Type field are defined in a later section. Note that this value is specified in two different fields of the message header. Dixon & Kushi [Page 7]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 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). DATA LINK ID (14 Bytes) +-----------------------------------------------------------------+ |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 DLS. It consists of a DLC Port ID (4 bytes), and a Data Link Correlator (4 bytes). This value is unique in a single DLS and is assigned locally. The pair of Circuit ID's along with the identifiers of the Data Link Switches, uniquely identify a single end-to-end circuit. Each DLS 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 DLS and target DLS, 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 these two fields, along with the associated values for DLC Port ID Dixon & Kushi [Page 8]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 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 messages all carry the Data Link ID, consisting of the MAC and Link SAP addresses associated with the two end stations. Upon receipt of a CANUREACH message, the target DLS starts a data link for each port, thereby obtaining a Data Link Correlator. If the target station can be reached, an ICANREACH message is returned to the origin DLS containing the Target Circuit ID parameter. Upon receipt, the origin DLS starts a data link and returns the Origin Circuit ID to the target DLS within the REACH_ACK message. If the REACH_ACK message is not successfully received, the target Data Link Switch can obtain the Origin Circuit ID from a subsequent message (i.e., CONTACT, XIDFRAME, or DGRMFRAME). +------------+ +------------+ |Disconnected| |Disconnected| +------------+ CANUREACH (Data Link ID) +------------+ -------------------------------------------------> ICANREACH (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) <------------------------------------------------- Figure 3. DLS Circuits and Connections 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 established, the INFOFRAME messages are exchanged with the shorter Dixon & Kushi [Page 9]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 header. This header contains only the Circuit ID associated with the remote DLS. 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. 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. Command Function Hex Value ------- -------- --------- CANUREACH Can U Reach Station x'03' ICANREACH I Can Reach Station x'04' REACH_ACK Reach Acknowledgment x'05' DGRMFRAME Datagram Frame (See note) x'06' XIDFRAME XID Frame x'07' CONTACT Contact Remote Station x'08' CONTACTED Remote Station Contacted x'09' RESTART_DL Restart Data Link x'10' DL_RESTARTED Data Link Restarted x'11' INFOFRAME Information (I) Frame x'0A' HALT_DL Halt Data Link x'0E' DL_HALTED Data Link Halted x'0F' NETBIOS_NQ NetBIOS Name Query x'12' NETBIOS_NR NetBIOS Name Recognized x'13' DATAFRAME Data Frame (See note) x'14' NETBIOS_ANQ NetBIOS Add Name Query x'1A' NETBIOS_ANR NetBIOS Add Name Response x'1B' Table 1. SSP Message Types Note: Both the DGRMFRAME and DATAFRAME messages are used to carry information received by the DLC entity within UI frames. As will be explained below, 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. 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 Dixon & Kushi [Page 10]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 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. 4. Protocol Specification This section provides a description of the Switch-to-Switch Protocols. Included is a set of high-level protocol flows and a detail set of state transition tables. The states and the protocols are described in terms that are intended to be generic to different platforms. Emphasis of the technical details is to ensure operability of the IBM 6611 with another vendor's implementation. Notes are inserted at points where the IBM 6611 performs local actions that are specific to the AIX platform upon which it operates. 4.1. Protocol Flow Diagrams The switch-to-switch protocols are 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) protocols. In addition, the end systems can establish an end-to-end connection for support of LLC Type 2 (connection oriented) protocols. 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 in defined by the concatenation of the destination MAC address (DA), the source MAC address (SA), the destination link SAP (DSAP) and source link SAP (SSAP). 4.1.1. Connect Protocols The following figure depicts the protocol flows that are used for the establishment of a circuit between a pair of Data Link Switches, followed by the establishment of a connection between the pair of end systems. The figure is drawn assuming that the two end systems are SNA (the protocol flow for NetBIOS systems is described in a later paragraph). Dixon & Kushi [Page 11]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 Data Link Data Link Data Link Data Link Control Switch Switch Control -------------------- -------------------- +------------+ +------------+ |Disconnected| |Disconnected| +------------+ +------------+ Test Command CANUREACH Test Comd. ----------> ---------------------------------------> -------> (DSAP=Null) (DSAP=SSAP) Test Response ICANREACH <--------- Test Response <--------------------------------------- <---------- REACH ACK ---------------------------------------> +------------+ +------------+ |Circuit Est.| |Circuit Est.| +------------+ +------------+ SABME CONTACT ----------> ---------------------------------------> SABME UA -------> <---------- RNR UA <---------- CONTACTED <------- <--------------------------------------- +------------+ +------------+ | Connected | | Connected | +------------+ +------------+ RR <--------- Figure 4. DLS Connect Message Protocols Upon receipt of a Test command from the origin station, the origin DLS will send a CANUREACH (i.e., can you reach) message to the target DLS. If the target DLS is not known to the origin DLS, the CANUREACH message is sent to all remote Data Link Switches defined to the origin DLS. The receipt of the CANUREACH message causes the target DLS to send a Test command searching for the target station. The target station will return a Test response, causing the target DLS to return an ICANREACH (i.e., I can reach) message to the origin DLS. If multiple Data Link Switches can reach the target station, the origin DLS will receive multiple ICANREACH messages. The origin DLS will select the first message and send a REACH_ACK (i.e., reach acknowledgment) message to the selected Data Link Switch. During this exchange of messages, both Data Link Switches change states from the Disconected state to the Circuit Established state. Once the circuit is established, Type-1 frames, such as XID, may be exchanged between the origin and target stations. Dixon & Kushi [Page 12]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 To establish a connection, the origin station sends a SABME command. Upon receipt of this command, the origin DLS will send a CONTACT message to the target DLS and return a UA response to the origin station. To inhibit traffic flow until the connection is established to the remote station, a RNR supervisory frame is sent to the origin station. The CONTACT message will cause the target DLS to send a SABME command to the target station, which in return will reply with a UA response. Upon receipt of the UA response, the target DLS will send a CONTACTED message to the origin DLS. The origin DLS will now send an RR supervisory frame to the origin station. During this exchange of messages, both Data Link Switches change states from the Circuit Established state to the Connected state. For NetBIOS end systems, the protocol flows are similar but employ different frames and SSP messages. Instead of using a Test command frame to initiate the circuit, a NetBIOS system will use a Name Query frame. Receipt of a Name Query frame will cause the Data Link Switch to issue a NETBIOS_NQ message instead of the CANUREACH message. In a like fashion, the Test response is replaced with a Name Recognized frame and the ICANREACH message is replaced with a NETBIOS_NR message. As with the SNA protocol flows, the receipt of a NETBIOS_NR message causes the origin Data Link Switch to respond with a REACH_ACK message. 4.1.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. Dixon & Kushi [Page 13]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 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. DLS Link Restart Message Protocols Upon receipt of a SABME command from the origin station, the origin DLS will send a RESTART_DL message to the target DLS. 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 DLS will issue a DISC command to the target station. The target station is expected to return a UA response. The target DLS will then restart its data link and send an DL_RESTARTED message back to the origin DLS. 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 DLS will send a CONTACT message to the target DLS. If the SABME command 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. Dixon & Kushi [Page 14]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 4.2.2.5 CIRCUIT_ESTABLISHED State Event Action(s) Next State ----- --------- ---------- Receive CONTACT DLC_CONTACT CONTACT_PENDING Receive HALT_DL DLC_HALT_DL HALT_PENDING Receive XIDFRAME DLC_XID Receive DGRMFRAME DLC_DGRM Receive DATAFRAME DLC_DGRM DLC_CONTACTED Send CONTACT CONNECT_PENDING DLC_ENTER_BUSY DLC_ERROR Send HALT_DL DISCONNECT_PENDING DLC_DGRM Send DGRMFRAME DLC_XID Send XIDFRAME The CIRCUIT_ESTABLISHED state is entered by the origin Data Link Switch from the DISCONNECTED state, and by the target Data Link Switch from the CIRCUIT_PENDING state. The state is exited when a connection is started (i.e., DLC receives a SABME command). The next state is CONTACT_PENDING for the target Data Link Switch and CONNECT_PENDING for the origin Data Link Switch. 4.2.2.6 CONTACT_PENDING State Event Action(s) Next State ----- --------- ---------- Receive HALT_DL DLC_HALT_DL HALT_PENDING Receive RESTART_DL DLC_HALT_DL RESTART_PENDING Receive DGRMFRAME DLC_DGRM Receive DATAFRAME DLC_DGRM DLC_CONTACTED Send CONTACTED CONNECTED DLC_ERROR Send HALT_DL DISCONNECT_PENDING DLC_DGRM Send DGRMFRAME The CONTACT_PENDING state is entered by the target Data Link Switch upon the receipt of a CONTACT message. This causes the Data Link Switch to issue a DLC_CONTACT signal to the DLC (i.e., DLC sends a SABME command). This state is then exited upon the receipt of a DLC_CONTACTED signal from the DLC (i.e., a UA response received). If a RESTART_DL message is received, indicating that the remote Data Link Switch has received a DLC_RESET signal, the local Data Link Switch will send a DISC command frame on the adjacent LAN (i.e., DLC_HALT_DL signal) and enter the RESTART_PENDING state. Dixon & Kushi [Page 27]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 4.2.2.7 CONNECTED State Event Action(s) Next State ----- --------- ---------- Receive HALT_DL DLC_HALT_DL HALT_PENDING Receive RESTART_DL DLC_HALT_DL RESTART_PENDING Receive DGRMFRAME DLC_DGRM Receive INFOFRAME DLC_INFO Receive DATAFRAME DLC_DGRM DLC_RESET Send RESTART_DL (See note) CIRCUIT_RESTART DLC_ERROR Send HALT_DL DISCONNECT_PENDING DLC_DGRM Send DGRMFRAME DLC_INFO Send INFOFRAME The CONNECTED state is entered by the origin Data Link Switch from the CONNECT_PENDING state upon the receipt of a CONTACTED message. The CONNECTED state is entered by the target Data Link Switch from the CONTACT_PENDING state upon the receipt of a DLC_CONTACTED signal. At this time, the target Data Link Switch will return a CONTACTED message to the origin Data Link Switch. The CONNECTED state is exited usually under one of two conditions: a DLC_ERROR signal received from the DLC (e.g., a DISC command received by the local DLC), or a HALT_DL message received from the other Data Link Switch (e.g., a DISC command received by the remote DLC). A SABME command (i.e., a DLC_RESET signal) received by either Data Link Switch will also cause the two Data Link Switches to leave the CONNECTED state and eventually restart a new circuit. Note: The IBM 6611 will also send a Test command in order to restart the data link to the station that sent the SABME command (i.e., a DLC_START_DL will be issued). Following the receipt of a reset signal, the Data Link Switch will send a RESTART_DL message to the other Data Link Switch and will enter the CIRCUIT_RESTART state. Upon the receipt of the RESTART_DL message, the remote Data Link Switch will send a DISC command (i.e., DLC_HALT_DL signal) and enter the RESTART_PENDING state. 4.2.2.8 CIRCUIT_RESTART State Event Action(s) Next State ----- --------- ---------- Receive DL_RESTARTED If Connected: If Connected: Send CONTACT CONNECT_PENDING, else: CIRCUIT_ESTABLISHED Receive DATAFRAME DLC_DGRM Dixon & Kushi [Page 28]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 DLC_ERROR Send HALT_DL DISCONNECT_PENDING DLC_DGRM Send DATAFRAME The CIRCUIT_RESTART state is entered if a DLC_RESET signal is received from the local DLC. This was caused by the receipt of a SABME command while a connection was currently active. A DM response will be issued to the SABME command and the Data Link Switch will attempt to restart the end-to- end circuit. The CIRCUIT_RESTART state is exited through one of two transitions. The next state depends upon the time the local DLC has reached the contacted state (i.e., a DLC_CONTACTED signal is presented) relative to the receipt of the DL_RESTARTED message. This signal is caused by the origin station resending the SABME command that initially caused the DATA Link Switch to enter the CIRCUIT_RESTART state. The two cases are as follows: 1) DL_RESTARTED message received before the DLC_CONTACTED signal- In this case, the CIRCUIT_ESTABLISHED state is entered. 2) DL_RESTARTED message received after the DLC_CONTACTED signal- In this case, the CONNECT_PENDING state is entered. 4.2.2.9 DISCONNECT_PENDING State Event Action(s) Next State ----- --------- ---------- Receive DL_HALTED DISCONNECTED Receive HALT_DL Send DL_HALTED Receive DATAFRAME DLC_DGRM DLC_DGRM Send DATAFRAME The DISCONNECT_PENDING state is entered when a DLC_ERROR signal is received from the local DLC. Upon receipt of this signal, a HALT message is sent. Once an DL_HALTED message is received, the state is exited, and the Data Link Switch enters the DISCONNECTED state. 4.2.2.10 RESTART_PENDING State Event Action(s) Next State ----- --------- ---------- Receive DATAFRAME DLC_DGRM DLC_DL_HALTED (See note) Send DL_RESTARTED CIRCUIT_ESTABLISHED DLC_ERROR Send HALT_DL DISCONNECT_PENDING DLC_DGRM Send DATAFRAME Dixon & Kushi [Page 29]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 The RESTART_PENDING state is entered upon the receipt of a RESTART_DL message from the remote DLS while the local Data Link Switch is in either the CONTACT_PENDING state or the CONNECTED state. These cause the local DLC to issue a DISC command. Upon the receipt of the UA response (DLC_DL_HALTED), the data link is restarted, a DL_RESTARTED message is returned to the remote DLS, and the CIRCUIT_ESTABLISHED state is entered. Note: The IBM 6611 will send a Test command in order to restart the data link to the target station (i.e., a DLC_START_DL will be issued) prior to sending the DL_RESTARTED message. 4.2.2.11 HALT_PENDING State Event Action(s) Next State ----- --------- ---------- Receive DATAFRAME DLC_DGRM DLC_DL_HALTED Send DL_HALTED DISCONNECTED DLC_ERROR Send DL_HALTED DISCONNECTED DLC_DGRM Send DATAFRAME The HALT_PENDING state is entered upon the receipt of a HALT_DL message. This causes the local DLC to issue a DISC command. Upon the receipt of the UA response (DLC_DL_HALTED), a DL_HALTED message is returned to the remote DLS and the DISCONNECTED state is entered. 4.3. NetBIOS Datagrams The NetBIOS protocols use a number of UI frames for directory services and the transmission of datagrams. Most of these frames are directed to a group MAC address (GA) with the routing information field indicating spanning tree explorer (STE). Two of the frames, NB_Add_Name_Response and NB_Status_Response, are directed to a specific MAC address with the routing information field indicating a specifically routed frame (SRF). The handling of these frames is summarized in the following table. Event Action(s) Comment ----- --------- ------- DLC_DGRM (NB Group Address): Send NETBIOS_ANQ Transmitted to all NB_Add_Name_Query remote DLS DLC_DGRM (Specific Address): Send NETBIOS_ANR Transmitted to NB_Add_Name_Response specific DLS DLC_DGRM (Specific Address): Send DATAFRAME Transmitted to all NB_Status_Response remote DLS DLC_DGRM (NB Group Address): Send DATAFRAME Transmitted to all NB_Name_in_Conflict, remote DLS NB_Add_Group_Name_Query, Dixon & Kushi [Page 30]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 NB_Datagram, NB_Datagram_Broadcast, NB_Status_Query, NB_Terminate_Trace Table 5. NetBIOS DLC Frames The above actions do not apply in the following states: CIRCUIT_ESTABLISHED, CONTACT_PENDING, CONNECT_PENDING, CONNECTED, and CIRCUIT_PENDING. The handling of the remaining two UI frames used by NetBIOS systems, NB_Name_Query and NB_Name_Recognized, are documented as part of the DLS state machine in the previous section (i.e., DISCONNECTED and RESOLVE_PENDING states). Furthermore, the handling of NetBIOS datagrams (i.e., NB_Datagram) sent to a specific MAC address is also governed by the DLS state machine. Note: The IBM 6611 will also issue Test frames during the exchange of the NetBIOS, NB_Name_Query and NB_Name_Recognized. This exchange of protocol data units occurs during the start of a data link and is used to determine the routing information. Most other implementations of NetBIOS will use the NB_Name_Query/NB_Name_Recognized exchange to determine routes in conjunction with resolving the NetBIOS names. These differences are not reflected in the SSP protocols. The handling of the NetBIOS specific SSP messages is given in the following table. Event Action(s) Comment ----- --------- ------- NETBIOS_ANQ DLC_DGRM: Routed STE NB_Add_Name_Query (NB Group Address) NETBIOS_ANR DLC_DGRM: Routed SRF NB_Add_Name_Response (Specific MAC Address) NETBIOS_NQ DLC_DGRM: Routed STE NB_Name_Query (NB Group Address) NETBIOS_NR DLC_DGRM: Routed SRF NB_Name_Recognized (Specific MAC Address) DATAFRAME DLC_DGRM Routed STE (If NB_Status_Response: Specific MAC Address Else: NB Group Address) Table 6. NetBIOS SSP Messages The above actions apply to all DLS states. The handling of NetBIOS datagrams sent within DGRMFRAME messages is governed by the DLS state machine. The DGRMFRAME message type is employed instead of the Dixon & Kushi [Page 31]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 DATAFRAME message type once the end-to-end circuit has been established. At that time, the message is addressed according to the pair of Circuit IDs in the message header instead of relying upon the MAC address information in the token ring header. Acknowledgments Randall Campbell, David Miller, Gene Cox, Ravi Periasamy, and The Ghost of Christmas Past. References 1) ISO 8802-2/IEEE Std 802.2 International Standard, Information Processing Systems, Local Area Networks, Part 2: Logical Link Control, December 31, 1989 2) The NETBIOS Frames Protocol, IBM Local Area Technical Reference, SC30-3383-03, Chapter 5, December 1990 3) ISO/IEC DIS 10038 DAM 2, MAC Bridging, Source Routing Supplement, December 1991 Security Considerations Security issues are not discussed in this memo. Dixon & Kushi [Page 32]
RFC 1434 DLS: Switch-to-Switch Protocol March 1993 Authors' Addresses Roy C. Dixon IBM Networking Systems Department B57, Building 060 P.O. Box 12195 Research Triangle Park, NC 27709 Phone: (919) 543-3380 EMail: rcdixon@ralvmg.vnet.ibm.com



Back to RFC index

 

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""