tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 1795

 
 
 

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

Part 4 of 4, p. 68 to 91
Prev RFC Part

 


prevText      Top       Page 68 
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.

Top       Page 69 
                          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

Top       Page 70 
   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

Top       Page 71 
      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)

Top       Page 72 
                            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

Top       Page 73 
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.

Top       Page 74 
   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 |
   +----+----+--------+--------+

Top       Page 75 
   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.

Top       Page 76 
                          (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

Top       Page 77 
   (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

Top       Page 78 
            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

Top       Page 79 
                                    <-----------
         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

Top       Page 80 
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.

Top       Page 81 
   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

Top       Page 82 
   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

Top       Page 83 
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:

Top       Page 84 
          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

Top       Page 85 
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

Top       Page 86 
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

Top       Page 87 
     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!

Top       Page 88 
     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   <------+|

Top       Page 89 
     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

Top       Page 90 
   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.

Top       Page 91 
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.