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 RFC1434 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