RFC 1795
Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1
7.6.6 SAP List Support (0x86) Control Vector The SAP List Support control vector identifies support for Logical Link Control SAPs (DSAPs and SSAPs) by the sending Data Link Switch. This is used by the DLSw that sent the SAP List Support control vector to indicate which SAPs can be used to support SNA and optionally NetBIOS traffic. This may be used by the DLSw that receives the SAP list to filter explorer traffic (TEST, XID, or NetBIOS UI frames) from the DLSw state machine. For SNA, a DLSw should set bits for all SAP values (SSAP or DSAP) that may be used for SNA traffic. For NetBIOS support, the bit for SAP 0xF0 should be set (if not supported then the same bit should be cleared). Each bit in the SAP control vector data field represents a SAP as defined below. This vector is required and must follow the Initial Pacing Window Control Vector. Offset Length Value Contents ------ ------ ----- -------- 0 1 0x12 Length of the Supported SAP List structured subfield 1 1 0x86 key = 0x86 that identifies this as the Supported SAP List structured subfield 2-17 16 the 16-byte bit vector describing all even numbered SAPs enabled. Each Bit within the 16 byte bit vector will indicate whether an even numbered SAP is enabled (b'1') or disabled (b'0'). Each Byte within the 16 byte bit vector will be numbered from 0 - F. (Most significant byte first). Byte 0 1 2 3 ... F XX XX XX XX ... XX The bits in each byte indicate whether an even numbered SAP is enabled (b'1') or disabled (b'0'). (Most significant bit first) Bits 7 6 5 4 ... 0 SAP 0 2 4 6 ... E By combining the byte label with the enabled bits, all supported SAPs can be determined.
In the following diagram, 'n' would equal 0
through F depending on which byte was being
interpreted.
Bit ordering is shown below with bit
7 being the most significant bit and bit
0 the least significant bit.
7654 3210
bbbb bbbb....
|||| ||||
|||| |||SAP 0xnE enabled or not
|||| |||
|||| ||SAP 0xnC enabled or not
|||| ||
|||| |SAP 0xnA enabled or not
|||| |
|||| SAP 0xn8 enabled or not
||||
|||SAP 0xn6 enabled or not
|||
||SAP 0xn4 enabled or not
||
|SAP 0xn2 enabled or not
|
SAP 0xn0 enabled or not
An example of using all User Definable SAPs of 0x04 to 0xEC for SNA Data Link Switching and SAP 0xF0 for NetBIOS Data Link Switching would be as follows: Offset SAPs Binary Hex 0 4,8,C 0010 1010 0x2A 1 10,14,18,1C 1010 1010 0xAA 2 20,24,28,2C 1010 1010 0xAA 3 30,34,38,3C 1010 1010 0xAA 4 40,44,48,4C 1010 1010 0xAA 5 50,54,58,5C 1010 1010 0xAA 6 60,64,68,6C 1010 1010 0xAA 7 70,74,78,7C 1010 1010 0xAA 8 80,84,88,8C 1010 1010 0xAA 9 90,94,98,9C 1010 1010 0xAA A A0,A4,A8,AC 1010 1010 0xAA B B0,B4,B8,BC 1010 1010 0xAA C C0,C4,C8,CC 1010 1010 0xAA D D0,D4,D8,DC 1010 1010 0xAA E E0,E4,E8,EC 1010 1010 0xAA F F0 1000 0000 0x80 7.6.7 TCP Connections (0x87) Control Vector The TCP Connections control vector indicates the support of an alternate number of TCP Connections for the Data Link Switching traffic. The base implementation of Data Link Switching supports two TCP Connections, one for each direction of data traffic. This control vector is optional. If it is omitted in a DLSw Capabilities Exchange, then two TCP Connections are assumed. It is further assumed that if a Data Link Switch can support one TCP Connection, it can support two TCP Connections. If TCP Connections CV values agree and the number of connections is one, then the DLSw with the higher IP address must tear down the TCP connections on its local port 2065. The format of the TCP Connections Control Vector is shown below: Offset Length Value Contents ------ ------ ----- -------- 0 1 0x03 Length of the TCP Connections structured subfield 1 1 0x87 key = 0x87 that identifies this as the TCP Connections structured subfield
2 1 an indicator of the support for an
alternate number of TCP Connections by
the sending Data Link Switch.
0x01 the number of TCP Connections
may be brought down to one
after Capabilities Exchange
is completed.
0x02 the number of TCP Connections
will remain at two for
the duration of the DLSw
connection.
7.6.8 NetBIOS Name Exclusivity (0x88) Control Vector
The NetBIOS Name Exclusivity control vector identifies how the
NetBIOS Name List control vector data is to be interpreted.
Specifically, this control vector identifies whether the NetBIOS
Names in the NetBIOS Name List control vectors are the only ones
accessible via the sending Data Link Switch.
If a NetBIOS Name List control vector is specified and the NetBIOS
Name Exclusivity control vector is missing, then the NetBIOS Names
are not assumed to be the only ones accessible via this switch.
A node may specify that it supports no local NetBIOS names by
including in its capabilities the NetBIOS Name List Exclusivity CV
(with byte 2 == 0x01), and not including any instances of the NetBIOS
Name List CV.
Offset Length Value Contents
------ ------ ----- --------
0 1 0x03 Length of the Exclusivity structured
subfield
1 1 0x88 key = 0x88 that identifies this as the
NetBIOS Name Exclusivity structured
subfield
2 1 an indicator of the relationship of the
NetBIOS Names to the sending Data Link
Switch.
0x00 the NetBIOS Names 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 NetBIOS Names specified in
this Capabilities Exchange
are the only ones accessible
via this switch.
7.6.9 MAC Address List (0x89) Control Vector
The MAC Address List control vector identifies one or more MAC
addresses that are accessible through the sending Data Link Switch.
This control vector specifies a single MAC address value and MAC
address mask value to identify the MAC address or range of MAC
addresses. MAC addresses and masks are in non-canonical (Token-Ring)
format in this control vector.
This control vector is optional and can be repeated if necessary.
Note 1: If a particular MAC address, <mac-addr>, satisfies the
following algorithm, then <mac-addr> is assumed to be accessible via
the sending Data Link Switch:
<mac-addr> & <mac-addr-mask> == <mac-addr-value>
where: <mac-addr-value> is the MAC Address
Value specified in
this control vector
<mac-addr-mask> is the MAC Address
Mask specified in
this control vector
Note 2: If an individual MAC Address is desired, then <mac-addr-
value> should be the individual MAC address and <mac-addr-mask>
should be 0xFFFFFFFFFFFF.
Offset Length Value Contents
------ ------ ----- --------
0 1 0x0E Length of the MAC Address List
structured subfield
1 1 0x89 key = 0x89 that identifies this as the
MAC Address List structured subfield
2-7 6 the 6-byte MAC Address Value,
<mac-addr-value> in the above formula
8-13 6 the 6-byte MAC Address Mask,
<mac-addr-mask> in the above formula
7.6.10 NetBIOS Name List (0x8A) Control Vector The NetBIOS Name List control vector identifies one or more NetBIOS names that are accessible through the sending Data Link Switch. This control vector specifies a single NetBIOS name in ASCII. However, the NetBIOS name can consist of "don't care" and "wildcard" characters to match on a number of NetBIOS names. If an individual character position in the NetBIOS name in this control vector contains a '?', then the corresponding character position in real NetBIOS name is a "don't care". If a NetBIOS name in this control vector ends in '*', then the remainder of real NetBIOS names is a "don't care". '*' is only considered a wildcard if it appears at the end of a name. All blanks or nulls at the end of NetBIOS names in this control vector are ignored. NetBIOS names which have fewer than 16 bytes and which do not end with '*' are not assumed to have a trailing '*'; the "wildcard" character must be explicit. NetBIOS group names can exist across several LANs/networks. As such, NetBIOS group names received in a NetBIOS Name List Control Vector can not be treated the same as NetBIOS individual names. The Individual/Group Flag allows Data Link Switches to distinguish between the two. This control vector is optional and can be repeated if necessary. Offset Length Value Contents ------ ------ ----- -------- 0 1 0xn Length of the NetBIOS Name List structured subfield (maximum = 0x13) 1 1 0x8A key = 0x8A that identifies this as the NetBIOS Name List structured subfield 2 1 Individual/Group Flag 0x00 - Individual NetBIOS Name 0x01 - Group NetBIOS Name 3-n n-3 the NetBIOS name with possible embedded '?' and terminating '*'. 7.6.11 Vendor Context (0x8B) Control Vector The Vendor Context 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 optional and is used to provide the context
for any Vendor Specific control vectors that follow in the
Capabilities Exchange. 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.
Offset Length Value Contents
------ ------ ----- --------
0 1 0x05 Length of the Vendor Context structured
subfield
1 1 0x8B key = 0x8B that identifies this as the
Vendor Context structured subfield
2-4 3 the 3-byte Organizationally Unique
Identifier (OUI) for the vendor
(non-canonical format)
7.7 Capabilities Exchange Responses
There are two kinds of DLSw Capabilities Exchange Responses: positive
and negative. A positive response is returned to the sending Data
Link Switch if there were no errors encountered in the DLSw
Capabilities Exchange Request. A negative response is returned if
there is at least one error encountered.
A positive DLSw Capabilities Exchange Response has the following
overall format:
+----+----+
| LL | ID |
+----+----+
0-1 Length, in binary, of the DLSw Capabilities
Exchange Response GDS Variable. The value of
LL in this case is 0x0004.
2-3 GDS Id: 0x1521
A negative DLSw Capabilities Exchange Response has the following
overall format:
+----+----+--------+--------+
| LL | ID | Offset | Reason |
+----+----+--------+--------+
0-1 Length, in binary, of the DLSw Capabilities Exchange
Response 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 Offsets/Reasons).
2-3 GDS Id: 0x1522
4-5 Offset into the DLSw Capabilities Exchange Request of the
error. Offset should always point to the start of the
GDS Variable or a specific control vector.
6-7 Reason code that uniquely identifies the error. Specific
values for the reason code are:
0x0001 invalid GDS length for a DLSw Capabilities
Exchange Request. (The value of Offset
is ignored.)
0x0002 invalid GDS id for a DLSw Capabilities
Exchange Request. (The value of Offset
is ignored.)
0x0003 Vendor Id control vector is missing. (The
value of Offset is ignored.)
0x0004 DLSw Version control vector is missing. (The
value of Offset is ignored.)
0x0005 Initial Pacing Window control vector is
missing. (The value of Offset is ignored.)
0x0006 length of control vectors doesn't correlate
to the length of the GDS variable
0x0007 invalid control vector id
0x0008 length of control vector invalid
0x0009 invalid control vector data value
0x000A duplicate control vector (for non-repeating
control vectors)
0x000B out-of-sequence control vector (for
repeating control vector)
0x000C DLSw Supported SAP List control vector is
missing.
(The value of Offset is ignored.)
Note: Multiple Offset, Reason pairs can be returned with one pair
for each error encountered.
8. Pacing/Flow Control
This section describes the required Pacing and Flow Control
mechanisms used by a Data Link Switch.
While it is beyond the scope of this document to specify a policy for
how an implementation maps SSP flow control to the native data link
flow control at the edges, the following paragraphs describe a
general philosophical overview of how the mechanism is to be applied.
There are two types of flows which are covered by the flow control
mechanism: connection-oriented and connectionless. In the first,
connection-oriented flows, the implementer is to map the native flow
control mechanism of the two data links at the boundaries to the SSP
flow control mechanism thus presenting an end-to-end flow control
mechanism which "pushes back" all the way to the originating station
in either direction.
However, in the case of connectionless traffic, this is not possible
at the data link level because there is no native flow control
mechanism for connectionless data links. At first glance it is
tempting to allow connectionless traffic to flow the DLSw cloud
unthrottled. However, the rationale for subjecting these flows to
flow control within the DLSw cloud is to "push" the discarding of
frames (should this become necessary) back to the ingress of the DLSw
cloud. This "early discarding" of excessive DATAGRAMs should allow
the cloud to remain deterministic without wasting network bandwidth.
8.1 Basic Overview
Each circuit consists of two data flows, one in each direction. Each
data flow has its own independent flow control mechanism. For each
data flow there is an entity that originates traffic, referred to as
the sender, and a target entity which receives the traffic, referred
to as the receiver.
A sender may only send data when its receiver has granted explicit
permission to send a discrete number of data units. Data units are
defined as either a DGRMFRAME or an INFOFRAME.
The receiver grants permission to send data units by sending a Flow
Control Indicator (FCIND- defined later). The sender must
acknowledge all FCINDs by sending a Flow Control Acknowledgment
(FCACK- defined later).
A sending implementation must maintain these values:
1. GrantedUnits - The number of units (frames) which the sender
currently has permission to send.
2. CurrentWindow - This is a discrete number of units, controlled by
the receiver, which is basis for granting additional units.
3. InitialWindowSize - Global for all circuits on a transport
connection. Learned in capabilities exchange when the transport
connection is established. It specifies an initial value for
CurrentWindow when each circuit is established.
A receiving implementation must maintain these values:
1. CurrentWindow - This is a discrete number of units, controlled by
the receiver, which is basis for granting additional units.
2. InitialWindowSize - Global for all circuits on a transport
connection. Sent in capabilities exchange when the transport
connection is established. It specifies an initial value for
CurrentWindow when each circuit is established.
3. FCACKOwed - The sender owes an FCACK. If true, no FCIND may be
sent.
8.2 Frame Format
The Flow control Byte is contained at offset 15 in both the
Information and Control SSP messages. From a flow control
perspective, the flow control information in the two frames are
handled identically.
The following diagram describes the format of the Flow Control Byte
(Bit 7 is the most significant and Bit 0 is the Least significant bit
of the octet):
bit 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
|FCI|FCA| reserved | FCO |
+---+---+---+---+---+---+---+---+
FCI : Flow Control Indicator
FCA : Flow Control Ack
FCO : Flow Control Operator Bits
000 - Repeat Window Operator
001 - Increment Window Operator
010 - Decrement Window Operator
011 - Reset Window Operator
100 - Halve Window Operator
101 - Reserved
110 - Reserved
111 - Reserved
A frame with the FCI bit set is referred to as a Flow Control
Indication (FCIND). An FCIND is used to manage the flow in the
opposite direction of the frame which bears it.
A frame with the FCA bit set is referred to as a Flow Control
Acknowledgment (FCACK). An FCACK is used to manage the flow in the
same direction of the frame which bears it.
NOTE: A frame may be both a FCIND and an FCACK.
A frame bearing an FCIND or FCACK may also contain data for the flow
in the direction it is traveling. In such a frame, the FCIND or
FCACK are said to be piggy-backed. A non-piggy-backed FCIND is
called an Independent Flow Control Indication (IFCIND) and a non-
piggy-backed FCACK is called an Independent Flow Control
Acknowledgment (IFCACK). IFCIND and IFCACK messages are sent in a
Independent Flow Control SSP message (type 0x21).
NOTE: A frame may be both an IFCIND and an IFCACK.
It is desirable to carry information in control messages so as to
reduce the need to send a flow control only message. The diagram
below shows the messages that may carry valid flow control
information:
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
May have valid
FCI/FCA/FCO Data carrying
N N CANUREACH_cs
----------->
Y* N ICANREACH_cs
<-----------
Y N REACH_ACK
----------->
Y Y XIDFRAMEs
<------------>
Y Y DGRMFRAMEs
<------------>
Y N CONTACT
----------->
Y N CONTACTED
<-----------
Y Y INFOFRAMEs
<------------>
Y N RESTART_DL
----------->
Y N DL_RESTARTED
<-----------
Y N CONTACT
----------->
Y N CONTACTED
<-----------
N N HALT_DL
----------->
N N DL_HALTED
<-----------
*Note: ICANREACH_cs cannot carry FCA, as there could not be an
outstanding FCI.
8.3 Granting Permission to Send Data
A receiver grants a sender permission to send units of data by
sending FCIND. Each FCIND is further qualified by a flow control
operator, which is encoded in the FCO bits of the FCIND header. With
one exception (the Reset Window operator) all operators may be either
piggy-backed or carried in a IFCIND.
The five flow control operators are outlined below:
8.3.1 Repeat Window Operator
This operator is processed as follows:
(CurrentWindow unchanged)
GrantedUnits += CurrentWindow
8.3.2 Increment Window Operator This operator is processed as follows: CurrentWindow++ GrantedUnits += CurrentWindow 8.3.3 Decrement Window Operator This operator is processed as follows: CurrentWindow-- GrantedUnits += CurrentWindow NOTE: This operator may only be sent if CurrentWindow is greater than one. 8.3.4 Reset Window Operator This operator is processed as follows: CurrentWindow = 0; GrantedUnits = 0; NOTE: This operator may only flow on an independent pacing indication (may NOT be piggy-backed). NOTE: After sending this operator, the only legal subsequent operator is Increment Window. 8.3.5 Halve Window Operator This operator shall be processed as follows: IF CurrentWindow > 1 THEN CurrentWindow = CurrentWindow / 2 ENDIF GrantedUnits += CurrentWindow Note: The divide by two operation is an unsigned integer divide (round down) or bit shift right operation. 8.4 Acknowledging a Flow Control Operator Each sender must acknowledge each FCIND with an FCACK which is piggy-backed on the next frame in the opposite direction in all cases except the Reset Window Operator.
The receiver may have no more than one unacknowledged FCIND outstanding at any time with one exception: A Reset Window Operator may be sent while another FCIND is pending acknowledgment. NOTE: The FCI and FCO bits of the FCACK are used independently by the flow in the opposite direction 8.4.1 Acknowledging a Reset Window Operator Since this operator revokes all previously granted units, the sender must acknowledge this FCIND using an IFCACK (Independent Flow Control Acknowledgment). This is the only case where IFCACK is used. Should a sender receive a non-reset FCIND followed by a Reset Window FCIND before acknowledging the first, it only acknowledges the Reset Window. NOTE: The FCI and FCO bits on these frames are used independently by the flow in the opposite direction. 8.5 Capabilities Exchange Initial Window Size When two nodes establish a transport connection, they engage in a capabilities exchange (this is a requirement). Refer to the Capabilities Exchange section 7 for further details. The two nodes are required to exchange the following parameter: InitialWindowSize - This indicates to the partner what the sending flow entity initializes its CurrentWindow value to for each multiplexed circuit subsequently established on that transport connection. This value must be non-zero. 8.6 Circuit Startup Process as follows: CurrentWindow = InitialWindowSize GrantedUnits = 0 NOTE: The InitialWindow Size variable has a scope of one per DLSw transport connection, while CurrentWindow and Granted units are maintained on a per circuit basis. At circuit startup, a sender may not send data units until the receiver grants explicit permission with an FCIND message. This grant may be an independent FCIND message or the FCIND may be piggy-backed on any of the message types
listed in section 8.2. 8.7 Example Receiving Implementations The following two examples illustrate receiving implementations of varying degrees of complexity. These are not meant to be complete implementations but rather serve to illustrate the protocol. NOTE: The examples are independent of the buffering model ( buffers may be deterministicly or statistically committed) NOTE: The examples assume a process model where each event processes to completion without being preempted by another event. 8.7.1 Fixed Pacing Example Consider the following variables, in addition to InitialWindowSize and CurrentWindow and FCACKOwed: GrantDelayed - Boolean GrantedUnits - Outstanding Units The following section describes how various events are processed in this example implementation: 8.7.1.1 Circuit Startup CurrentWindow = InitialWindowSize FCACKOwed = FALSE GrantDelayed = FALSE GrantedUnits = 0 Repeat Window Operator 8.7.1.2 Check Buffers Available Can my implementation afford to grant CurrentWindow just now? 8.7.1.3 Buffers Become Available IF Check Buffers Available THEN Send FCIND( Repeat Window) GrantDelayed = FALSE ELSE Wait on buffers to become available (LIFO) ENDIF
8.7.1.4 Repeat Window Operator IF Check Buffers Available THEN Send FCIND( Repeat Window) ELSE GrantDelayed = TRUE Wait on buffers to become available (FIFO) ENDIF 8.7.1.5 Send FCIND( operator) GrantedUnits += CurrentWindow FCACKOwed = TRUE Encode and Transmit FCIND piggybacked or as IFCIND 8.7.1.6 A Frame Arrives from Sender GrantedUnits--; IF frame is FCACK THEN IF FCACKOwed THEN FCACKOwed = FALSE ELSE Protocol Violation ENDIF ENDIF IF NOT GrantDelayed THEN IF GrantedUnits <= CurrentWindow THEN IF FCACKOwed THEN Protocol Violation ELSE Repeat Window Operator ENDIF ENDIF ENDIF 8.7.2 Adaptive Pacing Example The following example illustrates a receiving implementation that adjusts the window size and granted units based on buffer availability and transport utilization. NOTE: This example ignores other factors which might compel the receiving implementation to adjust the window size (i.e., Outbound queue length, traffic priority, ...) Consider the following variables, in addition to InitialWindowSize, CurrentWindow and FCACKOwed:
GrantDelayed - Boolean
GrantedUnits - Outstanding Units
8.7.2.1 Circuit Startup
CurrentWindow = InitialWindowSize
FCACK = FALSE
GrantDelayed = FALSE
GrantedUnits = 0
Repeat Window Operator
8.7.2.2 Check Buffers Available ( X)
Can my implementation afford to grant X units just now?
8.7.2.3 Buffers Become Available
IF Check Buffers Available THEN
CurrentWindow--;
Send FCIND( Decrement Window)
GrantDelayed = FALSE
ELSE
Wait on buffers to become available (LIFO)
ENDIF
8.7.2.4 Repeat Window Operator
IF Check Buffers Available (CurrentWindow) THEN
Send FCIND( Repeat Window)
ELSE
GrantDelayed = TRUE
Wait on buffers to become available (FIFO)
ENDIF
8.7.2.5 Increment Window Operator
IF Check Buffers Available ( CurrentWindow + 1) THEN
CurrentWindow++
Send FCIND( Increment Window)
ELSE
Repeat Window Operator
ENDIF
8.7.2.6 Send FCIND( operator)
FCACKOwed = TRUE
GrantedUnits += CurrentWindow
Encode and Transmit FCIND piggybacked or as IFCIND
8.7.2.7 An FCACK Arrives from Sender GrantedUnits--; IF NOT FCACKOwed THEN Protocol Violation ENDIF FCACKOwed = FALSE; IF NOT GrantDelayed THEN IF GrantedUnits < CurrentWindow THEN Increment Window Operator ELSE IF GrantedUnits == CurrentWindow THEN Repeat Window Operator END ENDIF 8.7.2.8 A Non-FCACK Frame Arrives from Sender GrantedUnits--; IF NOT GrantDelayed THEN IF FCACKOwed THEN IF GrantedUnits < CurrentWindow THEN Protocol Violation END ELSE IF GrantedUnits <= CurrentWindow THEN Repeat Window Operator ENDIF ENDIF ENDIF
8.8 Adaptive Pacing Example Flow Diagrams 8.8.1 Example Flows from the Above Implementation The following diagram illustrates the use of adaptive pacing (use of Halve Window, and Reset operation are shown in subsequent diagrams). -----SENDER----- ----RECEIVER---- Granted Window Window Granted 0 2 circuit established 2 0 2 2 <-------- FCIND(Rpt) 2 2 1 2 FCACK--------------> 2 1 4 3 <-------- FCIND(Inc) 3 4 3 3 FCACK--------------> 3 3 +- FCIND(Rpt) 3 6 2 3 DATA---|-----------> 3 5 1 3 DATA---|-----------> 3 4 4 3 <------+ 3 3 FCACK--------------> 3 3 6 3 <-------- FCIND(Rpt) 3 6 5 3 FCACK--------------> 3 5 4 3 DATA---------------> 3 4 3 3 DATA---------------> 3 3 +- FCIND(Rpt) 3 6 2 3 DATA---|-----------> 3 5 1 3 DATA---|-----------> 3 4 0 3 DATA---|-----------> 3 3 3 3 <------+ 2 3 FCACK--------------> 3 2 6 4 <-------- FCIND(Inc) 4 6 5 4 FCACK--------------> 4 5 4 4 DATA---------------> 4 4 Waiting on Buffer +- FCIND(Dec) 3 7 3 4 DATA---|-----------> 3 6 2 4 DATA---|-----------> 3 5 1 4 DATA---|-----------> 3 4 0 4 DATA---|-----------> 3 3 3 3 <------+ 2 3 FCACK--------------> 3 2 Waiting on Buffer +- FCIND(Dec) 2 4 1 3 DATA---|-----------> 2 3 0 3 DATA---|-----------> 2 2 2 2 <------+ 1 2 FCACK--------------> 2 1 4 3 <-------- FCIND(Inc) 3 4 3 3 FCACK--------------> 3 3
6 3 <-------- FCIND(Rpt) 3 6
5 3 FCACK--------------> 3 5
4 3 DATA---------------> 3 4
3 3 DATA---------------> 3 3
6 3 <-------- FCIND(Rpt) 3 6
8.8.2 Example Halve Window Flow
The following flow illustrates the use of the Halve Window Operator:
-----SENDER----- ----RECEIVER----
Granted Window Window Granted
0 2 circuit established 2 0
2 2 <-------- FCIND(Rpt) 2 2
1 2 FCACK--------------> 2 1
4 3 <-------- FCIND(Inc) 3 4
3 3 FCACK--------------> 3 3
Resource Shortage
2 3 DATA---------------> 1 2
1 3 DATA---------------> 1 1
0 3 DATA---------------> 1 0
1 1 <-------- FCIND(Hlv) 1 1
0 1 FCACK--------------> 1 0
NOTE: The Halve Window Operator could have been sent before the
granted units fell to zero. The implementer may make a choice based
on the severity of the condition.
8.8.3 Example Reset Window Flows
The following flow diagram illustrates the ResetWindow operation if
the receiver has no FCIND outstanding.
-----SENDER----- ----RECEIVER----
Granted Window Window Granted
0 2 circuit established 2 0
2 2 <-------- FCIND(Rpt) 2 2
1 2 FCACK--------------> 2 1
4 3 <-------- FCIND(Inc) 3 4
3 3 FCACK--------------> 3 3
+- FCIND(Rpt) 3 6
2 3 DATA---|-----------> 3 5
1 3 DATA---|-----------> 3 4
4 3 <------+
3 3 FCACK--------------> 3 3
6 3 <-------- FCIND(Rpt) 3 6
5 3 FCACK--------------> 3 5
Resource shortage!
0 0 <-------- FCIND(Rst) 0 5 (note still
committed)
0 0 IFCACK-------------> 0 0
Condition eases
1 1 <-------- FCIND(Inc) 1 1
0 1 FCACK--------------> 1 0
2 2 <-------- FCIND(Inc) 2 2
1 2 FCACK--------------> 3 4
The next two flows illustrate the Reset Window operation if the
receiver has an outstanding FCIND.
-----SENDER----- ----RECEIVER----
Granted Window Window Granted
0 2 circuit established 2 0
2 2 <-------- FCIND(Rpt) 2 2
1 2 FCACK--------------> 2 1
4 3 <-------- FCIND(Inc) 3 4
3 3 FCACK--------------> 3 3
+- FCIND(Rpt) 3 6
2 3 DATA---|-----------> 3 5
| Resource shortage!
|+-FCIND(Rst) 0 5
1 3 DATA---||----------> 0 4
4 3 <------+|
3 3 FCACK---+----------> 0 3 (Not IFCACK!)
2 3 DATA----|----------> 0 2
0 0 <-------+
0 0 IFCACK-------------> 0 0
Condition eases
1 1 <-------- FCIND(Inc) 1 1
0 1 FCACK--------------> 1 0
2 2 <-------- FCIND(Inc) 2 2
1 2 FCACK--------------> 3 4
-----SENDER----- ----RECEIVER----
Granted Window Window Granted
0 2 circuit established 2 0
2 2 <-------- FCIND(Rpt) 2 2
1 2 FCACK--------------> 2 1
4 3 <-------- FCIND(Inc) 3 4
3 3 FCACK--------------> 3 3
+- FCIND(Rpt) 3 6
2 3 DATA---|-----------> 3 5
| Resource shortage!
|+-FCIND(Rst) 0 5
1 3 DATA---||----------> 0 4
4 3 <------+|
0 0 <-------+
0 0 IFCACK-------------> 0 0
Condition eases
1 1 <-------- FCIND(Inc) 1 1
0 1 FCACK--------------> 1 0
2 2 <-------- FCIND(Inc) 2 2
1 2 FCACK--------------> 3 4
8.9 Other Considerations
8.9.1 Protocol Violations
The following events are considered protocol violations:
1. Sender exceeds granted units or does not acknowledge FCIND on
first frame after its receipt (the receiver can not discern the
difference between the two).
2. Receiver does not follow a Reset Window Operator with an Increment
Window Operator.
3. Receiver has two unacknowledged FCINDs ( other than Reset Window)
outstanding.
4. Receiver sends Decrement Window Operator with a window size of one.
5. Receiver attempts to increment the window size beyond 0xFFFF.
Actions taken in response to protocol violations are left to the
implementation of the node which discovers the violation. If an
implementation chooses to take down the circuit on which the
violation occurred, HALT_DL is the appropriate action.
Acknowledgments
Original RFC 1434 Authors:
Roy C. Dixon, IBM
David M. Kushi, IBM
Chair of APPN Implementers Workshop Data Link Switching Related
Interest Group:
Louise Herndon Wells, Internetworking Technology Institute
Working Group Chairs (and significant contributors to this document):
Connect/Disconnect (State Machines): Steve Klein, IBM
Capabilities Exchange: Wayne Clark, Cisco Systems
Flow Control (Adaptive Pacing): Shannon Nix, Metaplex
Priority/Class of Service: Gene Cox, IBM
Other significant contributors:
Peter Gayek, IBM
Paul Brittain, Data Connection Limited
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) IBM LAN Technical Reference IEEE 802.2 and NETBIOS Application
Program Interfaces SC30-3587-00, December 1993.
3) ISO/IEC DIS 10038 DAM 2, MAC Bridging, Source Routing Supplement,
December 1991.
4) ISO 8802-2/IEEE Std 802.1D International Standard, Information
Processing Systems, Local Area Networks, Part 2: MAC layer
Bridging.
Security Considerations Security issues are not discussed in this memo. Chair's Address Louise Wells Internetwork Technology Institute 2021 Stratford Dr. Milpitas, CA 95035 EMail: lhwells@cup.portal.com Editor's Address Alan K. Bartky Manager of Technology Sync Research Inc. 7 Studebaker Irvine, CA 91728-2013 Phone: 1-714-588-2070 EMail: alan@sync.com Note: Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: aiw-dlsw@networking.raleigh.ibm.com. This address will be used to coordinate the handling of responses. NOTE 1: This is a widely subscribed mailing list and messages sent to this address will be sent to all members of the DLSw mailing list. For specific questions relating to subscribing to the AIW and any of it's working groups send email to: appn@vnet.ibm.com Information regarding all of the AIW working groups and the work they are producing can be obtained by copying, via anonymous ftp, the file aiwinfo.psbin or aiwinfo.txt from the Internet host networking.raleigh.ibm.com, located in directory aiw. NOTE 2: These mailing lists and addresses are subject to change.