Редактирование: Документ:Спецификация протокола DDCMP

    DECnet

                     DIGITAL Network Architecture

                              D D C M P

                       Functional Specification

                               Phase IV
                             Version 4.1
                             August, 1984



                                              .-------.                     
                                              `======='                     
         .------.        .---.        .-------.  | |  .-------.
         `======'        `==='        `======='  | |  `=======' 
             \\ ..|        |\             \\ \   | |   / /
              \...|      .-----.          .-------------.
            ......|      |      \         \              \
          .-------.      .-------.        o\.--------------. o
          `--/ /--'      `---|\--'      o   `-----\\ \-----'     o
            / /              | \      o            \\ \              o
           / /               |  \   O               \\ \                  O
       ------------.   .----------------.       .-----------------.
                  /|   |                 \       \                 \
                 /     |                  \    \  \                  \      
                /.-----|                   \------.\                   \
               / `-----|                    \-----' \                    \
      --------. /      .---------------------.    \ .----------------------.
        /     |        |                     |     \|         \   \        |
       / /----'        `---------------------'      `--------\ \   \-------'
      / /                                                     \ \   \
     / /                                                       \ \   \
      /                                              .------------------------
     /                                              |\                      
                                                      
                                                    \  \
                                                     \
                                                      \  \
                                                       \
                                                        \  \
                                                         \
                                                          \  \
                                                           \  .----------------
                                                            \ |          \     
                                                             \|        \  \   
                                                              `---------\  \   
�                                                                Page 2


                               ABSTRACT

               The Digital Data Communications  Message
               Protocol  (DDCMP) is a data link control
               procedure that ensures a  reliable  data
               communication path between communication
               devices connected by data links.   DDCMP
               has  been designed to operate over full-
               and    half-duplex    synchronous    and
               asynchronous     channels     in    both
               point-to-point and multipoint modes.  It
               can be used in a variety of applications
               such as distributed computer networking,
               host/front-end     processing,    remote
               terminal concentration, and  remote  job
               entry-exit system operation.

               This document describes  the  functions,
               characteristics,    capabilities,    and
               operation of  DDCMP.   It  is  primarily
               intended   to   assist   the  individual
               implementing DDCMP within a system.   It
               is  structured, however, to also provide
               general   information   describing   the
               protocol  for  others  who may need this
               level  of  information.    It   is   not
               intended  to  instruct  those unfamiliar
               with    the    principles    of     data
               communications.


                    DIGITAL EQUIPMENT CORPORATION

                     MAYNARD, MASSACHUSETTS 01754








        Copyright (C) 1980, 1982 Digital Equipment Corporation


This material may be copied, in whole or in part,  provided  that  the
above  copyright  notice  is  included  in  each  copy  along  with an
acknowledgment that the  copy  describes  protocols,  algorithms,  and
structures developed by Digital Equipment Corporation.

This material may be  changed  without  notice  by  Digital  Equipment
Corporation,  and Digital Equipment Corporation is not responsible for
any errors which may appear herein.
�                                                                Page 3


                                   CONTENTS

        1       INTRODUCTION . . . . . . . . . . . . . . . . . . . . 7
        2       FUNCTIONAL DESCRIPTION . . . . . . . . . . . . . . . 7
        2.1       RELATIONSHIP TO DECNET . . . . . . . . . . . . . . 8
        2.2       FEATURES . . . . . . . . . . . . . . . . . . . . . 8
        2.3       OPERATING REQUIREMENTS . . . . . . . . . . . . . . 9
        2.3.1       Goals  . . . . . . . . . . . . . . . . . . . . . 9
        2.3.2       Restrictions . . . . . . . . . . . . . . . . .  10
        2.4       DATA LINK FUNCTIONS  . . . . . . . . . . . . . .  11
        2.5       FUNCTIONAL ORGANIZATION  . . . . . . . . . . . .  12
        2.5.1       Framing Component  . . . . . . . . . . . . . .  12
        2.5.1.1       Bit Synchronization  . . . . . . . . . . . .  13
        2.5.1.2       Byte Synchronization . . . . . . . . . . . .  13
        2.5.1.3       Message Synchronization  . . . . . . . . . .  13
        2.5.2       Link Management Component  . . . . . . . . . .  13
        2.5.3       Message Exchange Component . . . . . . . . . .  14
        2.5.3.1       Negative Acknowledgement (NAK) . . . . . . .  15
        2.5.3.2       Reply To Message Number (REP)  . . . . . . .  16
        2.5.3.3       Pipelining . . . . . . . . . . . . . . . . .  16
        2.5.3.4       Piggybacking . . . . . . . . . . . . . . . .  16
        2.5.3.5       ACK Implied In NAK . . . . . . . . . . . . .  17
        2.5.3.6       Initialization . . . . . . . . . . . . . . .  17
        3       INTERFACES . . . . . . . . . . . . . . . . . . . .  17
        3.1       USER INTERFACE . . . . . . . . . . . . . . . . .  17
        3.1.1       Commands To DDCMP  . . . . . . . . . . . . . .  18
        3.1.2       Responses From DDCMP . . . . . . . . . . . . .  19
        3.2       DEVICE DRIVER INTERFACE  . . . . . . . . . . . .  19
        3.2.1       Commands To The Driver . . . . . . . . . . . .  20
        3.2.2       Responses From The Driver  . . . . . . . . . .  21
        3.2.3       Initialization And Management Interface  . . .  21
        4       MESSAGE FORMATS  . . . . . . . . . . . . . . . . .  23
        4.1       NOTATION . . . . . . . . . . . . . . . . . . . .  24
        4.2       DATA MESSAGES  . . . . . . . . . . . . . . . . .  25
        4.3       CONTROL MESSAGES . . . . . . . . . . . . . . . .  27
        4.3.1       Acknowledge Message (ACK)  . . . . . . . . . .  28
        4.3.2       Negative Acknowledge Message (NAK) . . . . . .  29
        4.3.3       Reply To Message Number (REP)  . . . . . . . .  30
        4.3.4       Start Message (STRT) . . . . . . . . . . . . .  31
        4.3.5       Start Acknowledge Message (STACK)  . . . . . .  32
        4.4       MAINTENANCE MESSAGES . . . . . . . . . . . . . .  33
        5       OPERATION  . . . . . . . . . . . . . . . . . . . .  34
        5.1       FRAMING  . . . . . . . . . . . . . . . . . . . .  34
        5.1.1       Byte Framing . . . . . . . . . . . . . . . . .  34
        5.1.1.1       Asynchronous Links . . . . . . . . . . . . .  34
        5.1.1.2       Synchronous Links  . . . . . . . . . . . . .  35
        5.1.1.3       Parallel Links . . . . . . . . . . . . . . .  36
        5.1.2       Message Framing  . . . . . . . . . . . . . . .  36
        5.1.2.1       CRC Performance Option . . . . . . . . . . .  37
        5.1.3       Synchronization  . . . . . . . . . . . . . . .  37
        5.1.3.1       Receiver Synchronization . . . . . . . . . .  37
        5.1.3.2       Transmitter Synchronization  . . . . . . . .  38
        5.1.3.3       Synchronization Rules  . . . . . . . . . . .  39
        5.2       LINK MANAGEMENT  . . . . . . . . . . . . . . . .  41
�                                                                Page 4


        5.2.1       Link Management On Full-Duplex Point-To-Point 
                    Links  . . . . . . . . . . . . . . . . . . . .  42
        5.2.2       Link Management On Half-Duplex Point-To-Point 
                    Links  . . . . . . . . . . . . . . . . . . . .  42
        5.2.3       Link Management On Full-Duplex Multipoint Links 43
        5.2.4       Link Management On Half-Duplex Multipoint Links 44
        5.2.5       Link Management Summary Rules  . . . . . . . .  45
        5.3       MESSAGE EXCHANGE . . . . . . . . . . . . . . . .  47
        5.3.1       Initialization . . . . . . . . . . . . . . . .  47
        5.3.2       Reply Time-outs  . . . . . . . . . . . . . . .  47
        5.3.2.1       Reply Timer Interval . . . . . . . . . . . .  48
        5.3.3       Valid Messages . . . . . . . . . . . . . . . .  49
        5.3.4       Message Exchange Variables And States  . . . .  49
        5.3.4.1       Data Variables . . . . . . . . . . . . . . .  50
        5.3.4.2       Control Flag Variables . . . . . . . . . . .  50
        5.3.4.3       DDCMP States . . . . . . . . . . . . . . . .  51
        5.3.5       Message Queueing, Reply Timers, And Buffering   52
        5.3.6       Reply Timer Operation Rules  . . . . . . . . .  53
        5.3.6.1       Start Timer: . . . . . . . . . . . . . . . .  53
        5.3.6.2       Stop Timer:  . . . . . . . . . . . . . . . .  53
        5.3.7       NAK Reasons  . . . . . . . . . . . . . . . . .  54
        5.3.8       Start-Up . . . . . . . . . . . . . . . . . . .  54
        5.3.9       Data Transfer  . . . . . . . . . . . . . . . .  55
        5.4       MAINTENANCE MODE . . . . . . . . . . . . . . . .  61
        6       ERROR RECORDING  . . . . . . . . . . . . . . . . .  63
        6.1       STRUCTURE OF THE COUNTERS  . . . . . . . . . . .  64
        6.2       DATA LINK COUNTERS . . . . . . . . . . . . . . .  64
        6.2.1       Data Errors Outbound . . . . . . . . . . . . .  65
        6.2.1.1       NAKs Received Header Block Check Error . . .  65
        6.2.1.2       NAKs Received Data Field Block Check Error .  65
        6.2.1.3       NAKs Received REP Response . . . . . . . . .  65
        6.2.2       Data Errors Inbound  . . . . . . . . . . . . .  65
        6.2.2.1       Header Block Check Errors  . . . . . . . . .  65
        6.2.2.2       NAKs Sent Data Field Block Check Error . . .  65
        6.2.2.3       NAKs Sent REP Response . . . . . . . . . . .  66
        6.2.3       Local Reply Timeouts . . . . . . . . . . . . .  66
        6.2.4       Remote Reply Timeouts  . . . . . . . . . . . .  66
        6.2.5       Local Buffer Errors  . . . . . . . . . . . . .  66
        6.2.5.1       NAKs Sent Buffer Temporarily Unavailable . .  66
        6.2.5.2       NAKs Sent Buffer Too Small . . . . . . . . .  66
        6.2.6       Remote Buffer Errors . . . . . . . . . . . . .  67
        6.2.6.1       NAKs Received Buffer Temporarily Unavailable  67
        6.2.6.2       NAKs Received Buffer Too Small . . . . . . .  67
        6.2.7       Selection Timeouts . . . . . . . . . . . . . .  67
        6.2.7.1       No Reply To Select . . . . . . . . . . . . .  67
        6.2.7.2       Incomplete Reply To Select . . . . . . . . .  68
        6.2.8       Data Messages Transmitted  . . . . . . . . . .  68
        6.2.9       Data Messages Received . . . . . . . . . . . .  68
        6.2.10      Selection Intervals  . . . . . . . . . . . . .  68
        6.2.11      Data Bytes Transmitted . . . . . . . . . . . .  68
        6.2.12      Data Bytes Received  . . . . . . . . . . . . .  69
        6.3       STATION COUNTERS . . . . . . . . . . . . . . . .  69
        6.3.1       Remote Station Errors  . . . . . . . . . . . .  69
        6.3.1.1       NAKs Received Receive Overrun  . . . . . . .  69
        6.3.1.2       NAKs Sent Message Header Format Error  . . .  69
�                                                                Page 5


        6.3.1.3       Selection Address Errors . . . . . . . . . .  69
        6.3.1.4       Streaming Tributaries  . . . . . . . . . . .  70
        6.3.2       Local Station Errors . . . . . . . . . . . . .  70
        6.3.2.1       NAKs Sent Receive Overrun  . . . . . . . . .  70
        6.3.2.2       Receive Overruns, NAK Not Sent . . . . . . .  70
        6.3.2.3       Transmit Underruns . . . . . . . . . . . . .  70
        6.3.2.4       NAKs Received Message Header Format Errors .  71
        6.4       THRESHOLD ERROR COUNTERS . . . . . . . . . . . .  71
        6.4.1       Transmit Threshold Errors  . . . . . . . . . .  71
        6.4.2       Receive Threshold Errors . . . . . . . . . . .  72
        6.4.3       Selection Threshold Errors . . . . . . . . . .  72
        6.5       NETWORK MANAGEMENT INTERFACE SUPPORTING THE DDCMP 
                  COUNTERS . . . . . . . . . . . . . . . . . . . .  72
        6.5.1       Read Data Link Counters (ADDR) . . . . . . . .  73
        6.5.2       Read And Clear Data Link Counters (ADDR) . . .  73
        6.5.3       Read Station Counters  . . . . . . . . . . . .  73
        6.5.4       Read And Clear Station Counters  . . . . . . .  73
        6.6       SUMMARY  . . . . . . . . . . . . . . . . . . . .  74
        7       EVENT LOGGING  . . . . . . . . . . . . . . . . . .  75
        7.1       LOCALLY-INITIATED STATE CHANGE . . . . . . . . .  75
        7.2       REMOTELY INITIATED STATE CHANGE  . . . . . . . .  76
        7.3       STRT RECEIVED WHILE IN MAINTENANCE . . . . . . .  76
        7.4       TRANSMIT ERROR THRESHOLD REACHED . . . . . . . .  77
        7.5       RECEIVE ERROR THRESHOLD REACHED  . . . . . . . .  77
        7.6       SELECTION ERROR THRESHOLD REACHED  . . . . . . .  77
        7.7       MESSAGE HEADER FORMAT ERRORS . . . . . . . . . .  78
        7.8       SELECTION ADDRESS ERRORS . . . . . . . . . . . .  78
        7.9       STREAMING TRIBUTARIES  . . . . . . . . . . . . .  78
        7.10      NAKS SENT BUFFER TOO SMALL . . . . . . . . . . .  79


APPENDIX A      GLOSSARY


APPENDIX B      FORMAL SYNTAX DEFINITION

        B.1     SYMBOLOGY  . . . . . . . . . . . . . . . . . . . . B-1
        B.2     MESSAGE SYNTAX . . . . . . . . . . . . . . . . . . B-1


APPENDIX C      MESSAGE FORMAT SUMMARY

        C.1     GENERAL MESSAGE FORMATS  . . . . . . . . . . . . . C-1
        C.2     UNNUMBERED MESSAGE SUMMARY . . . . . . . . . . . . C-1


APPENDIX D      DDCMP BLOCK CHECK COMPUTATION

        D.1     DDCMP ERROR DETECTION  . . . . . . . . . . . . . . D-1
        D.2     THE CRC-16 POLYNOMIAL  . . . . . . . . . . . . . . D-1
        D.3     CRC COMPUTATION  . . . . . . . . . . . . . . . . . D-2
�                                                                Page 6


APPENDIX E      EXAMPLES

        E.1     EXAMPLE 1 - START-UP SEQUENCE WITH NO ERRORS . . . E-1
        E.2     EXAMPLE 2 - START-UP SEQUENCE WITH ERRORS  . . . . E-2
        E.3     EXAMPLE 3 - DATA TRANSFER WITH NO ERRORS . . . . . E-3
        E.4     EXAMPLE 4 - DATA TRANSFER WITH CRC ERRORS AND 
                NAKING . . . . . . . . . . . . . . . . . . . . . . E-4
        E.5     EXAMPLE 5 - DATA TRANSFER WITH ERRORS CAUSING 
                REPLY TIMEOUTS . . . . . . . . . . . . . . . . . . E-5


APPENDIX F      REVISION HISTORY


TABLES

        1       Summary of Synchronization Rules . . . . . . . . .  39
        2       Link Management Summary  . . . . . . . . . . . . .  45
        3       Startup State Table  . . . . . . . . . . . . . . .  56
        4       RUNNING State Table  . . . . . . . . . . . . . . .  59
        5       Maintenance State Table  . . . . . . . . . . . . .  63
        6       DDCMP Counters . . . . . . . . . . . . . . . . . .  74
�Introduction                                                    Page 7


1  INTRODUCTION

In the design of computer communications networks, one  of  the  basic
considerations  is the physical transmission of data from one computer
to  another  over  a  physical  data  channel.   In  the  absence   of
transmission errors, this task becomes relatively simple.  Once errors
are introduced, however, data sequencing and synchronization  problems
occur  between  the  transmitter  and receiver.  The solution to these
problems consists of a data link control procedure  or  communications
protocol  that  ensures  the  correct sequencing and integrity of data
transmitted between computers over a data link.

Digital  Equipment  Corporation  recognized  the  need  for   such   a
communications  protocol  to  establish  reliable computer-to-computer
communications.  A standard protocol was designed to serve  the  needs
of  interprocessor  communications.   That protocol has been named the
Digital Data Communications Message  Protocol  (DDCMP)  and  has  been
adopted  as a Digital Equipment Corporation standard for intercomputer
data communications.



2  FUNCTIONAL DESCRIPTION

The Digital Data Communications Message Protocol (DDCMP)  is  designed
for use over communication channels to provide data integrity, message
sequencing, and management of  the  physical  channel.   The  protocol
defines  the  structure,  content,  and  sequencing procedures for the
transmission of data between computers and  the  techniques  used  for
error  detection  and  recovery.   DDCMP  resides at a level above the
communication medium (i.e., the physical transmission of bits over the
communication   channel).    DDCMP   is  concerned  with  the  logical
transmission of data  grouped  into  physical  blocks  known  as  data
messages.   The  primary function of the protocol is to exchange these
data messages while ensuring their correct  sequencing  and  integrity
when sent over communication channels.

Computers adhering to the protocol will be able to correctly  exchange
data (between their respective address spaces) over a link.  It is the
level above the protocol  that  is  concerned  with  the  meaning  and
understanding  of  this  data  once  correctly exchanged.  With remote
entry stations and concentrators,  this  includes  device  addressing,
device  control,  and  data  formatting.   With  computer networks, it
includes problems of network routing,  process  synchronization,  link
multiplexing, flow control, and network management.

Programs wishing to communicate using DDCMP must agree on  the  syntax
and  semantics  of  the  data  transmitted  within the DDCMP envelope.
DDCMP may thus be  viewed  as  a  black  box  creating  an  error-free
sequential  communication path over which data may be transmitted.  On
multipoint links, DDCMP creates multiple sequential data paths between
the  control station and the multiple tributaries on the link.  If the
physical channel connecting two  communicating  computers  were  truly
error-free, much of DDCMP would not be necessary.
�Functional Description                                          Page 8


2.1  RELATIONSHIP TO DECNET

DECnet is a family of  hardware  and  software  products  that  create
distributed  computer  communication  networks using Digital computers
and their  interconnecting  data  links.   DECnet  creates  a  general
mechanism   for   sharing   resources   and   providing   interprogram
communications  within  a  distributed  data  processing  environment.
DECnet  implementations  adhere  to a common network architecture that
defines the structure and  protocols  each  must  use  to  communicate
through  the  network.  The Digital Network Architecture (DNA) defines
this common structure.

The DNA structure is based on a  hierarchy  of  communication  layers.
That  is,  each layer is built upon the layers beneath it.  The lowest
layer is the physical link or media over which bits  are  transmitted.
The  highest  layer  is  the  user  service  or  application  program.
Intermediate layers perform such functions as error  detection,  error
recovery,   routing,   sequencing,   flow   control,   and  connection
management.  More details on the DNA/DECnet structure can be found  in
current DECnet literature.

The DDCMP protocol creates and supports the functions of the Data Link
Layer  within  the  DECnet  architecture.  This layer provides control
over the physical link operation and ensures both data  integrity  and
the sequentiality of data transmitted over a single physical link.  It
should be noted that DECnet is  not  a  part  of  the  DDCMP  standard
specification  and  that  DDCMP  may be used, independently, in a wide
variety of systems and environments where error-free communication  is
desired.



2.2  FEATURES

DDCMP includes the following features:

     a.  Error detection using the 16-bit, CRC-16,  cyclic  redundancy
         check error detection polynomial.

     b.  Error correction by retransmission.

     c.  Message sequencing, with up to 255 outstanding  messages  for
         pipelining.

     d.  Operation that  is  independent  of  the  channel  bit  width
         (serial   or   parallel)   and  transmission  characteristics
         (asynchronous and synchronous).  DDCMP will  operate  with  a
         wide  variety  of  communication  hardware  (e.g.,  character
         interrupt and block transfer or DMA) and modems.

     e.  Common operation over full- and  half-duplex,  point-to-point
         and multipoint channels.

     f.  A positive start-up procedure that synchronizes both ends  of
         the link.
�Functional Description                                          Page 9


     g.  Simplicity and efficiency with only a few message formats.

     h.  A maintenance mode for diagnostic testing  and  bootstrapping
         functions.

     i.  Data transparency of any bit sequence using  a  length  field
         framing technique.




2.3  OPERATING REQUIREMENTS

DDCMP is designed to serve the needs of interprocessor  communications
in  a  wide  variety  of  applications  and  environments.  DDCMP will
provide:

     a.  High Performance - DDCMP provides  high  data  throughput  on
         links   capable  of  such  and  makes  optimum  use  of  link
         characteristics.

     b.  Wide  Applicability  -  DDCMP  ensures  operation   that   is
         independent  of  channel  type  over  a  wide range of system
         configurations.

     c.  Use of Available Hardware - DDCMP is  able  to  operate  with
         most currently available communications equipment.




2.3.1  Goals - In addition to ensuring the error-free transmission  of
data, DDCMP is designed to meet specific performance and compatibility
requirements.  These goals are:

     a.  Create  a  protocol  for  the  transmission  of   data   over
         communication links to provide for the correct sequencing and
         integrity of the data transmitted (even  when  the  link  may
         distort the information).

     b.  Operate  over  a  wide  variety  of  communications   devices
         available  on  micro,  mini, and maxi computers in bit-serial
         (asynchronous and synchronous) and bit-parallel modes.

     c.  Operate over point-to-point and multipoint circuits  in  both
         full-  and  half-duplex  modes using a common set of messages
         and operating procedures.

     d.  Provide   for   the   efficient   transmission   of    binary
         (transparent) data.

     e.  Ensure both high performance and simultaneous operation  over
         full-duplex   channels  where  long  circuit  delays  may  be
         encountered.
�Functional Description                                         Page 10


     f.  Provide error recording and  reporting  features  so  that  a
         degraded  link  can  be  detected  and repaired prior to link
         failure.

     g.  Provide a positive indication (and synchronization) that  the
         protocol   module   on   the   other  end  of  the  link  has
         re-initialized or started.

     h.  Provide a basic operational mode  for  maintenance  functions
         such as bootstrapping and diagnostic testing.

     i.  Provide a rigid enough protocol so that  all  implementations
         on  the  same channel type will operate together, independent
         of implementation techniques.

     j.  Create a protocol to minimize  the  memory  requirements  and
         execution time in the systems implementing the protocol.

     k.  Create a protocol that allows the physical characteristics of
         the channel to become transparent to the user.




2.3.2  Restrictions - Even though DDCMP  is  a  general  purpose  link
protocol  offering high performance over a wide range of applications,
there are a number of situations in which it may not be optimal.  Some
of these restrictions are:

     a.  DDCMP accepts data in blocks that are  a  multiple  of  8-bit
         bytes.  Within a data block, a user can interpret the data in
         any manner (e.g., 5-bit quantities), but the total block must
         be a multiple of 8 bits.

     b.  DDCMP may not be optimal when operating on  links  with  long
         propagation  delays and a high probability of error.  Optimal
         techniques  in  these  cases  might  include  forward   error
         correction  and/or  single  message  retransmission.  When an
         error occurs, DDCMP must  go  back  to  the  last  sequential
         correct  message,  thereby losing any pipelining in effect on
         the link.

     c.  DDCMP may not be suitable in some multipoint  systems  having
         many  tributaries  with  low  utilization  and  fast response
         requirements.  Optimal techniques  might  include  contention
         selection  and  broadcast.   DDCMP  uses  a polling selection
         mechanism, which in some  environments  may  result  in  long
         response times.

     d.  On multipoint links, DDCMP supports  only  a  single  control
         station.   No  messages  can  be  exchanged  directly between
         tributaries.  Within a given system, the control station  can
         not float among the tributaries.
�Functional Description                                         Page 11


     e.  On  multipoint  links  there  is  no  broadcast  or  multiple
         addressing facility.

     f.  There is no shut down capability within the protocol.  It  is
         the  user  responsibility,  at  higher  levels,  to  complete
         communications and shut down the link.




2.4  DATA LINK FUNCTIONS

The DDCMP protocol is an extension of the  data  communications  link,
providing  a  number  of functions to the user of the protocol.  DDCMP
may be viewed as a  black  box  creating  an  error-free,  sequential,
managed data link.  On the transmit side, messages are given to DDCMP,
which delivers them over the link  and  notifies  the  user  when  the
delivery  has  successfully  occurred.   On the receive side, the user
provides buffers which are filled with correctly received messages  by
DDCMP.   The  term  "user" refers to the process or program exchanging
messages with the protocol.  In DECnet, it will be the  higher  levels
in  the  DNA  structure.  In other systems or structures it might be a
service  process  or  the  end-user  directly.   DDCMP   extends   the
capabilities  of  a  physical  data  link  to  include  the  following
features:

     a.  Creates  an  error-free  data  path.   DDCMP  transfers  data
         between   protocol   users   over   a  physical  link,  while
         maintaining data integrity within some very small  undetected
         error  probability.   If data integrity cannot be maintained,
         no data will be transferred.

     b.  Transfers messages in  proper  sequence.   Messages  will  be
         delivered  from  one  user  to the other in the same order as
         they are sent, even though  DDCMP  may  require  the  use  of
         retransmission or other error recovery techniques.

     c.  Manages the characteristics of the channel.  If  the  channel
         requires    receiver   addressing   and/or   arbitration   of
         transmission  requests,  DDCMP  is   responsible   for   that
         management.

     d.  Interfaces to modem control signals.   DDCMP  must  interface
         with  signals  necessary  for  the  operation of the physical
         channel, (e.g., modem control signals not  handled  by  other
         components in the system).  It may do this directly, leave it
         up to the hardware device driver, or  let  the  user  of  the
         modem control code control these signals through the protocol
         interface.

     e.  Accesses data in blocks consisting of byte quantities.  DDCMP
         accepts  data  in  blocks consisting of 8-bit bytes.  All 256
         8-bit combinations  are  transmittable,  and  transparent  to
         DDCMP.   The protocol will allow blocks of up to 16,383 bytes
         to be  transmitted.   However,  the  CRC-16  error  detection
�Functional Description                                         Page 12


         polynomial  used is most effective with blocks no longer than
         4093 bytes.

     f.  Provides restart  or  initialization  notification.   If  the
         other  end  of  the  link  resets  or initializes, DDCMP will
         notify the user.

     g.  Provides start and  stop  control.   The  user  controls  the
         protocol and can start (or re-initialize), and stop (or halt)
         the operation of DDCMP.

     h.  Provides notification of channel error.   When  a  persistent
         error  is detected, the user is notified of such a condition.
         Such errors might be:
         1.  too high a block error rate;
         2.  outages;
         3.  nonexistent communications;
         4.  modem failure.

     i.  Provides a maintenance mode.  DDCMP creates a  data  envelope
         with   bit   error-detection-only   capability   for  use  in
         diagnostic testing and system bootstrapping functions.




2.5  FUNCTIONAL ORGANIZATION

From an operational viewpoint,  DDCMP  consists  of  three  functional
components:

     1.  Framing,

     2.  Link Management,

     3.  Message Exchange.

The following  provide  a  generic  model  describing  each  of  these
components.   This  model is helpful in understanding DDCMP operation.
It is provided as an aid in  implementation  design  (by  enabling  an
individual  to understand the protocol, its operational intentions and
motivations).  It is  not  intended  to  describe  specific  operating
details of DDCMP or subsets of DDCMP.  For specific information on the
actual protocol operation, refer to subhead 5.



2.5.1  Framing Component - Framing is  the  process  of  locating  the
beginning  and  end  of  a  message,  at  the receiving end of a link.
Synchronization is the process of locating some entity (e.g., a bit or
byte)  and  then staying in step or operating at the same rate as that
entity.  Synchronization of data on a link  must  occur  at  the  bit,
byte,  and  message  levels  before  framing can be accomplished.  The
following paragraphs describe how DDCMP  provides  synchronization  at
these levels:
�Functional Description                                         Page 13


2.5.1.1  Bit Synchronization - Locating  a  bit  on  the  link.   This
function  is  accomplished by the modems or interfaces on the link and
is not a part of DDCMP.  This makes the protocol  independent  of  the
physical characteristics of the data link.



2.5.1.2  Byte  Synchronization - Grouping   bits   into   8-bit   byte
quantities.   Byte  synchronization  is  the  process  of locating the
proper 8-bit window in the bit stream and then staying in step with it
for  every  8-bit  byte  grouping.   On 8-bit asynchronous links, this
process is inherent in the start/stop transmission  technique  on  the
link.    Byte   framing  is  established  with  each  byte  sent.   On
synchronous links, byte synchronization is  established  by  searching
for  a unique 8-bit sequence called the sync byte, checking for two in
sequence, and then counting every  8  bits  as  a  byte.   The  unique
pattern is such that any skewing to the right or left will not produce
a sequence match.  On 8-bit or 8-bit  multiple  parallel  links,  byte
synchronization  is  inherent  in the link.  For other types of links,
techniques must be designed to locate the proper  8-bit  byte  window.
The  technique  is,  thus,  part of DDCMP but defined specific to each
link type.



2.5.1.3  Message Synchronization - Locating a message or block.   This
involves  finding  the  first  and last bytes of a message.  The first
byte is found by searching for one of  three  special  first  starting
bytes  after  achieving  byte synchronization.  The last byte is found
via a count field in the message header which denotes  the  length  of
the  message.   Once  the  message  is framed it is then available for
processing by the  remainder  of  the  protocol.   The  starting  byte
defines the format type of the message and how the remaining bytes are
to be interpreted.

The byte and message synchronization techniques were chosen  to  allow
the  greatest  flexibility  and independence from the actual data link
characteristics.  By using these  techniques,  DDCMP  can  operate  on
serial  synchronous  links  with  typical character interrupt or block
transfer devices and on serial asynchronous links using  8-bit  bytes.
Byte  synchronization  is  specified in DDCMP and is specific for each
data link and its characteristics.   Message  synchronization  is  the
same   for   all   link  types  once  byte  synchronization  has  been
established.



2.5.2  Link  Management  Component - The  Link  Management   Component
resolves the transmission and reception on links that are connected to
two or more transmitters and/or receivers in a given direction.   This
is  true  of  half-duplex  and  multipoint  channels.  Link management
occurs for both the transmitting and receiving functions.

On half-duplex links, one station must be receiving while the other is
transmitting.   The  switching  between  transmit and receive is via a
�Functional Description                                         Page 14


selection flag.  The station that is transmitting ends transmission by
setting  the  flag  in its last message.  This signals the receiver to
complete reception of this message and then enter transmit mode.

For reception on multipoint links, the link appears as a  party  line,
with  one  station  designated  the  control  station  and  the others
tributaries.  All messages contain a  tributary  address  to  identify
them.   Messages  to  a  tributary are received by all tributaries and
ignored by all except the one with  the  matching  address.   Messages
from  tributaries are ignored by other tributaries and received by the
control station that verifies the tributary  address  to  be  the  one
selected.   Message  traffic  is  only between the control station and
tributaries.

For transmission on multipoint links, the control station manages  the
link  and  assigns  transmission  ownership  or selection to tributary
stations via a selection flag.  Tributary stations, once selected, may
transmit  and  will terminate transmission by sending a selection flag
to the control station in the last message of a transmission sequence.

Timers are used by half-duplex or control stations to handle the  case
of a lost flag (e.g., the message containing the flag is in error).  A
timer is started when waiting for the next message.  If it expires  it
is  assumed  the  selection flag was received in error and the station
operates as if it received a valid selection flag.



2.5.3  Message Exchange Component - The message exchange component  is
the  part  of DDCMP that creates the sequential error-free link.  This
component transfers the data correctly and in  sequence  over  a  link
that  has  some  probability  of  introducing errors.  Once framing is
accomplished, this component operates at the message level, exchanging
data  and  control  messages.   DDCMP  is  a  positive acknowledgement
retransmission protocol.  For each data message correctly received and
passed to the user, a positive acknowledgement is returned on the link
notifying the transmitter of the correct receipt of the data  message.
If  incorrectly  received,  the data message is not passed to the user
and not acknowledged.  Eventually, an error recovery mechanism will be
invoked  and the message will be retransmitted.  DDCMP uses the CRC-16
cyclic redundancy check for error detection.  This  section  describes
the component parts of the message exchange mechanism along with their
design characteristics and functions.

The basic positive acknowledgement message exchange component requires
the following:

     a.  A data message with message number n;

     b.  A positive acknowledgement with message number n (ACK); and

     c.  A timer.

�Functional Description                                         Page 15


It operates in the following manner:

     1.  The transmitter puts the next available message number  n  in
         the  data  message,  adds the CRC block check to the message,
         puts it in the required framing envelope, and sends it.  When
         it has been transmitted on the link, a timer is started.

     2.  The receiver frames and receives the message, checks the  CRC
         for  errors,  and  compares  the message number with the next
         expected.  If the number is correct, the receiver  returns  a
         positive  acknowledgement  (ACK) with that number, passes the
         message to  the  receiving  user,  and  increments  the  next
         expected  number  to n + 1 (modulo 256).  If the number is in
         error, the message is ignored.

     3.  The transmitter follows one of two procedures;

         a.  It receives a positive acknowledgement and  compares  the
             number received with the one expected.  If it agrees, the
             transmitter   releases   the   message,   notifies    the
             transmitting user of successful receipt, stops the timer,
             and increments the next available message number to n + 1
             (modulo 256).  If the acknowledgement does not agree with
             the expected number, it is ignored.

       OR

         b.  It  receives  nothing  and  the   timer   expires.    The
             transmitter  initiates  error  recovery.   Various  error
             recovery options are available.  The ones used  in  DDCMP
             are presented below.


The timer in the message exchange component is keyed to the  selection
of  a tributary (multipoint) or other station (half-duplex).  That is,
the controlling station must wait  until  a  tributary  or  the  other
station  is selected and transmits before it determines that a message
or ACK was not properly received.  This makes the  timing  independent
of  the selection of stations.  On full duplex point to point channels
the timer is a clock which allows enough  time  for  the  receiver  to
respond with the ACK.

This mechanism is adequate for creating a message exchange  component.
The  following additional messages and operational techniques of DDCMP
are used to achieve higher performance  (via  pipelining)  and  faster
error  recovery  (via  error notification) but do not add to the basic
integrity of the data transfer mechanisms.



2.5.3.1  Negative Acknowledgement (NAK) - The time-out value  used  to
detect  an  error  when  an ACK is not returned must be long enough to
account  for  delays  such  as  propagation,  line  turnaround,  local
processing  of  the  data  message,  and  the  generation  of the ACK.
Time-out values might be a few seconds while the actual delay  may  be
�Functional Description                                         Page 16


on  the  order of a few milliseconds.  If the only way to determine an
error is to wait for a time-out,  undue  waste  and  inefficiency  are
encountered.   A  negative  acknowledgement  provides a means for more
immediate notification of some error conditions.  If the receiver does
not  receive  the  message correctly but does recognize that a message
was sent, it sends a  NAK,  which  triggers  the  retransmission  long
before the timer expires.

In DDCMP, NAKs are sent in response to cyclic redundancy check errors,
but not to wrong message numbers.  If the receiver gets a message with
the wrong number, the message is ignored and  the  time-out  condition
triggers  the  transmitter  to  initiate error recovery.  If NAKs were
sent in both cases, race conditions and long delays could occur  under
certain timing conditions.



2.5.3.2  Reply To Message Number (REP) - When the timer expires, it is
unclear  whether the message was received in error or the returned ACK
was received in error.  (ACKs also have CRC checks on them).  In  this
case,  rather  than  retransmit  perhaps a long message, a REP is sent
with the message number  of  the  message  previously  sent.   If  the
message  with  that number was received correctly, the response to the
REP is an ACK; otherwise it is a NAK.  The receipt  of  a  NAK  causes
retransmission  to occur.  The REP forces the transmitter and receiver
to synchronize their numbering and start retransmission  if  required.
The  transmission  timer  is  restarted  after  sending  a REP.  If it
expires again, the process is repeated.  After some  specified  number
of  these  time-outs,  the transmitter will notify the DDCMP user, who
may declare the link out-of-service.



2.5.3.3  Pipelining - The  ability  to  send  more  than  one  message
without  waiting  for  ACKs  to  each  successive  message  is  called
pipelining.  Within DDCMP, messages are numbered from 0 to 255.   This
numbering  is cyclic (modulo 256) in that after message number 255 the
next message number is 0.  ACKs not only confirm  that  the  specified
message  number  has  been  received  correctly, but that all previous
messages with numbers between the one acknowledged in the last ACK and
the  one  acknowledged  by  the  current  ACK  (modulo  256) have been
received correctly.  If an ACK message is in  error,  the  information
lost  is  automatically  included  in subsequent ACKs, eliminating the
sending of REP  messages  if  the  ACKS  are  received  prior  to  the
expiration  of  the  transmission  timer.  This technique is also used
with the REP message, the number sent in the REP being the  number  of
the last message transmitted.



2.5.3.4  Piggybacking - The purpose of an ACK is to convey the message
number  of  the  last  successfully  received  data  message.  If data
message traffic is being  transmitted  in  both  directions,  the  ACK
number  can  be sent piggybacked on or within the frame of the message
being transmitted in the  reverse  direction.   This  technique  saves
�Functional Description                                         Page 17


separate framing overhead for the ACK.



2.5.3.5  ACK Implied In NAK - The number referenced  in  a  NAK  reply
identifies  the last successfully received message as well as noting a
received error.  So NAK implies that all messages  prior  to  the  one
being negatively acknowledged were received correctly.



2.5.3.6  Initialization - The method of  setting  message  numbers  to
initial  values  is called initialization.  It is accomplished by STRT
and STACK messages that reset message numbers to  zero.   It  is  used
initially  or after a failure to reset number values at both ends.  It
is designed so that one end cannot be initialized without the other.



3  INTERFACES

This section describes how DDCMP is viewed by a user of  the  protocol
and how the physical interface device or driver is viewed by DDCMP.  A
generic description of the information that must be passed across  the
interfaces  to  the  user  and  the  device is presented as an aid for
implementation design.



3.1  USER INTERFACE

The interface between DDCMP and the  user  consists  of  a  number  of
commands  to  DDCMP  and  responses from DDCMP.  In these commands and
responses, the user exchanges data and control  information  with  the
protocol.   The  actual  interface  mechanism  depends  heavily on the
features and capabilities within the operating systems running  DDCMP.
Mechanisms  for  exchanging  this  information  might  include  shared
tables, calls with  parameter  lists,  I/O  registers,  and  interrupt
mechanisms.

Three kinds of  information  are  exchanged  in  the  command/response
sequences:

     a.  Data,

     b.  Control information, and

     c.  Error information.

Data is the user information to be sent or received by  the  protocol.
Its  description  usually  consists of a starting buffer address and a
length or character  count,  or  a  chain  of  addresses  and  counts.
Control  is  information to start and stop the protocol and notify the
user of protocol initialization.  Error information is provided by the
protocol for use in determining the physical condition of the link and
�Interfaces                                                     Page 18


when maintenance is necessary.  DDCMP is  totally  controlled  by  the
user  of the protocol.  It is only activated by a command request from
the user and continues to operate even  when  large  numbers  of  data
errors  occur  on  the  physical  link.   It  is started, stopped, and
reinitialized only upon commands from the user.  On multipoint  links,
independent  command and response sequences are maintained between the
control station and each tributary on  the  link.   The  link  appears
logically  as  multiple  point-to-point  links, one for each tributary
address.

The exact interface between DDCMP and the user depends on  the  system
implementation  and  will  vary  in  the  manner  in  which errors are
handled.  In some systems, the error handling code may be  totally  at
the  user  level,  each  error  being  reported to the user.  In other
systems, the error handling code may be part of  the  protocol  module
and  only  persistent  errors will be reported to the user.  Subhead 6
describes the error  information  recording  techniques  that  may  be
employed within DDCMP.



3.1.1  Commands To DDCMP - The basic commands to DDCMP are:

     a.  Initialize Link - Initialize the protocol and start the  data
         link.  See 3.2.3 below for more details on initialization and
         management commands.

     b.  Stop Link - Halt the protocol.  In some dial-up situations, a
         method may be employed to force the modem to hang-up.

     c.  Transmit Message - Give a message to DDCMP for  transmission.
         As  an option the user may specify that it wishes to send the
         message  within  the  maintenance  mode,  or   the   protocol
         implementation   may  require  a  separate  Maintenance  Mode
         Initialization command prior to a transmit request.

     d.  Receive Message - Give an empty buffer to DDCMP for reception
         of  the  next  sequential  message.   Alternatively, the user
         might supply a pool of buffers to DDCMP initially,  and  have
         the  protocol  select  one.   In  this mode, there will be an
         alternate command to Return Empty Buffers to the pool so they
         may again be used by DDCMP.

     e.  Return Transmit Buffers - This optional command, which can be
         employed  after  halting  DDCMP, returns outstanding transmit
         buffers to the user.  The  response  to  this  command  would
         include   whether   they   were   already   transmitted   and
         acknowledged, not yet acknowledged, or not yet transmitted.

     f.  Enter Maintenance Mode - This command is an option  to  first
         change   to  the  maintenance  mode  before  transmitting  or
         receiving maintenance mode messages.

�Interfaces                                                     Page 19


3.1.2  Responses From DDCMP - The responses from DDCMP are:

     a.  Initialization on Other End - The other end has restarted  or
         initialized.   This  response  will  halt  the protocol.  The
         command to restart the  protocol  on  this  end  will  be  an
         Initialize Link command.

     b.  Initialization  Complete  -  Response  to   Initialize   Link
         command.   This  response is optional.  If it is omitted, the
         reply to a successfully received or transmitted message  will
         serve as initialization completion notification.

     c.  Message  Transmitted  -  Response  to  the  Transmit  Message
         command.   The message was successfully received on the other
         end (acknowledged).

     d.  Message  Received  -  The   next   sequential   message   was
         successfully  received.   Either the user buffer specified in
         the Receive Message command will be used, or a buffer will be
         taken from a pool, if such a buffering technique is employed.

         Optionally, if the message was received  in  the  maintenance
         mode it may be so marked, or a separate response may be first
         sent to the user  to  indicate  that  the  other  end  is  in
         maintenance mode.  At that point, the protocol will halt, and
         the user will  have  to  initialize  the  protocol  into  the
         maintenance mode before receiving maintenance mode messages.

     e.  Transient Error -  Threshold  Counter  Overflow  -  An  error
         threshold counter has overflowed.  The protocol will continue
         operation.  It must be halted by the user if the user  wishes
         to cease operation.  Refer to subhead 6, ERROR RECORDING.

     f.  Persistent Error - An error has occurred from which  recovery
         may  not  be  possible.  Some implementations of the protocol
         may halt operation.   Some  errors  that  are  classified  as
         persistent errors in one system, might be transient errors in
         another.  The  various  types  of  errors  are  described  in
         subhead 6.




3.2  DEVICE DRIVER INTERFACE

The interface between DDCMP and the line driver includes a  number  of
commands  and responses used to transmit and receive message blocks to
and from the link, respectively.  The actual interface depends heavily
on  the  mechanisms and capabilities available in the I/O structure of
the systems within which this interface  operates.   It  also  depends
heavily  on  the  split  of  protocol  functions between DDCMP and the
driver.  The driver may be very protocol independent and rely on heavy
interaction  with  DDCMP for message framing, CRC calculation, and the
syntactic and semantic interpretation of message fields.  Alternately,
it  may  embody  much  of  DDCMP including framing, CRC checking, link
�Interfaces                                                     Page 20


management, and link turnaround.  In this mode, there  would  be  less
interaction  with  the  semantic or message exchange portion of DDCMP.
Consequently the driver would handle many of the functions related  to
link   type   and   device  characteristics.   The  choice  of  driver
capabilities  and  the  split   of   functions   depends   on   system
characteristics,  device  requirements,  driver  generality,  and  the
interface to other  protocols.   The  interface  described  here  lies
between these two extremes and is presented as an aid to understanding
what information must pass across this interface.

Message blocks are usually passed to the driver via a  buffer  address
and  length  (or  a chain of addresses and lengths to allow fragmented
message blocks).



3.2.1  Commands To The  Driver - The  driver  receives  the  following
commands:

     a.  Link and Modem Control - These commands activate and  connect
         a  physical  link  to  DDCMP.   They  also  control the modem
         signals necessary for proper operation.  These signals may be
         implicit in enabling the link (i.e., turn Data Terminal Ready
         (DTR) on) or explicit via modem  control  commands  to  allow
         DDCMP  to directly control the modem.  Typical commands might
         be:

          o  Enable link.  This command connects the driver  to  DDCMP
             and turns DTR on.

          o  Disable link.  This command disconnects the  driver  from
             DDCMP and turns DTR off.


     b.  Buffer Management - Received message  blocks  are  passed  to
         DDCMP via buffers.  The buffers may be (a) individually given
         to the driver via Receive commands or (b) initially allocated
         to  the  driver  in  a Set Buffers command or the Enable Link
         command.  In this second mode there must also  be  a  command
         for   DDCMP   to  return  the  buffers  to  the  driver.   On
         disconnection (Disable Link Command),  the  buffers  must  be
         returned to DDCMP or to a buffer pool.

     c.  Transmit a Block - This command passes a block to the  driver
         for  transmission.   The  request  might  include  one of the
         following  options:   (a)  precede  with  a   synchronization
         sequence;  (b)  end  with  a  pad;  (c) calculate CRC; or (d)
         shutdown the transmitter after the  message.   These  options
         depend  on  the  precise  division  of  functions between the
         driver and protocol.

     d.  Receive a Block - This command passes buffers to  the  driver
         if  individual  explicit  buffers  are  used.  Otherwise, the
         driver might simply queue  received  blocks  to  DDCMP  using
         buffers   from  a  previously  obtained  pool  (as  noted  in
�Interfaces                                                     Page 21


         paragraph b above).  This command may also request the driver
         to  resynchronize  or  reframe the receiver or there may be a
         separate Resync Receiver command.

     e.  Set  Parameters  -  If  the   driver   design   is   protocol
         independent,  this  command  might  be  included  to set such
         parameters  as  synchronization   sequences   and   the   CRC
         polynomial.




3.2.2  Responses From The Driver - The  driver  issues  the  following
responses:

     a.  Modem Status - The driver returns modem signals, such as Data
         Set Ready (DSR), if appropriate to the interface.

     b.  Received Block - The driver passes a received data  block  to
         DDCMP.   Depending on the functional split between the driver
         and DDCMP, the driver may calculate CRC (either in the driver
         or  device itself) and pass this status with the block.  When
         DDCMP is finished with the buffer it returns it to the driver
         via  either  (a)  a  Receive  command  or (b) a Return Buffer
         command, depending on the buffering scheme used.

     c.  Transmit Complete - The  driver  will  notify  DDCMP  when  a
         previous Transmit a Block command has been completed.




3.2.3  Initialization And Management Interface - The  Initialize  Link
command  may  be  expanded  to provided more control and monitoring of
DDCMP, especially in multipoint configurations.
This may included the following commands and responses:

     1.  Reset

         This command resets the state of DDCMP,  placing  it  into  a
         default  mode  and  disabling  any  tributary addresses.  All
         tributary state information is cleared (to HALTED state).

     2.  Set mode (mode)

         Where mode is one of the following:

             inoperative
             full duplex point-to-point
             half duplex point-to-point
             full duplex multipoint control
             half duplex multipoint control
             full duplex multipoint tributary
             half duplex multipoint tributary
�Interfaces                                                     Page 22


         This command is required  only  if  more  than  one  mode  is
         supported.   The  choice  of  default mode following Reset is
         implementation dependent.

         Some implementations may permit this command only immediately
         following  a  Reset.  Others may permit changing between full
         and half duplex operation at other times.

     3.  Status mode

         This command returns the current station mode.  This  command
         should be implemented if Set Mode is implemented.

     4.  Enable Data Link (address)

         This command is used by  multipoint  stations  only.   It  is
         required  for  multipoint  control  stations and optional for
         multipoint  tributary  stations.   (If  not  implemented   by
         tributaries,  alternate  means  are  required  to  define the
         tributary address(es).)

         Until an address has been enabled, a multipoint station  will
         not  accept  commands  from  the user interface for that data
         link.  That is, multipoint control station will not poll  the
         specified  tributary,  and  a  multipoint  tributary will not
         accept received messages for the specified address.

     5.  Disable Data Link (address)

         This command is the inverse of  the  Enable  and  clears  any
         state information associated with the address.

     6.  Status Data Link (address)

         This command returns the following states for  the  specified
         address:

             Disabled (if multipoint)
             HALTED
             ISTRT
             ASTRT
             RUNNING
             MAINTENANCE


     7.  Set timer (value)

         This command sets the timer  used  for  the  reply  timer  on
         full-duplex  point-to-point  links  and  the  select timer on
         half-duplex  point-to-point  links  and  multipoint   control
         stations.  This command is optional.

     8.  Status timer

         This command returns the timer value.  It is also optional.
�Interfaces                                                     Page 23


Commands and  responses  to  read  and  clear  error  and  maintenance
counters are described in heading 6.



4  MESSAGE FORMATS

This  section  describes  the  message  formats  of  DDCMP.   Data  is
exchanged  over  DDCMP links between the data source (master) and data
sink (slave) within numbered data  messages.   Responses  and  control
information   are  returned  from  the  slave  to  the  master  within
unnumbered control messages.   Stations  contain  both  a  master  and
slave.  For the purpose of exchanging data, the station plays the role
of master  or  slave  depending  on  whether  it  is  transmitting  or
receiving  the  data.  It is a distinction used for easy understanding
and explanation of DDCMP.  In reality, data is  usually  exchanged  in
both directions.  In the following explanation only a single direction
is described.

Each data message carries a number assuring correct message sequencing
at   the   slave.    The   numbering  begins  with  number  one  after
initialization via the STRT/STACK  control  message  sequence  and  is
incremented by one (modulo 256) for each subsequent data message.  The
slave always acknowledges the correct  receipt  of  data  messages  by
returning  the  message  number  as  a response either in the response
field of numbered data messages being sent or, in  an  ACK  unnumbered
control  message.   For  efficiency,  an  acknowledgement  of the data
message with number n implies an acknowledgement  of  all  consecutive
data  messages  sent  up  to  and  including  data  message  number n.
Retransmission is used to recover from  errors.   The  error  recovery
mechanism   uses  time-outs  and  NAK  and  REP  control  messages  to
resynchronize and cause retransmission if required.  All messages also
include station addresses and link control flags for use on multipoint
and half-duplex channels.
�Message Formats                                                Page 24


4.1  NOTATION

The following notation is used to describe the messages:

         Field (length) :  coding = description of field

         Field = the name of the field being described

         Length = the length of the field as:

         a.  A number meaning the number of 8-bit bytes

       OR

         b.  A number followed by a B, meaning the number of bits.


         Coding = the representation type used:

             B = Binary
             BM = Bit map (each bit has independent meaning)
             C = Constant
             Null = Interpretation data dependent


Fields in separate messages that have the identical name are the  same
field and have identical meaning.

All  numeric  values  in  this   document   are   shown   in   decimal
representation unless otherwise noted.

All header fields and bytes  of  data  are  transmitted  low-order  or
least-significant  bit  first  on  the  data  links  unless  otherwise
specified.
�Message Formats                                                Page 25


4.2  DATA MESSAGES

Numbered data messages carry user data over DDCMP links.   The  format
of a numbered message is:

 __________________________________________________________________
|      |       |       |      |      |     |        |      |       |    
| SOH  | COUNT | FLAGS | RESP | NUM  |ADDR | BLKCK1 | DATA | BLKCK2|
|      |       |       |      |      |     |        |      |       |
 ------------------------------------------------------------------

Where:

SOH(1) : C =          The numbered data message identifier.  It has a 
                      value of 129 (octal - 201, hex - 81).

COUNT(14B) : B =      The byte count field.  It specifies the number 
                      of 8-bit bytes in the DATA field.  The value 
                      zero is not allowed.

FLAGS(2B) : BM =      The link flags.  They are used to control link 
                      ownership and message synchronization.  These 
                      flags are:

     bit 0 =               Quick sync flag (QSYNC flag), used to 
                           notify the receiver that the next message 
                           will not abut this message and resynchron-
                           ization should follow this message.  The 
                           quick sync flag reduces the length of sync 
                           sequences on synchronous links.
     
     bit 1 =               Select flag (SELECT flag), used to control 
                           transmission ownership on multipoint and 
                           half-duplex links.  Reverses link direction 
                           on half-duplex links.  Invites a tributary 
                           to send and signals end of tributary 
                           selection on multipoint links.
     
                                            Note
                      COUNT and FLAGS form a 2-byte quantity.  The 
                      first byte contains the 8 low-order bits of the 
                      COUNT.  The second byte contains the 6 
                      high-order bits of the COUNT, the SELECT flag 
                      the highest order or most significant bit of the 
                      byte, and the QSYNC flag the next bit in the 
                      byte.
                                      _______________
                                     |   |   |       |
                                     | S | Q | COUNT |
                                     |   |   |       |
                                      ---------------
                        high order bit             low order bit
                        transmitted last           transmitted first
�Message Formats                                                Page 26


RESP(1) : B =         The response number.  It is used to acknowledge 
                      correctly received messages (the piggybacked 
                      ACK).  It is the number of the last consecutive 
                      correctly received message received from the 
                      addressed station by the station transmitting 
                      this message.  It implies that all 
                      unacknowledged messages between the one 
                      acknowledged in the last RESP field received and 
                      the one acknowledged by this RESP field (modulo 
                      256), have been received correctly.

NUM(1) : B =          The transmit number.  It is used to denote the 
                      number of this data message.

ADDR(1) : B =         The station address field.  It is used to 
                      designate the address of tributary stations on 
                      multipoint links.  Stations on point-to-point 
                      links use the address value 1.

BLKCK1(2) : B =       The block check on the numbered message header.  
                      It is computed on SOH through ADDR using the 
                      CRC-16 polynomial (X^16+X^15+X^2+1).  BLKCK1 is 
                      initialized to zero prior to computation and 
                      transmitted X^15 bit first.  On reception the 
                      inclusion of BLKCK1 in the computation will 
                      result in a zero remainder or CRC value if no 
                      bit errors exist.  See Appendix D for a 
                      description of CRC computation.

DATA (COUNT) =        The numbered message data field.  This field is 
                      totally transparent to the protocol and has no 
                      restrictions on bit patterns, groupings, or 
                      interpretations.  The only requirement is that 
                      it contain the number of 8-bit bytes specified 
                      in the COUNT field.

BLKCK(2) : B =        The block check on the data field.  It is 
                      computed on the DATA field only using the 
                      polynomial and technique described above for 
                      BLKCK1.
�Message Formats                                                Page 27


4.3  CONTROL MESSAGES

Unnumbered control messages carry  channel  information,  transmission
status,  and initialization notification between the protocol modules.
The individual fields are specific for each type of  control  message.
Control messages have the following general form:

      ____________________________________________________
     |    |     |        |      |     |     |     |       |
     |ENQ |TYPE |SUBTYPE |FLAGS |RCVR |SNDR |ADDR |BLKCK3 |
     |    |     |        |      |     |     |     |       |
      ----------------------------------------------------

where:

ENQ(1) : C =          The unnumbered control message identifier.  It 
                      has a value of 5 (octal - 005, hex - 05).

TYPE(1) : B =         The control message type.  This value denotes 
                      the type of each control message.

SUBTYPE(6B) : B =     The subtype or type modifier field.  It provides 
                      additional information for some message types.  
                      Its use is specific for each message type.

FLAGS(2B) : BM =      The link flags.  They are the same as described 
                      for numbered data messages (See subhead 4.2).

RCVR(1) : B =         The control message receiver field.  It is used 
                      to pass information from the data message 
                      receiver or slave station to the data message 
                      sender or master station.  Its use is specific 
                      for each control message type.

SNDR(1) : B =         The control message sender field.  It is used to 
                      pass information from the data message sender or 
                      master to the data message receiver or slave.  
                      Its use is specific for each control message 
                      type.

ADDR(1) : B =         The station address field.  It is the same as 
                      described for numbered data messages (See 
                      subhead 4.2).

BLKCK3(2) : B =       The block check on the control message.  BLKCK3 
                      is computed on fields ENQ through ADDR using the 
                      polynomial and technique described for numbered 
                      data message BLKCK1 (See subhead 4.2).

�Message Formats                                                Page 28


                                 Note
              
              The common fields in data and control 
              messages are in the same position 
              relative to the beginning of the message.  
              The two types line up as follows:
              
 ______________________________________________________________
|   |            |      |     |    |     |       |     |       |
|SOH| C O U N T  |FLAGS |RESP |NUM |ADDR | BLKCK1| DATA|BLKCK2 |
|   |            |      |     |    |     |       |     |       |
 --------------------------------------------------------------
|   |    |       |      |     |    |     |       |
|ENQ|TYPE|SUBTYPE|FLAGS |RCVR |SNDR|ADDR | BLKCK3|
|   |    |       |      |     |    |     |       |
 ------------------------------------------------



4.3.1  Acknowledge  Message  (ACK) - The  ACK  message  is   used   to
acknowledge the correct receipt of numbered data messages.  It conveys
the same information as the RESP field in  numbered  messages  and  is
used when acknowledgements are required, and when no numbered messages
are to be sent in the reverse direction.  The form of the ACK  message
is:

 _____________________________________________________
|    |        |       |      |     |     |     |      |
|ENQ | ACKTYPE|ACKSUB |FLAGS |RESP |FILL |ADDR |BLKCK3|
|    |        |       |      |     |     |     |      |
 -----------------------------------------------------

Where:

ENQ(1) : C =         The control message identifier.

ACKTYPE(1) : C =     The ACK message type with a value of 1.

ACKSUB(6B) : C =     The ACK subtype with a value of 0.

FLAGS(2B) : BM =     The link flags.

RESP(1) : B =        The response number used to acknowledge correctly 
                     received messages.  It is the same as described 
                     for numbered data messages (See subhead 4.2).

FILL(1) : C =        A fill byte with value 0.

ADDR(1) : B =        The station address field.

BLKCK3(2) : B =      The control message block check.
�Message Formats                                                Page 29


4.3.2  Negative Acknowledge Message (NAK) - The NAK message is used to
pass error information from the slave (or data receiver) to the master
(or data sender).  The error reason is included in the subtype  field.
The NAK message also includes the same information as the ACK message,
thus  serving  two  functions:   acknowledging   previously   received
messages  and  notifying the master of some error condition.  The form
of the NAK message is:

 ______________________________________________________
|    |        |       |      |     |     |     |       |
|ENQ |NAKTYPE |REASON |FLAGS |RESP |FILL |ADDR |BLKCK3 |
|    |        |       |      |     |     |     |       |
 ------------------------------------------------------

Where:

ENQ(1) : C =          The control message identifier.

NAKTYPE(1) : C =      The NAK message type with a value of 2.

REASON(6B) : B =      The NAK error reason.  Identifies the source and 
                      reason for the NAK.

     1.  Error usually due to transmission medium:
     
         Value and Reason
     
         1 = header block check error (data message BLKCK1 
             or control message BLKCK3).
         2 = data field block check error (data message 
             BLKCK2).
         3 = REP response.
     
     2.  Error usually due to computer and/or interface:
     
         Value and Reason
     
         8 = buffer temporarily unavailable.
         9 = receiver overrun.
        16 = message too long.
        17 = message header format error.
     
FLAGS(2B) : BM =      The link flags.

RESP(1) : B =         The response number used to acknowledge 
                      correctly received messages.  When used in a NAK 
                      message usually implies some error in a message 
                      with number RESP+1 (modulo 256) or beyond.

FILL(1) : C =         A fill byte with a value of 0.

ADDR(1) : B =         The station address field.

BLKCK3(2) : B =       The control message block check.
�Message Formats                                                Page 30


4.3.3  Reply To Message Number (REP) - The  REP  message  is  used  to
request  received  message status from the slave or data receiver.  It
is usually sent when the master has transmitted data messages and  has
not  received a reply within a time-out period.  The response to a REP
is either an ACK or NAK depending on whether the slave has or has  not
received  all messages previously sent by the master.  The form of the
REP message is:

 _____________________________________________________
|    |        |       |      |     |    |     |       |
|ENQ |REPTYPE |REPSUB |FLAGS |FILL |NUM |ADDR |BLKCK3 |
|    |        |       |      |     |    |     |       |
 -----------------------------------------------------

 Where:

ENQ(1) : C =            The control message identifier.

REPTYPE(1) : C =        The REP message type with a value of 3.

REPSUB(6B) : C =        The REP subtype with a value of 0.

FLAGS(2B) : BM =        The link flags.

FILL(1) : C =           A fill byte with a value of 0.

NUM(1) : B =            The number of the last sequential numbered 
                        data message (not including retransmissions) 
                        sent by the master.  This is compared against 
                        the number of the last sequential message 
                        received by the slave and results in either an 
                        ACK being returned if they agree or a NAK if 
                        they do not.  The NAK will contain the number 
                        of the last sequential message that was 
                        received.

ADDR(1) : B =           The station address field.

BLKCK3(2) : B =         The control message block check.
�Message Formats                                                Page 31


4.3.4  Start Message (STRT) - The STRT message is  used  to  establish
initial  contact and synchronization on a DDCMP link.  It is used only
on link startup or  reinitialization.   It  operates  with  the  start
acknowledge  message STACK described below.  The start sequence resets
message numbering at the transmitter and addressed receiver.  The form
of the STRT message is:

 ______________________________________________________
|    |         |        |      |           |    |      |
|ENQ |STRTTYPE |STRTSUB |FLAGS |FILL |FILL |ADDR|BLKCK3|
|    |         |        |      |     |     |    |      |
 ------------------------------------------------------

where:

ENQ(1) : C =            The control message identifier.

STRTTYPE(1) : C =       The STRT message type with a value of 6.

STRTSUB(6B) : C =       The STRT subtype with a value of 0.

FLAGS(2B) : C =         The link flags.  For STRT, both flags are ones 
                        (flags value of 3).

FILL(1) : C =           A fill byte with a value of 0.

FILL(1) : C =           A fill byte with a value of 0.

ADDR(1) : B =           The station address field.

BLKCK3(2) : B =         The control message block check.
�Message Formats                                                Page 32


4.3.5  Start  Acknowledge  Message  (STACK) - The  STACK  message   is
returned  in  response  to  a  STRT  when  the  station  has completed
initialization and has reset its message numbering.  The form  of  the
STACK message is:

 ________________________________________________________
|    |         |        |      |     |     |     |       |
|ENQ |STCKTYPE |STCKSUB |FLAGS |FILL |FILL |ADDR |BLKCK3 |
|    |         |        |      |     |     |     |       |
 --------------------------------------------------------

where:

ENQ(1) : C =          The control message identifier.

STCKTYPE(1) : C =     The STACK message type with a value of 7.

STCKSUB(6B) : C =     The STACK subtype with a value of 0.

FLAGS(2B) : C =       The link flags.  For STACK, both flags are ones 
                      (flags value of 3).

FILL(1) : C =         A fill byte with a value of 0.

FILL(1) : C =         A fill byte with a value of 0.

ADDR(1) : B =         The station address field.

BLKCK3(2) : B =       The control message block check.
�Message Formats                                                Page 33


4.4  MAINTENANCE MESSAGES

The DDCMP protocol operates in two basic modes:

     a.  On-line, or the normal running mode.

     b.  Off-line, or the maintenance mode.

The previous messages and operation describe the  on-line  mode.   The
off-line,  or  maintenance  mode,  may  be  used  for basic diagnostic
testing  and  simple  operating  procedures  such  as   bootstrapping,
down-line   loading,   or  dumping.   It  provides  a  basic  envelope
compatible with DDCMP framing, link management, and the CRC check  for
bit  errors,  but  does not include any error recovery, retransmission
time-outs, or sequence checks.  All these functions, if necessary, are
handled  by  the  user  of  this  mode  within  the  data  field.  The
maintenance message is similar in format to  the  data  message.   The
format of the maintenance message is:

 ______________________________________________________
|   |      |      |     |     |    |       |    |      |
|DLE|COUNT |FLAGS |FILL |FILL |ADDR|BLKCK1 |DATA|BLKCK2|
|   |      |      |     |     |    |       |    |      |
 ------------------------------------------------------

where:

DLE(1) : C =            The maintenance message identifier, has the 
                        value 144 (octal - 220, hex - 90).

COUNT(14B) : B =        The byte count field, specifies the number of 
                        8-bit bytes in the DATA field.  The value zero 
                        is not allowed.

FLAGS(2B) : C =         The link flags.  Both flags are ones for 
                        maintenance messages (flags value of 3).

FILL(1) : C =           A fill byte with a value of 0.

FILL(1) : C =           A fill byte with a value of 0.

ADDR(1) : B =           The station address field.

BLKCK1(2) : B =         The header block check on fields DLE through 
                        ADDR.  Same as described for data messages 
                        (See subhead 4.2).

DATA (COUNT) =          The data field.  It consists of COUNT 8-bit 
                        bytes.

BLKCK2(2) : B =         The block check on the DATA field only.  Same 
                        as described for numbered data messages (See 
                        subhead 4.2).
�Operation                                                      Page 34


5  OPERATION

The DDCMP functions may be grouped into three  areas:   Framing,  Link
Management, and Message Exchange.  These functional components are:

     a.  Framing - The process of locating the beginning and end of  a
         message.    It   may   involve   bit,   byte,   and   message
         synchronization.  Once framing is accomplished  the  protocol
         operates  at  the  logical  message  level,  both sending and
         receiving message blocks.

     b.  Link Management - The process of controlling the transmission
         and  reception on links connected to two or more transmitters
         and/or receivers on a common signal channel.  This is true of
         half-duplex  and  multipoint links.  There must be an orderly
         mechanism for the proper receiver to identify  its  data  and
         for  only  one  transmitter  on a common signal channel to be
         active at a given time.

     c.  Message Exchange - The process of transferring user data over
         the  link  sequentially  and  without bit errors.  DDCMP is a
         positive acknowledgement retransmission  protocol,  returning
         an  indication  to  the transmitter for each message that has
         been successfully received.




5.1  FRAMING

The basic concepts of framing are  presented  in  subhead  2.5.   This
section  discusses  the specific details of framing for each link type
on which DDCMP operates.  Framing occurs at the bit, byte, and message
levels.

Bit framing is handled by the modems and interfaces, and is not a part
of this standard.



5.1.1  Byte Framing - This process entails framing on the proper 8-bit
byte sequence so that bits may be grouped into meaningful 8-bit bytes.
Byte framing  differs  for  each  type  of  link.   The  byte  framing
procedures  for  asynchronous,  synchronous,  and  parallel  links are
described in the following subheads:



5.1.1.1  Asynchronous Links - DDCMP operates  on  serial  asynchronous
links using 8-bit bytes.  Byte framing is inherent in the asynchronous
operation.  An asynchronous link is a communications path that has  no
fixed time relationship between bytes.  When bytes are to be sent, the
link is activated.  When there is no byte flow the link remains  in  a
steady  state.   This  steady state is called the mark state, 1 state,
stop state,  or  Z  condition  and  by  convention  is  the  binary  1
�Operation                                                      Page 35


condition.   For sending a byte (or 8 bits) over the line, the framing
technique used is based on a start and a stop bit placed at  each  end
of the byte.

The presence of the start bit is recognized by the receiving  computer
as  a  change  from  the  1  to  0  state.  This change (a) starts the
receiver sampling the line at preset timing intervals  and  (b)  tells
the  receiver  that the next eight bits will be the data byte followed
by a ninth bit, the stop bit.   An  important  consideration  is  that
there is no framing until the start bit is received for each byte.

A potential problem on asynchronous links is that framing may be  lost
during  the  transmission  of multiple abutting bytes (i.e., where the
next start bit immediately follows the preceding stop  bit).   If  the
receiver  shifts in bit timing, it may time its search for a start bit
at the exact interval when a data bit with the same value as the start
bit  is  received.   The receiver would then think that the next eight
bits were data, look for the stop bit, and wait for the next start bit
to  reframe.   The  error  will  be  caught by the block check for the
current message but may  lead  to  misframing  and  missing  the  next
message if uncorrected.

The solution to synchronization on asynchronous links  specifies  that
the transmitter must either send an all ones byte DEL (Value 255., 377
Octal,  FF  Hex)  or  idle  the   link   for   10   bit   times   when
resynchronization  is  required.  This technique will guarantee proper
byte framing for the next byte at the receiver.  The receiver does not
look  for  this DEL; it simply causes proper framing on the next byte.
If the DEL is  received,  it  is  ignored  when  resynchronizing.   On
asynchronous   links,   bytes  always  logically  abut  due  to  their
independence  from  each  other  in  time.   So  resynchronization  is
required  only  for  error  recovery  and  is  not  required preceding
messages where the link has just been idle for some time.



5.1.1.2  Synchronous  Links - DDCMP  operates  on  serial  synchronous
links  using  8-bit  bytes.   Bit  timing  is provided by the modem or
superimposed digitally on the data signal.  On synchronous links, byte
framing  is  established  by  searching  for a unique 8-bit pattern or
sequence in the bit stream.  Once this is found every eight bits forms
the next byte.  This pattern is called the SYN byte (value 150., octal
- 226, hex - 96).  The receiver must locate and lock on to a  sequence
of  two  consecutive  SYN  bytes to achieve byte synchronization.  The
transmitter must send four or more SYN bytes to  allow  for  the  loss
from    missynchronization   and   hardware   interface   constraints.
Additional  consecutive  SYN  bytes  are  ignored  on  receive   while
searching  for  the first non-SYN byte.  This sequence of four or more
SYN bytes is the synchronous synchronization sequence.

Since timing between bytes is determinate, messages must  either  abut
(i.e., the first byte of the next message immediately follows the last
byte of the current message with no intervening time) or byte  framing
is  assumed  lost  following the end of the current message.  The next
message  must  re-establish  or  resynchronize  byte  framing  at  the
�Operation                                                      Page 36


receiver.   This  resynchronization  requires  the  next message to be
preceded  by  a  synchronization  sequence.   On  some   communication
interfaces  (usually block-oriented or DMA type), received data may be
buffered within the device and when  the  software  driver  determines
that the next message does not abut, the device may have buffered many
bytes further ahead on the link.  Therefore, on synchronous  links,  a
long synchronization sequence is required when messages do not abut to
account for the potential buffering in the interface.  This  value  is
the  number  passed  over or buffered by the device plus four more for
resynchronization.  Current devices and  programming  techniques  have
set  the  long  sync sequence to eight or more SYN bytes.  This allows
for four bytes of buffering in the device followed by the  4-byte  SYN
sequence.

A feature has been included in DDCMP that can be used  to  reduce  the
length  of this sequence and improve efficiency of the protocol.  This
is implemented via the  QSYNC  or  Quick  Sync  flag  present  in  all
messages.   If  set in a message, the QSYNC flag notifies the receiver
that the next message will not abut and the  synchronization  sequence
preceding  the  next  message  may  be  the  short sequence.  When the
transmitter knows the next message will not abut the current  message,
it  may  set  the  QSYNC  flag.   The  receiver  seeing  this  may set
resynchronization on the  device  immediately  following  the  current
message  without  looking  ahead  into  the next message (and possibly
requiring a long synchronization sequence due  to  device  buffering).
This  allows  the receiver to synchronize on a short sequence.  A long
sequence may always be used;  the  additional  SYN  bytes  are  simply
ignored.



5.1.1.3  Parallel Links - If the transmission bit grouping on the link
is  a  multiple  of  eight  bits, then byte framing is inherent on the
link.  If the transmission bit grouping is a multiple  of  some  other
number  of  bits,  then  other  means  must  be sought to achieve byte
framing.   Such  a  mechanism  is  not  currently  specified  by  this
standard.



5.1.2  Message Framing - Message framing is achieved by searching  for
one  of  the  three  starting  message bytes SOH, ENQ, or DLE.  One of
these bytes must appear immediately after the byte framing sequence or
immediately  after the previous message's last byte (if abutting).  If
these bytes do not appear at the receiver in the proper location, then
the next message does not abut and byte framing is assumed lost.  Once
one of these starting message bytes is found, the end of  the  message
is determined by a single set of rules for all link types:

     a.  If the starting byte is SOH or DLE, then the next five  bytes
         will  complete  the  message header, followed by two bytes of
         header block check (CRC), followed by  COUNT  bytes  of  data
         (where  COUNT  is  the  14-bit  field  following SOH or DLE),
         followed by two bytes of data block check.
�Operation                                                      Page 37


     b.  If the starting byte is ENQ, then the next  five  bytes  will
         complete  the  message, followed by two bytes of header block
         check.

The data field is totally transparent.  No pattern searching  is  done
once  the  starting  byte is found.  If the header CRC is in error the
framing stops and  resynchronization  will  occur  (see  Subhead  5.3,
Message  Exchange).   If the station is a multipoint tributary and the
ADDR in the header does not match the station address,  the  tributary
still  tracks  the  message  by  framing  it  (see  subhead  5.2, Link
Management).



5.1.2.1  CRC Performance Option - In some cases, where  errors  caused
by  the  loss of synchronization on synchronous links have resulted in
one or more bits being either removed or added, the performance of the
CRC  block  check  is not as robust as in cases of simple bit changes.
To increase  the  error  detection  capability  in  these  cases,  the
following  additions  should be made to the techniques described above
(synchronous only):

Transmission - Whenever idling the link, ensure that the  transmission
ends with eight more 1 bits (DEL bytes).  This is a requirement on the
end of a message  where  the  next  message  does  not  abut,  is  not
immediately  followed by a sync sequence separating messages or before
shutdown.  Additional DEL bytes  may  be  needed  before  shutdown  to
satisfy the requirements of specific modems.

Reception  -  (Optional  to  achieve  better   bit   error   detection
capability).   After  receiving the end of a data message with a valid
CRC, do not process the message  until  one  more  byte  is  received.
Discard  the  message  (treat as a data CRC error) if this byte is not
either:  DEL, SYN, SOH,  ENQ,  or  DLE.   The  reception  function  is
optional.



5.1.3  Synchronization - Synchronization    is    the    process    of
establishing both byte and message framing.



5.1.3.1  Receiver Synchronization - Synchronization takes place at the
receiver under the following conditions:

     a.  Initially  on  receiver  start-up,  or  for  half-duplex  and
         multipoint  operation  on  link  turnaround or selection (see
         subhead 5.2, Link Management).

     b.  If messages do not abut (i.e., the next abutting byte is  not
         SOH, ENQ or DLE).

     c.  If  the  QSYNC  flag  is  set   in   the   current   message,
         resynchronize at the end of the message.
�Operation                                                      Page 38


     d.  If a block check (CRC) error or other error occurs that might
         have  caused  synchronization  to  be  lost  (e.g.,  receiver
         overrun).

The receiver should track the  link  as  much  as  possible  and  only
resynchronize  when  synchronization  may  have  been lost.  This will
increase the efficiency in receiving abutting messages and reduce  the
chance  of synchronizing on a false message inside a data message (the
aliasing problem).



5.1.3.2  Transmitter Synchronization - The  transmitter  will  send  a
synchronization  sequence  prior  to  transmitting  messages under the
following conditions:

     a.  Initially  on  transmitter   start-up   or   following   link
         turnaround (half-duplex and multipoint).

     b.  If a multipoint control station when  changing  the  ADDR  in
         messages to different tributaries.

     c.  If messages do not abut (synchronous mode only - they  always
         abut in the asynchronous mode).

     d.  If QSYNC is set in the  current  message,  precede  the  next
         message with the sync sequence.

     e.  In the next message sent after receiving a NAK.

     f.  Preceding  all  control  (ENQ)  messages   except   ACK.    A
         synchronization  sequence  will also precede an ACK if one of
         the other conditions is satisfied.

     g.  Preceding all maintenance mode (MAINT) messages.

     h.  Preceding all messages with the SELECT flag on  (see  subhead
         5.2, Link Management).

     i.  Preceding the next message if a hardware/driver error  (e.g.,
         overrun) occurs while transmitting the current message.

The transmitter should send a  synchronization  sequence  whenever  it
believes  synchronization  may  have  been  lost at the receiving end.
Preceding every message with a synchronization sequence  is  legal  in
the  protocol  but  will  reduce  the  potential  overall  performance
efficiency.
�Operation                                                      Page 39


5.1.3.3  Synchronization  Rules - Table   1   summarizes   the   DDCMP
synchronization rules.

             Table 1   Summary of Synchronization Rules

______________________________________________________________________
                   |               |
Type of Framing    |     Mode      | Synchronization Rules
                   |               |                                  
                   |               |
1. Byte Framing    |               |
                   |               |
   Asynchronous    | Receiver      | Inherent in transmission mode
                   |               | (none for DDCMP)
                   |               |
                   | Transmitter   | Send an all ones byte or idle the
                   |               | link for a 10-bit time interval.
                   |               | Not required on initial message
                   |               | or link turnarounds.
                   |               |
   Synchronous     | Receiver      | Search for two adjacent SYN
                   |               | bytes.  Strip any more abutting.
                   |               |
                   | Transmitter   | Send short sequence if:
                   |               |
                   |               | 1. Initial message (after
                   |               |    start-up) or link turnaround.
                   |               |
                   |               | 2. QSYNC set in previous message.
                   |               |
                   |               | Send long sequence if:
                   |               |
                   |               | 1. QSYNC not set in previous
                   |               |    message (not initial message).
                   |               |
�Operation                                                      Page 40


          Table 1.  Summary of Synchronization Rules (Cont'd)
______________________________________________________________________
                   |               |
Type of Framing    |     Mode      | Synchronization Rules
                   |               |                                  
                   |               |
2. Message Framing |               |
                   | Receiver      | Search for SOH, ENQ, DLE
                   |               | immediately following byte 
                   |               | framing.
                   |               |
                   |               | After SOH or DLE:
                   |               |
                   |               | Header = 5 bytes
                   |               | CRC = 2 bytes
                   |               | Data = COUNT bytes
                   |               | CRC = 2 bytes
                   |               |
                   |               | After ENQ:
                   |               |
                   |               | Header = 5 bytes
                   |               | CRC = 2 bytes
                   |               |
                   | Transmitter   | Send message immediately
                   |               | after byte framing
                   |               | synchronization sequence.

                          Notes To Table 1 

     1.  The recommended synchronous short synchronization sequence is
         four or more SYN bytes.

     2.  The recommended synchronous long synchronization sequence  is
         eight or more SYN bytes.

     3.  In response to a NAK, to assure that a  receiver  is  in  the
         reframing  mode  and  has  not already framed on an erroneous
         message,  the  transmitter  may   optionally   increase   the
         synchronization sequence to:

         a.  Eight or more all ones bytes (DEL bytes - 255.)  for  the
             asynchronous mode.

         b.  10 or more SYN bytes (150.) for the synchronous mode.


     4.  A simple implementation may precede all messages with a  sync
         sequence.   It  may  also  always send a long synchronization
         sequence, at some cost in time and  efficiency,  since  extra
         synchronization bytes are ignored.

     5.  If modems and/or interfaces require PAD  sequences  to  clear
         them  and  to  assure  transmission  of the last message byte
         prior to transmitter shutdown they should use all ones  bytes
         (DEL bytes - 255.) for synchronous and asynchronous modes.

�Operation                                                      Page 41


5.2  LINK MANAGEMENT

Link management is the process of  controlling  the  transmission  and
reception of data on links where there may be two or more transmitters
and/or receivers actively connected to the same signal channels.  This
will be true of half-duplex point-to-point links, as well as full- and
half-duplex  multipoint  links.   On  half-duplex  links,   only   one
transmitter  may  be  active at a time; on full-duplex links, only one
transmitter may be active in each direction on the link at a time.

A station on such a link may transmit when it  has  been  selected  or
granted ownership of the link.  This ownership is passed by use of the
SELECT flag contained in  all  messages.   A  SELECT  flag  set  in  a
received  message  allows  the  addressed  station  to  transmit after
completing reception of the message.  The SELECT flag also means  that
the  transmitter will cease transmitting after the message is sent, if
this is necessary for the proper operation  of  the  link  type.   The
process  of  receiving  a valid SELECT flag and transmitting is called
selection.   The  interval  between   receiving   the   SELECT   flag,
transmitting,  and  terminating  selection by sending a SELECT flag is
called the selection interval.  A SELECT flag may be sent and received
in  any  DDCMP  message.   If there is no message to send and a SELECT
flag needs to be transmitted, the ACK message is used for sending  the
flag.   A selection timer is used to detect a lost SELECT flag.  It is
started when a station is selected and reset when valid  messages  are
received.  If it expires, no message was received for a timer interval
and it is assumed the messages with the SELECT flag set, either  those
transmitted or received, were in error.

The length of  a  selection  interval  depends  on  the  response  and
throughput  considerations  of  a particular implementation or system.
When a station  is  selected,  it  should  limit  the  length  of  the
selection  interval  to  some  maximum  period, either:  a) by using a
timer to time the length of the interval, b) by  using  a  counter  to
count the number of bytes transmitted, or c) by limiting the number of
data messages  transmitted  during  the  selection  interval.   If  no
explicit  limit  is  implemented  for  half  duplex point-to-point and
multipoint  stations,  transmissions  will  eventually  cease  due  to
unacknowledged  data  messages  exhausting buffer capacity or sequence
numbers.   If  no  explicit  limit  is  implemented  for   full-duplex
multipoint  stations,  the  selection  interval might never terminate,
since messages  may  be  acknowledged  as  other  messages  are  being
transmitted.   Therefore  full-duplex multipoint stations must have an
explicit limit to their selection interval.

When there are two or more receivers on a link (multipoint)  the  ADDR
field  is  used  to  address  the  tributary  stations.   A multipoint
configuration consists of a single control station  and  a  number  of
tributary  stations.   In a point-to-point configuration both stations
are considered control stations.  Address "1"  is  used  in  the  ADDR
field  on  point-to-point  links.  Addresses 1-255 are used to address
tributaries on multipoint links and appear in the ADDR  field  of  all
messages  both  to  and from tributaries.  Address "0" is reserved.  A
tributary will only accept messages that contain  its  address  (after
CRC  checks)  and will ignore all others.  Only SELECT flags set (i.e.
�Operation                                                      Page 42


on) in messages with the matching tributary address  are  accepted  as
selecting  the  addressed  station.   The SELECT flag is always set in
STRT, STACK, and MAINTENANCE messages for all link types.   The  start
up  procedure  and maintenance mode operate in the half-duplex, single
message at-a-time mode for consistency on all link types.



5.2.1  Link Management On Full-Duplex Point-To-Point Links - There  is
effectively no link management required on these links.  Both stations
are control stations and always selected.  The address value 1 is used
in  the  ADDR  field of all messages.  The checking of this address is
optional on reception.  For all messages other than STRT,  STACK,  and
MAINTENANCE,  in  which  the  SELECT  flag  is set, the SELECT flag is
optional in the full-duplex point-to-point  mode  and  is  essentially
ignored.  That is, it may be optionally set on transmission but is not
checked on reception.



5.2.2  Link Management On Half-Duplex Point-To-Point Links - As in the
full-duplex  mode, both stations are control stations and use the ADDR
value 1.   Checking  of  this  on  reception  is  optional.   Stations
transfer  control back and forth by use of the SELECT flag.  A station
setting the SELECT flag in a message  invites  the  other  station  to
transmit  and will shut down its transmitter at the end of the current
message after sending a number of DEL pad  bytes  appropriate  to  the
modem  and  circuit.   A  station  receiving  a valid message with the
SELECT flag set will transmit after completion  of  reception  of  the
current   message.    Depending   on   the   characteristics   of  the
communication channel and modem this may require waiting until any pad
characters  have  been  received  and the carrier has been turned off.
The station ends its selection interval with the SELECT  flag  set  in
its last message transferring control back to the other station.

When a station sends a  SELECT  it  starts  a  selection  timer.   The
selection  timer  is  stopped and restarted when a valid data message,
maintenance  message,  or  control  message  is  received;   or   when
resynchronization  occurs  at  the receiver.  See the message exchange
subhead 5.3 for the description of a valid message.   The  purpose  of
the  selection timer is to detect a lost SELECT flag either to or from
the other station.  It also serves to detect a  loss  of  data  signal
part  way  through  a  message  that  may  not  be  detected  by other
components of the system (e.g.  loss of signal on an asynchronous link
after  receiving  part  of  the  data  field of a message), preventing
deadlocking of the protocol due to a link failure.  If no  message  is
received  when the timer expires, the station assumes the message sent
with the SELECT flag was received in error or the message sent by  the
other  station  which  contained  the return SELECT was in error.  The
station assumes ownership of the link  and  transmits  as  if  it  had
received  a  valid  SELECT  return.   When  a  station is selected and
transmitting, its selection timer is not  running.   The  timer  value
should  be  different  at  both  stations  to  avoid  a  deadlock race
condition.  The value of  the  timer  must  include  such  factors  as
maximum  message  length,  sync  sequence  lengths,  link  speed, link
�Operation                                                      Page 43


turnaround time, and processing delays.

The selection timer detects the loss of the SELECT flag by timing  the
interval  it  takes  to  receive  the  longest  message from the other
station.  It is reset after every message is received.  Typical values
might  be on the order of a few seconds.  To avoid excessive overhead,
(when there is no data traffic)  of  constantly  turning  the  channel
around  and  selecting the other station, a station can delay replying
to a selection for a short period of  time  (typical  value  would  be
10-20%  of select timer value).  The decision to do this and the value
of the delay is based on such factors as:  response time requirements,
message  queuing  delays,  turnaround  time,  and  the duration of the
selection timer.



5.2.3  Link  Management  On   Full-Duplex   Multipoint   Links - DDCMP
supports  configurations  with  a single control station and up to 255
tributaries.  Messages are only exchanged between the control  station
and  the  tributaries.   There  is  no  direct  tributary to tributary
traffic.  The tributaries use address values 1-255.   These  addresses
are  used  in  the  ADDR  field  in  messages  sent  both  to and from
tributaries.

Transmission  from  the  control  station  to  any  tributary  can  be
simultaneous  with  transmission  from  a  selected  tributary  to the
control station.  The control station  must  maintain  separate  error
counters,  starting  sequence  and  state  transition  logic, and data
message number sequences for  each  active  tributary.   The  messages
transmitted  to a given tributary are independent of the messages sent
to any other tributary.  A tributary is only allowed to send after  it
receives  a  message  addressed to it with the SELECT flag on from the
control station.  The control station is allowed to send data messages
(with  SELECT  off) to either the tributary it has just selected or to
any other tributary.  The  control  station  is  allowed  to  transmit
continuously.   A  message  and  associated  SELECT  flag  sent  to  a
tributary are valid only if the data message header  CRC,  maintenance
message  header  CRC, or control message CRC checks and the ADDR field
matches that of the tributary.

The control station uses a selection timer to  recover  from  messages
where  the  SELECT flag has been transmitted or received in error.  It
operates the same as in the  half-duplex,  point-to-point  case.   The
tributaries have no timer and wait to be selected again after ending a
selection interval.

Tributaries  only  accept  messages  with  their  own  addresses.    A
tributary is selected by receiving a message with its address with the
SELECT flag on.  It may  then  transmit  and  it  ends  the  selection
interval  by  setting  the  SELECT  flag  in  its last message.  While
transmitting, it may be simultaneously receiving messages addressed to
it.

The order in which the control  station  selects  tributaries  is  not
defined  in  this  protocol.   The  control  station might select each
�Operation                                                      Page 44


station in turn in round-robin fashion, or it might have one  or  more
lists  that determine the order and frequency of selection.  The lists
might be supplied by a higher level process or might be  developed  by
selecting  all  the  possible  stations  to  determine  which ones are
on-line.

A single physical station is allowed to respond to  several  different
addresses  on  a  multipoint  channel  only  if  it acts as if it were
multiple separate tributaries.  That is, the control station does  not
know that several addresses are located at a single physical station.

Once the control station has selected a tributary, it  must  wait  for
either:

     a.  The addressed tributary returning a message with  the  SELECT
         flag on.

   OR

     b.  The selection timer expiring.

before selecting another tributary.

On data and maintenance messages received by the tributary, the SELECT
flag on is valid if the header CRC and ADDR check even if the data CRC
is in error.  The tributary  must  wait,  however,  until  the  entire
message is received before starting transmission.

Tributary stations track all messages on the link by framing them  and
accepting only those with matching addresses.  They resynchronize only
on non-abutting messages or messages with CRC errors.



5.2.4  Link Management On Half-Duplex Multipoint  Links - These  links
operate  in  the  same  way as the full-duplex multipoint links except
that the control station must cease transmitting  when  it  selects  a
tributary.  It regains control only when:

     a.  It receives a message  with  the  SELECT  flag  on  from  the
         addressed tributary.

   OR

     b.  The selection timer expires.

The control station operates in the same  manner  as  the  half-duplex
point-to-point  control  station  does,  except  that  the  ADDR field
addresses one specific tributary rather than the only other station on
the  link.  The tributary stations operate as if they were full-duplex
tributaries, except, they do not receive while transmitting.
�Operation                                                      Page 45


5.2.5  Link Management Summary Rules - Table 2  summarizes  the  major
modes of operation.


                  Table 2   Link Management Summary


______________________________________________________________________
Mode                 | Summary
                     |                                                
                     |
Full-Duplex          | Always selected.
Point-to-Point       | Uses ADDR = 1.
Control Station      | Checks ADDR on receive (optional).
                     | SELECT flag set (on) in STRT, STACK, and
                     | MAINTENANCE messages.
                     | SELECT flag ignored in other messages (may
                     | be set but not checked on receive).
                     | No selection timer.
                     |                                                
                     |
Half-Duplex          | Selected alternately.
Point-to-Point       | Uses ADDR = 1.
Control Station      | Checks ADDR on receive (optional).
                     | SELECT flag turns link around and selects
                     | other station.
                     | SELECT flag set (on) in STRT, STACK and
                     | MAINTENANCE messages.
                     | Selection timer used by both stations.
                     |
                     | Selection timer rules:
                     | 
                     | 1.  Start when sending SELECT to select
                     |     other station.
                     | 
                     | 2.  Stop and restart when a valid data 
                     |     message, maintenance message, or 
                     |     control message is received.
                     | 
                     | 3.  Stop and restart when resynchronization
                     |     occurs at the receiver.
                     |
                     | 4.  Stop timer when receiving a SELECT
                     |     (being reselected).
                     | 
                     | 5.  If the timer expires, treat as if a 
                     |     valid SELECT had been received.
                     |                                                
�Operation                                                      Page 46


              Table 2.  Link Management Summary (Cont'd)
______________________________________________________________________
Mode                 | Summary
                     |                                                
                     |
Full-Duplex          | Always selected.
Multipoint           | Uses tributary address in ADDR field (1-255).
Control Station      | Checks for proper tributary ADDR on receive
                     | SELECT flag set (on) in STRT, STACK, and
                     | MAINTENANCE messages.
                     | Start selection timer when selecting a
                     | tributary.
                     | Timer operates as indicated for Half-Duplex
                     | Point-to-Point mode.
                     | Select another tributary when SELECT is
                     | received or selection timer expires.
                     |                                                
                     |
Full-Duplex          | Selected on receipt of SELECT where CRC and
Multipoint           | ADDR checks.
Tributary Station    | Ends selection with SELECT set in last 
                     | message.
                     | Uses its own address in ADDR field
                     | Accepts received messages with matching ADDR.
                     | SELECT flag set in STRT, STACK, and 
                     | MAINTENANCE messages.
                     | No selection timer for tributaries.
                     |                                                
                     |
Half-Duplex          | Selected alternately with tributaries.
Multipoint           | Uses tributary address in ADDR field.
Control Station      | Checks for proper tributary ADDR on receive.
                     | SELECT flag set in STRT, STACK, and
                     | MAINTENANCE messages.
                     | Selection timer used when selecting a 
                     | tributary (same as for full-duplex 
                     | multipoint control stations).
                     |                                                
                     |
Half-Duplex          | Same as Full-Duplex Multipoint Tributary
Multipoint           | station except that it does not receive
Tributary Station    | while transmitting.
                     |                                                

�Operation                                                      Page 47


5.3  MESSAGE EXCHANGE

Using the framing and  link  management  mechanisms  described  above,
messages  are  exchanged  by the protocol modules to create a protocol
that ensures the sequentiality and integrity of data sent  via  DDCMP.
The  basic  concepts  of  this  exchange were presented in subhead 2.5
Functional Organization.  This section presents the  details  of  that
message exchange mechanism.

Before discussing the actual message exchanges,  three  concepts  must
first be presented:

     a.  Initialization

     b.  Reply Time-outs

     c.  Valid messages




5.3.1  Initialization - DDCMP can operate in two modes:

     a.  The on-line, or running, mode.

   and

     b.  The off-line, or maintenance, mode.

The on-line mode creates the sequential error-free link.  The off-line
or  maintenance  mode  provides  a  data  integrity block check, DDCMP
framing, and link management procedures.  The on-line mode is  entered
via  a  DDCMP  start sequence.  This start-up or initialization resets
the message numbering, clears any outstanding  messages  and  prepares
for  the  start  of  data  message  transfers.   The start sequence is
designed so that both stations must enter the  start  sequence  before
either  station can complete the sequence and the message exchange can
commence.  Start-up or restart is initiated by the user of DDCMP  when
it  first  starts up, on a fatal error, usually on a persistent error,
and wherever else restarting is  appropriate  (See  subhead  6,  Error
Recording).  DDCMP does not initiate start-up itself.



5.3.2  Reply Time-outs - A necessary component of DDCMP is  the  reply
time-out.   The  replies to some transmitted messages are timed and if
there is no response within a time-out interval the expiration of  the
timer  triggers recovery action.  The time-out is necessary to recover
from outages and messages distorted by the link such that even framing
may be lost.  Time-outs prevent the protocol from being deadlocked.

The timer is keyed to the selection of a station.  That is, a  station
is  given  a  chance  to respond during a selection interval and if no
proper response is received before the end of the  selection  interval
then  error  recovery  is  initiated.   In  full-duplex point-to-point
�Operation                                                      Page 48


links, where each station is always selected, a clock is used  as  the
timer.  On the other link configurations, the time-out interval is set
to be one selection interval and  expires  at  the  end  of  the  next
selection of the selected station.  A station is given one interval to
reply.  A message with the SELECT flag set  is  processed  before  the
SELECT flag itself is processed to denote the beginning or ending of a
selection interval.  A more  detailed  description  of  the  selection
process is given in subhead 5.2, Link Management.



5.3.2.1  Reply Timer Interval - The reply timer controls  the  maximum
period  a  station will wait between sending a message and receiving a
proper response  before  taking  error  recovery  action.   The  timer
interval for each station type is as follows:

     a.  Point-to-Point

         Full-Duplex:  Uses a real clock.  The  clock  period  is  the
         same  as that of the selection timer used in other modes.  It
         must include link delays, turnaround, processing and  message
         transmission  times.   A  typical  value is three seconds for
         telephone type channels.

         Half-Duplex:  Next selection interval.  The other station  is
         given  a  selection  interval in which to respond.  The other
         station  is  selected,  it  transmits  (if  it  received  the
         selection  correctly),  and  selection is ended (by the other
         station sending a select or by the selection timer expiring).
         If  the  proper  reply  is not returned in that interval, the
         reply timer is assumed to have expired.

     b.  Multipoint

         Full-Duplex-Control   Station:    Next   complete   selection
         interval.   A  tributary  is  given  at  least  one  complete
         selection  interval  in  which  to   reply.    For   messages
         transmitted to a tributary that is not selected, operation is
         as described for half-duplex point-to-point (see above).  For
         messages  transmitted  to  a  tributary that is selected, the
         tributary is expected to reply prior to  the  ending  of  the
         next  selection  interval  rather than prior to the ending of
         the current interval.  That is, a reply timer started  during
         a  selection  interval  does  not expire until the end of the
         next selection interval, not the current interval.

         Full-Duplex-Tributary Station:  Before  the  next  selection.
         The tributary station expects the control station to reply in
         the interval starting with the tributary sending the  message
         requiring  the  reply,  completing the current selection, and
         ending with the tributary being selected again by the control
         station.   The  message  that  selects the tributary again is
         included in that interval and may contain  the  valid  reply.
         If  there  is no proper response within that interval between
         selections the tributary assumes the timer has expired.
�Operation                                                      Page 49


         Half-Duplex-Control Station:  The  next  selection  interval.
         Same   as  described  above  for  half-duplex  point-to-point
         stations.

         Half-Duplex-Tributary Station:  Before  the  next  selection.
         Same  as described above for full duplex multipoint tributary
         stations with the addition that the reply cannot be  received
         before  ending  the  current selection due to the half-duplex
         mode.

Only point-to-point full-duplex control stations use a real clock; all
others  key  reply  time-out  to  a  selection  interval as indicated.
Half-duplex and multipoint control stations use a real clock  to  time
the  selection interval.  Tributary stations have no clock and rely on
the control station for timing intervals (selection).



5.3.3  Valid Messages - Only  valid  messages  are  processed  by  the
protocol.  A message that has been properly framed is checked for:

     a.  Good block checks (header and data).

     b.  Valid message TYPE and SUBTYPE - control messages.

     c.  Matching ADDR for multipoint stations.

Optionally, a station may check for:

     a.  FILL fields for being zero.

     b.  ADDR=1 for point-to-point stations.

Multipoint tributary stations must ignore messages with  header  block
check  errors,  due  to the uncertainty of the ADDR field, and rely on
time-outs  for  recovery.   Control   stations   (point-to-point   and
multipoint)  may process messages with header block check errors (e.g.
reply with NAK), as they would process messages with data block  check
errors.

Additional checks are specific to each message and  are  described  in
the state tables where appropriate.



5.3.4  Message Exchange Variables And  States - The  following  states
and  variables  are  used  in  the  message  exchange state tables and
descriptions.  On multipoint links, there  is  a  set  of  states  and
variables  for  each  control  station  -  tributary  station pair.  A
multipoint link appears logically  as  multiple  point-to-point  links
operating  on  a  single physical channel.  Arithmetic and comparisons
between the variables listed below are always computed modulo 256.
�Operation                                                      Page 50


5.3.4.1  Data Variables -

R = The number of the highest sequential data message received at this
    station.   Sent  in the RESP field of data messages, ACK messages,
    and NAK messages as acknowledgement to the other station.

N = The number of the highest sequential data message  transmitted  by
    this  station.   Sent  in the NUM field of REP messages.  N is the
    number assigned to the last user transmit request  that  has  been
    transmitted (sent in the NUM field of that data message).

A = The number of the highest sequential data message  that  has  been
    acknowledged  to this station.  Received in the RESP field of data
    messages, ACK messages, and NAK messages.

T = The number of the next  data  message  to  be  transmitted.   When
    sending  new  data  messages  T  will  have  the  value N+1.  When
    retransmitting T will be set back to A+1 and will advance to N+1.

X = The  number  of  the  last  data  message   that   has   completed
    transmission.   When  a  new  data  message  has  been  completely
    transmitted, X will have the value  N.   When  retransmitting  and
    receiving   acknowledgements   asynchronously   with   respect  to
    transmission, X will have some value less than or equal to N.

Other variables are as defined in the message format section and refer
to  fields  in specific messages (e.g., ACK(RESP=0) refers to the RESP
field of an ACK message with value = 0).  ACKs refer to receiving  the
RESP  field  value  in  an ACK, NAK, or DATA message.  Relationship of
data variables (modulo 256.  arithmetic):

A <= N         The data message numbers from A+1 to N are the  current
               unacknowledged  data  messages.  ACKs within this range
               are valid and accepted.  ACKs outside  this  range  are
               ignored.

A < T <= N+1   If new data messages  are  being  sent  T  =  N+1.   If
               retransmissions are being sent T will lie between A and
               N+1.  If an ACK is received that increments A, T is set
               to  A+1 to start retransmission, possibly skipping some
               data messages in a retransmission sequence  already  in
               progress.

X <= N         The last data message transmitted is always  less  than
               or   equal  to  the  highest  sequential  data  message
               transmitted (N) and may be less than  the  highest  one
               acknowledged  (A) due to retransmissions and the NAKing
               of control message CRC errors.




5.3.4.2  Control Flag Variables - These flags control the  sending  of
DDCMP  control messages.  They are indicators specifying which control
messages to send when the transmitter is idle.
�Operation                                                      Page 51


SACK - Send ACK.  This flag is  set  when  either  R  is  incremented,
       meaning  a  new sequential data message has been received which
       requires an ACK reply, or  a  REP  message  is  received  which
       requires  an  ACK reply.  The SACK flag is cleared when sending
       either a DATA message with the latest RESP  field  information,
       an ACK with the latest RESP field information, or when the SNAK
       flag is set.

SNAK - Send NAK.  This flag is set when a receive  error  occurs  that
       requires a NAK reply.  It is cleared when a NAK message is sent
       with the latest RESP information, or when the SACK flag is set.

The SACK and SNAK flags are mutually exclusive.  At most, one will  be
set  at  a  given  time.   The  events  that  set  the SACK flag, R is
incremented or a REP is received requiring an ACK, also clear the SNAK
flag.   Similarly,  the  events  that  set  the SNAK flag, reasons for
sending a NAK (see Subhead 5.3.7), also clear the SACK flag.   Setting
or  clearing a flag that is already set or cleared respectively has no
effect.  For the SNAK flag, a  reason  variable  (or  field)  is  also
maintained  which  is  overwritten  with  the latest NAK error reason.
Whenever the SNAK flag is set the NAK reason variable is  set  to  the
reason for the NAK.

SREP - Send REP.  This flag is set when a reply timer expires  in  the
       running  state  and a REP should be sent.  It is independent of
       the SACK and SNAK flags.

It is desirable for DDCMP implementations to implement the sending  of
control  messages  via  the  use  of these control flags.  Events that
require control messages to be sent will  overwrite  previous  events,
for  which  the  control messages have not yet been sent, and only the
necessary current control messages will be  sent.   In  general,  this
will  increase  the performance of DDCMP by eliminating the sending of
unnecessary control messages which add to protocol  overhead  and  may
result in unnecessary retransmissions.  It is only necessary to have a
single ACK or NAK, and/or a single REP marked  for  transmission  with
the latest information.  A station when selected to transmit must send
all pending control messages (i.e., clear all pending  control  flags)
before deselecting itself.

It is also possible to implement the sending of control messages via a
queuing  mechanism, which actually builds and adds control messages to
the transmit queue.  In this case,  all  events  that  would  cause  a
control message to be sent must generate a message for the queue.



5.3.4.3  DDCMP States -

HALTED        Protocol stopped and not running.  The user can halt the
              protocol  anytime  by giving it a stop command (see user
              interface description subhead 3.1).  Commands  to  start
              cause a transition through halted first.
�Operation                                                      Page 52


STARTING      An attempt is being made to initialize the protocol  via
              an  exchange of STRT and STACK messages.  This state has
              two internal substates.

              1.  ISTRT (Initiate Start) sends the STRT message.

              2.  ASTRT (Acknowledging Start) sends the STACK message.


RUNNING       Signifies DDCMP is in the on-line mode  exchanging  data
              messages.

MAINTENANCE   Signifies DDCMP is in  the  off-line  mode  sending  and
              receiving maintenance messages.




5.3.5  Message Queueing, Reply Timers,  And  Buffering - Messages  are
passed  from  DDCMP  to a device driver for actual transmission on the
link.  They may be passed either one message at a time, waiting for  a
transmit  complete  before passing the next one to the driver; or more
than one message may be passed  to  the  driver,  letting  the  driver
maintain  a  transmit  queue.   One  message  at  a  time  is the most
efficient method from the message exchange viewpoint, since it  defers
decisions  on  which  message  to transmit next to the latest possible
instant,  making  use  of   the   latest   available   acknowledgement
information.    This  technique,  however,  may  not  be  optimal  for
implementations requiring high performance via queueing and pipelining
techniques.   The  state  tables  for DDCMP message exchange operation
assume single message at a time operation.  If queueing techniques are
used  in an implementation, the operation described in the state table
as "send" will mean  "add  to  transmit  queue"  or  "pass  to  device
driver".

The reply timer on full duplex point-to-point links uses a real clock.
The description of the message exchange operation assumes the timer is
started after the message has been completely  transmitted.   In  this
case,  the  timer  value must include link delays and processing time,
but is independent of the length of the transmitted message.  However,
if  the  timer  is started when the message is passed to the driver it
must also include the time to actually transmit the message.  If  many
messages  are  being  queued  to  the driver, then the timer must also
include the time to transmit all the  messages  ahead  on  the  queue.
These  increases  in  the  timer  value  make  it  less  precise  and,
therefore, it does not perform as  well  as  a  reply  timer  that  is
started  after  actual  transmission.   The  state table describes the
reply timer starting at two possible times:   one  when  messages  are
actually transmitted and the other when they are passed to the driver.
The operation affects the setting of the variable X and  the  starting
of  the  reply  timer.   The  choice  of  technique  in  a  particular
implementation depends on the split of functions  between  the  driver
and DDCMP, the sharing of the protocol data base, and the capabilities
and environment presented by the operating system.  All other  factors
being equal, the best technique uses queueing for high performance and
�Operation                                                      Page 53


starts the timer after actual message  transmission.   On  other  than
full-duplex  point-to-point  links,  the  timer  is  keyed  to station
selection.  The driver transmit queue is always emptied before  ending
selection, and, thus, has no effect on the reply timing.

A message must not be marked complete and returned to the  user  until
the  message is acknowledged.  If the user interface does not separate
the completion or acknowledgement of data messages from the  returning
of  buffers  to  the user (e.g.  transmit buffering is supplied by the
user), then the message must not be returned to the user while  it  is
still  residing  on  the  transmit queue.  This is required to prevent
buffers from being released prematurely and given  back  to  the  user
while  they  are  still  being  used  for  transmission.   If the user
interface separates the completion of data messages from the returning
of buffers (e.g.  transmit buffering is supplied by DDCMP, the message
is copied to a local DDCMP buffer), then the  message  may  be  marked
complete  to  the  user as soon as it is acknowledged, even though the
actual transmit buffer (local to DDCMP) may still be on  the  transmit
queue (i.e., being retransmitted).




5.3.6  Reply Timer Operation Rules -




5.3.6.1  Start Timer: -

     a.  When timer is a clock - set  clock  to  the  interval  value,
         start  it running.  When interval expires, clock will issue a
         signal and stop.

     b.  When timer is another event (e.g.  ending selection interval)
         -  set  flag marking timer as running.  When event occurs and
         flag is set, timer will issue a signal and turn flag off.

     c.  If timer is running when a Start Timer command is issued,  it
         is first stopped and then started.




5.3.6.2  Stop Timer: -

     a.  When timer is a clock - clock is halted, no signal is issued.
         The timer can be set running via the Start Timer command.

     b.  When timer is another event - turn flag off.

�Operation                                                      Page 54


5.3.7  NAK Reasons - NAKs are returned in response to message, device,
and buffering errors in the RUNNING state.

Specifically the NAK reasons are:

NAK Error
Reason Code         NAK Reasons (NAK Message REASON Field)
------ ----         --- -------  --- ------- ------ -----
     1.        Header Block Check Error - A data message header CRC or
               a control message CRC is in error.

     2.        Data Field Block Check Error  -  A  data  message  data
               field CRC is in error.

     3.        REP Response -  The  NAK  is  sent  in  response  to  a
               received REP message where the NUM field in the REP did
               not equal R (the highest sequential message received).

     8.        Buffer Temporarily  Unavailable  -  A  buffer  was  not
               available  to  store the incoming data message.  Either
               the user did not allocate one in time,  or  the  buffer
               pool was empty.

     9.        Receive  Overrun  -  The  receiving   hardware   and/or
               software  was  not  able  to  respond  fast  enough  to
               incoming bytes and an overrun occurred.

     16.       Message Too Long - A received data message (COUNT)  was
               too long for the allocated buffer.

     17.       Message Header Format Error - The  header  CRC  checked
               but  one  or  more header fields was invalid.  Possible
               errors are:

               a.  Invalid SELECT flag,

               b.  Invalid  ADDR  value   (check   is   optional   for
                   point-to-point),

               c.  FILL fields not zero (optional check),

               d.  Invalid control TYPE or SUBTYPE value.




5.3.8  Start-Up - Start-up is the process of initializing the protocol
states  and  variables,  and  synchronizing  both  stations on a link.
Table 3 is the start-up state table.

    Start-Up Notes:

     1.  Implementations  may  ignore  messages  in   error   (invalid
         messages)  or  messages other than that expected and wait for
         the reply timer  to  expire  during  the  start  sequence  to
�Operation                                                      Page 55


         initiate recovery action.

     2.  The SELECT flag is always set in STRT and STACK messages, the
         starting  sequence being an alternate (half-duplex) exchange,
         one message at a time.  For all stations,  except  multipoint
         control stations, the receipt of a STRT or STACK will trigger
         an  immediate  response  due  to  selection  by  these  start
         sequence  messages.   Multipoint  control  stations  need not
         respond immediately to  the  starting  tributaries,  but  may
         select   and   send  messages  to  other  tributaries  before
         returning and completing start-up  with  tributaries  waiting
         for start sequence replies.

     3.  After start-up  is  complete  the  data  variables  have  the
         following values:  R=0, N=0, A=0, T=1, X=0.  The control flag
         variables are all clear.




5.3.9  Data Transfer - This is the process of sending  data  messages,
waiting   for   positive  (ACK)  or  negative  (NAK)  acknowledgement,
retransmitting on NAK, and sending REP on reply time-out to  cause  an
acknowledgement  to  be  returned.  Table 4 is the state table for the
RUNNING State.  These events always leave the stations in the  RUNNING
state.   The  entries that change from RUNNING to the other states are
listed in Table 3, Start-Up State Table.

    Running State Notes:

     1.  All message numbering is  modulo  256  (i.e.,  after  message
         number  255  is  message  0, then 1 and so on).  For example,
         3>250 is correct where 3 follows messages:  255,0,1,2.

     2.  An ACK always sends RESP=R.  A NAK always sends RESP=R and an
         appropriate  NAK  reason.   A REP always sends NUM=N.  A data
         message always sends RESP=R, NUM=assigned sequential  number.
         A  retransmitted  message  always uses the same NUM value and
         DATA field as the original  message,  but  sends  the  latest
         receive value, R, in the RESP field.

     3.  The maximum number of outstanding unacknowledged messages  is
         255.  No more can be sent until some are acknowledged.  It is
         always required that (A + 255) > = N (modulo 256).

     4.  Positive acknowledgements can be sent in the  RESP  field  of
         data  messages  transmitted  in the reverse direction, in ACK
         messages, or in NAK messages.  They  are  all  equivalent  on
         receive   to   providing   a   positive  acknowledgement  for
         outstanding messages.  In the state table, ACK refers to  any
         of the above forms of acknowledgement.

�Operation                                                      Page 56


                        Table 3   Startup State Table

         ______________________________________________________________________
           State  |        Event         | New State |         Action
                  |                      |           |                         
                  |                      |           |
         Any State|User requests halt    | HALTED    |None-stop timer if
                  |                      |           |running
                  |                      |           |                         
                  |                      |           |
         HALTED   |User requests startup | ISTRT     |Send STRT, reset
                  |                      |           |variables, start timer
                  |                      |           |                         
                  |                      |           |
                  |User requests         |MAINTENANCE|See subhead 5.4, 
                  |Maintenance Mode      |           |MAINTENANCE MODE
                  |                      |           |                         
                  |                      |           |
         ISTRT    |Receive STACK         |RUNNING    |Send ACK (RESP=0),
                  |                      |           |stop timer if running
                  |                      |           |
                  |                      |           |
                  |Receive STRT          |ASTRT      |Send STACK, start timer
                  |                      |           |
                  |                      |           |
                  |Timer expires         |ISTRT      |Send STRT, start timer
                  |                      |           |
                  |                      |           |
                  |Receive MAINT message |MAINTENANCE|See subhead 5.4,
                  |                      |           |MAINTENANCE MODE
                  |                      |           |
                  |                      |           |
                  |Message in error or   |ISTRT      |Either:  Send STRT,
                  |other message received|           |start timer; or
                  |                      |           |ignore(do nothing)
                  |                      |           |                         
�Operation                                                      Page 57


                         Table 3.  Startup State Table (Cont'd)
         ______________________________________________________________________
           State  |        Event         | New State |         Action
                  |                      |           |                         
                  |                      |           |
         ASTRT    |Receive ACK (RESP=0)  |RUNNING    |See Data Transfer;
                  |or Receive Data msg   |           |stop timer
                  |(RESP=0)              |           |
                  |                      |           |
                  |                      |           |
                  |Receive STACK         |RUNNING    |Send ACK (RESP=0),
                  |                      |           |stop timer
                  |                      |           |
                  |                      |           |
                  |Receive STRT          |ASTRT      |Send STACK,
                  |                      |           |start timer
                  |                      |           |
                  |                      |           |
                  |Timer expires         |ASTRT      |Send STACK,
                  |                      |           |start timer
                  |                      |           |
                  |                      |           |
                  |Receive MAINT message |MAINTENANCE|See subhead 5.4,
                  |                      |           |MAINTENANCE MODE
                  |                      |           |
                  |                      |           |
                  |Message in error or   |ASTRT      |Either: Send STACK,
                  |other message received|           |start timer; or
                  |                      |           |ignore (do nothing)
                  |                      |           |                         

     5.  The order for transmitting messages in the running state  is:
         NAK, REP, DATA messages, ACK.

     6.  A  data  message  contains   four   independent   pieces   of
         information:

         a.  Data consisting of the NUM, COUNT, and DATA fields.

         b.  An ACK response consisting of the RESP field.

         c.  Link management information consisting  of  an  ADDR  and
             SELECT flag.

         d.  Framing information consisting of the QSYNC flag.

         These are independent of each other and  treated  separately.
         Thus,  a  received data message is treated as both a received
         data message and a received ACK.  For example,  even  if  the
         DATA CRC is in error the RESP field in a good header is still
         accepted and processed.

     7.  When a message that  starts  or  ends  a  selection  interval
         (SELECT  flag  set)  is received, the message exchange fields
         (RESP, NUM, COUNT,  DATA)  are  processed  according  to  the
�Operation                                                      Page 58


         message  exchange  rules  (Table  4) prior to the starting or
         ending of the selection interval.  For example, a RESP  field
         which  acknowledges  one  or  more  outstanding messages will
         complete those messages and stop the  reply  timer  prior  to
         processing   the  SELECT  flag.   If  the  SELECT  flag  were
         processed first, the reply timer might erroneously expire.

     8.  If there is no message to send in the RUNNING  state,  and  a
         SELECT  flag  wants  to be sent, use the ACK message for this
         purpose.  ACKs are legal at any time and may be used for time
         fill and to select and/or terminate selection.

     9.  Messages must never be truncated on transmission.  A  station
         should  always finish transmitting the current message before
         starting a new one, including  retransmissions.   This  is  a
         requirement of the byte count framing technique.

    10.  The SELECT flag can be set in any message.   All  outstanding
         control  messages  must  be  sent  before  a  station  ends a
         selection interval by sending a  SELECT  flag.   A  selection
         interval  is  ended when the message with the SELECT flag set
         is added to the transmit  queue  (given  to  the  driver  for
         transmission),  even  though  the  message  has  not yet been
         transmitted on the physical link.

    11.  The transmitter is idle when it  is  permissible  to  pass  a
         message  to  the  driver.   It  is  busy  when  this  is  not
         permissible.  For non-queued transmission, passing a  message
         to  the  driver  is  permissible  only  when nothing is being
         transmitted  and  the  station  is  selected.    For   queued
         transmission,  passing a message to the driver is permissible
         only when the driver will accept  a  message  (queuing  space
         available) and the station is selected.

         The message with the SELECT flag  set  is  the  last  message
         passed   to   the   driver  in  a  selection  interval.   The
         transmitter will remain busy after passing  this  message  to
         the  driver  until  another  selection interval is started by
         receiving a message with the SELECT flag set.  This technique
         is  necessary to maintain the proper relationship between the
         reply timer and station selection.

    12.  The notation "A <- B" is  the  notation  for  the  assignment
         statement which sets the value of the variable A to the value
         of the variable B.

�Operation                                                      Page 59


                    Table 4   RUNNING State Table

______________________________________________________________________
  State  |        Event         | New State |         Action
         |                      |           |                         
         |                      |           |
RUNNING  |Receive STRT          |HALTED     |Notify user of
         |                      |           |STRT received
         |                      |           |
         |                      |           |
         |Receive MAINT         |MAINTENANCE|See Subhead 5.4,
         |                      |           |MAINTENANCE MODE
         |                      |           |
         |                      |           |
         |Receive STACK         |RUNNING    |Send ACK (RESP=R)
         |                      |           |
         |                      |           |
         |User requests halt    |HALTED     |None Stop timer if
         |                      |           |running                  

The following events and actions occur in the RUNNING  state  and  the
protocol  remains in the RUNNING state, thus the columns for State and
New State are omitted and are implied to be the RUNNING State.

______________________________________________________________________
            Event             |               Action
                              |                                       
                              |
Receive Data Message          | If buffer available, R <- R+1, give
(NUM = R+1)                   | message to user, set SACK flag;
(Also see Receive ACK)        | otherwise set SNAK flag, (reason
                              | 8. or 16.)
                              |
                              |
Receive Data Message          | Ignore
(NUM =/ R+1)                  |
(Also see Receive ACK)        |
                              |
                              |
Receive Message In Error      | Set SNAK flag, see NAK reasons
                              | (subhead 5.3.7)
                              |
                              |
Receive REP                   | Set SACK flag
(NUM = R)                     |
                              |
                              |
Receive REP                   | Set SNAK flag, (reason 3.)
(NUM =/ R)                    | 
                              |                                       
�Operation                                                      Page 60


                Table 4.  RUNNING State Table (Cont'd)
______________________________________________________________________
            Event             |               Action
                              |                                       
                              |
Receive ACK, or Data Message  | For all messages (A < NUM <= RESP),
(A < RESP <= N)               | complete message to user,
                              | A <- RESP
                              | If T <= A, then T <- A+1
                              | If A < X, start timer
                              | If A >= X, stop timer
                              |
                              |
Receive ACK or Data Message   | Ignore
(RESP <= A or RESP > N)       |
                              |
                              |
Receive NAK                   | For all messages (A < NUM <= RESP),
(A <= RESP <= N)              | complete message to user,
                              | A <- RESP
                              | T <- A+1, stop timer
                              |
                              |
Receive NAK                   | Ignore
(RESP < A or RESP > N)        |
                              |
                              |
Reply timer expires           | Set SREP flag
                              |
                              |
Transmitter is idle           | Send NAK with reason value,
and SNAK flag is set          | clear SNAK flag
                              |
                              |
Transmitter is idle,          | Send REP, clear SREP flag,
SNAK flag is clear,           | * start timer
SREP flag is set              |
                              |
                              |
Transmitter is idle           | MSG(T) is retransmitted,
SNAK and SREP flags are clear | * X <- T,
T < N+1                       | * if timer not running start timer
                              | T <- T+1, clear SACK flag
                              |
                              |
User requests message         | User waits until:
to be sent: T < N+1,          | T = N+1, transmitter
transmitter is busy,          | is idle, SNAK flag is clear,
SNAK flag is set, or          | and SREP flag is clear
SREP flag is set              | 
                              |                                       
�Operation                                                      Page 61


                Table 4.  RUNNING State Table (Cont'd)
______________________________________________________________________
            Event             |               Action
                              |                                       
                              |
User requests message         | NUM <- N+1
to be sent, T = N+1,          | Send MSG(NUM)
transmitter is idle,          | N <- NUM
SNAK and SREP flags           | T <- N+1, clear SACK flag
are clear                     | * X <- N,
                              | * if timer not running start timer
                              |
                              |
Transmitter is idle,          | Send ACK, clear SACK flag
SNAK and SREP flags           |
are clear, T = N+1,           |
no user requests waiting,     |
SACK flag is set              |
                              |                                       
* If messages are queued for transmission and the timer is started and
  stopped  after actual transmissions of messages are completed rather
  than when messages are queued, then ignore the asterisk (*)  actions
  listed  above  for  the  events:   Transmitter  is  idle (SREP set),
  Transmitter is idle (T < N+1), and user requests message to be  sent
  (T = N+1) and add the following events and actions:
                              |
Data message (NUM)            | X <- NUM
transmission completed        | If A < X and timer not running,
on link                       |    then start timer
                              | If A >= X, then stop timer
                              |
                              |
REP message transmission      | start timer
completed on link             |
                              |                                       




5.4  MAINTENANCE MODE

Maintenance mode operation is  used  where  the  requirements  dictate
minimum code and compatibility with the DDCMP message structure.  This
is true of bootstrap (load), dump, and test facilities where the  code
might  reside  in  read-only memory (ROM).  Compatibility is necessary
for operation on multipoint channels where one station may be  in  the
maintenance  mode  and  the other stations in the on-line, or running,
mode.   By  using  the  same  structure,  both  functions  can   occur
concurrently on the link using the same control station protocol.

The maintenance mode uses the framing and link management portions  of
DDCMP  without  having  the  complexity  or  the  functionality of the
message exchange facility.  That is, it creates a  frame  or  envelope
for  transmitting  and receiving message blocks and providing a CRC-16
error detection check.  In this mode, there is no  message  sequencing
�Operation                                                      Page 62


or acknowledgement.  Sequencing and acknowledgement, if required, must
be provided by the user of the maintenance mode.

Maintenance mode messages always have the SELECT  flag  set,  so  they
operate  in  the alternate half-duplex mode on both point-to-point and
multipoint channels.  The link management  function  operates  in  the
same  manner  as  described for on-line mode except that only a single
message is transferred before ending selection.  Transmit complete  is
returned  to  the  user  immediately after the message is transmitted,
since there is no ACK returned to guarantee successful  delivery  over
the link.

The maintenance mode is entered via either a command from the user  or
a  received maintenance message.  To return to the on-line (or running
mode) the protocol must first  go  through  the  halted  and  starting
states.   Both  operating  modes  cannot  be  mixed  within  a  single
station-to-station pair.  The exact details of how maintenance mode is
entered  is implementation specific and may vary in different systems.
If a maintenance message is received while not  in  maintenance  mode,
some implementation may enter maintenance mode and present the message
to the user.  Other implementations may discard the message, enter the
HALTED state, and provide an indication that a maintenance message was
received.  Similarly, a received STRT message may cause  the  protocol
to  enter the HALTED state and notify the user of the received STRT or
the protocol may remain in the maintenance state and simply notify the
user  of the received STRT.  The maintenance message header is similar
in format to the data message header except the RESP  and  NUM  fields
are  zero  FILLS  (since maintenance messages are neither numbered nor
acknowledged).  In the maintenance mode, the protocol adds the  header
and  block  check to transmitted messages and starts a select timer if
necessary for proper operation of the channel (e.g., multipoint).   On
received  messages,  the  protocol  removes  the header and checks the
block check.  If in error it may either discard the message or  notify
the  user  that  a message was received with a block check error.  The
latter action improves responsiveness  rather  than  waiting  for  the
timer  to  expire.   It  also  assists in maintaining the link as such
errors can be recorded.

The maintenance mode is used  for  functions  such  as  bootstrapping,
dumping,  and  link  testing.   If  sequencing  or acknowledgement are
necessary it must be done within the data  field  of  the  maintenance
messages.    In  DECnet,  the  maintenance  message  protocol  is  the
Maintenance Operation Protocol (MOP) and is not part of this standard.
Maintenance  mode  messages are not guaranteed to be delivered or have
the assurance that they will arrive in the proper sequence.   If  they
are  delivered,  however, they will have been block checked within the
error limits of the CRC-16  check.   The  STRT  message  is  the  only
non-maintenance message recognized while in the maintenance state; all
others are ignored.

�Operation                                                      Page 63


                  Table 5   Maintenance State Table


______________________________________________________________________
   State   |       Event       | New State |         Action
           |                   |           |                          
           |                   |           |
MAINTENANCE|User requests halt |HALTED     |None-stop timer if running
           |                   |           |
           |                   |           |
           |                   |           |
           |Receive MAINT      |MAINTENANCE|If buffer available
           |                   |           |give to user,
           |                   |           |otherwise ignore
           |                   |           |
           |Message in error   |MAINTENANCE|Ignore
           |or other message   |           |
           |received(not STRT) |           |
           |                   |           |
           | Receive STRT      |MAINTENANCE|Notify user of STRT
           |                   |           |received
           |                   |           |
           |User requests MAINT|MAINTENANCE|If transmitter idle:
           |message to be sent |           |send MAINT message,
           |                   |           |If transmitter busy:
           |                   |           |wait until idle
           |                   |           |                          


                               Note
              
              Transmitter busy and idle conditions have 
              the same meaning as described in the 
              RUNNING State notes (subhead 5.3.9).
              



6  ERROR RECORDING

This section specifies how error recording  may  be  performed  within
DDCMP  implementations.   An implementation may utilize all, a subset,
or  none  of  these  techniques  and  statistics.   The  selection  of
techniques  used  and  statistics  maintained  depends  on  the system
environment and requirements of the application.   It  is  recommended
that  error  recording  be  employed  to  compile  statistics  on  the
condition of the link, determine overall error  rates,  and  detect  a
malfunctioning  link.   The protocol has been designed so that even if
one of the stations on  the  link  cannot  record  errors,  the  other
station  can  be  used to record errors for all communications sent in
both directions on the link.  This is accomplished by use of  the  NAK
reason  field.   For  most errors, the error is recorded locally and a
NAK is returned with  the  error  reason.   The  other  station,  upon
receiving  the  NAK,  can record the error for the remote station.  On
occasion, a NAK will be lost, but this should  not  noticeably  affect
�Error Recording                                                Page 64


the record being kept of a given link.

A station that has no means for reading out  its  counters,  or  whose
controlling user cannot maintain such records, would not maintain them
(e.g.  a transaction terminal).  It is strongly recommended,  however,
that  at  least  one  station on a link maintain error statistics.  On
multipoint links, the control station will maintain a separate set  of
counters  for  each  control-tributary pair.  In the maintenance mode,
error counters and records need not be maintained.

The following defines the  standard  set  of  DDCMP  counters.   These
counters  have  been standardized so that consistent error information
can be provided across a network.  In DECnet, the higher level Network
Management  layer  enables  these  counters  to be accessed locally or
remotely, and captured periodically, maintaining a log  of  data  link
operation.

In  selecting  these  counters  and  specifying  their   encoding,   a
compromise  was reached between the conflicting goals of capturing all
useful information and minimizing required memory  space.   A  further
goal  was to structure these counters so that a subset of the counters
relates directly to the cause of most failures.  The complete  set  is
available for isolating unusual and difficult failures.



6.1  STRUCTURE OF THE COUNTERS

Some counters are maintained for each tributary/control  station  pair
on  a  physical  link.   These  are  called  "Data-Link  Counters" and
"Threshold Counters".  Others are maintained for the physical link  as
a  whole.   These  are  called  "Station  Counters".  Unless otherwise
specified, all counters count up to a maximum value and latch at  that
value  until  cleared.   The  maximum  value  is 2n - 1 where n is the
number of bits in the counter.

Some occurrences are counted twice:

     1.  in a one-bit counter associated with the specific occurrence

     2.  in an 8-bit counter associated  with  a  set  of  occurrences
         having similar diagnostic significance.

Some occurrences are not counted at all.  These are deemed  to  be  of
sufficient  importance that they require special handling described in
Section 7.



6.2  DATA LINK COUNTERS

A point-to-point station maintains a single set of data link counters.
A  multipoint  control  station  maintains a separate set of data link
counters for each tributary.  A multipoint tributary station maintains
a  single  set  of  data  link  counters  unless  it supports multiple
�Error Recording                                                Page 65


tributary addresses; in this case, it supports a separate set for each
supported address.



6.2.1  Data  Errors  Outbound - This  8-bit  group   counter   records
occurrences   which   normally   result   from   data  errors  on  the
communications channel  outbound  from  this  station.   The  specific
errors associated with this counter are those counted on the following
1-bit counters:



6.2.1.1  NAKs Received Header Block Check Error - This  1-bit  counter
records the receipt of NAKs with a reason code of 1.



6.2.1.2  NAKs Received  Data  Field  Block  Check  Error - This  1-bit
counter records the receipt of NAKs with a reason code of 2.



6.2.1.3  NAKs Received REP Response - This 1-bit counter  records  the
receipt of NAKs with a reason code of 3.



6.2.2  Data  Errors  Inbound - This  8-bit   group   counter   records
occurrences   that   normally   result   from   data   errors  on  the
communications channel inbound to this station.  The  specific  errors
associated  with this counter are those counted on the following 1-bit
counters:



6.2.2.1  Header Block Check Errors - This 1-bit  counter  records  the
receipt  of  messages  with header block check errors.  Point-to-point
stations and  multipoint  control  stations  set  the  SNAK  flag  and
associated  NAK  reason  code of 1 in these circumstances.  Multipoint
control  stations  record  this  error  for  the  selected  tributary,
regardless  of  the address field in the received message.  Multipoint
tributary stations record this error only if the address field matches
their station address.



6.2.2.2  NAKs Sent Data Field Block Check Error - This  1-bit  counter
records the setting of the SNAK flag and associated NAK reason code of
2.
�Error Recording                                                Page 66


6.2.2.3  NAKs Sent  REP  Response - This  1-bit  counter  records  the
setting of the SNAK flag and associated NAK reason code of 3.



6.2.3  Local Reply Timeouts - This 8-bit counter  records  occurrences
which normally result from either:

     1.  the  loss  of  communications  between  stations  while  this
         station has data to transmit or,

     2.  the choice of an inappropriate value for this station's reply
         timer.

This counter records REPs sent.  Specifically, it records the  setting
of the SREP flag.



6.2.4  Remote Reply Timeouts - This 8-bit counter records  occurrences
which normally result from either:

     1.  the loss of communication between stations while  the  remote
         station has data to transmit or,

     2.  the choice of an inappropriate value for the remote station's
         reply timer.

This counter records ACKs sent in response to a REP.  Specifically, it
records the setting of the SACK flag when a REP is received with NUM =
R.



6.2.5  Local  Buffer  Errors - This  8-bit   group   counter   records
occurrences  which  normally  result  from  the failure of the user of
DDCMP at this station to properly coordinate  the  supply  of  receive
buffers  at this station to data messages supplied by the remote user.
The specific errors associated with this counter are those counted  in
the following 1-bit counters:



6.2.5.1  NAKs Sent Buffer Temporarily Unavailable - This 1-bit counter
records the setting of the SNAK flag and associated NAK reason code of
8.



6.2.5.2  NAKs Sent Buffer Too Small - This 1-bit counter  records  the
setting of the SNAK flag and the associated NAK reason code of 16.
�Error Recording                                                Page 67


6.2.6  Remote  Buffer  Errors - This  8-bit  group   counter   records
occurrences  which  normally  result  from  the failure of the user of
DDCMP at the remote station  to  properly  coordinate  the  supply  of
receive  buffers at that station to data messages supplied by the user
of DDCMP at this station.  The specific errors  associated  with  this
counter are those counted in the following 1-bit counters:



6.2.6.1  NAKs Received  Buffer  Temporarily  Unavailable - This  1-bit
counter records the receipt of NAKs with a reason code of 8.



6.2.6.2  NAKs Received Buffer Too Small - This 1-bit  counter  records
the receipt of NAKs with a reason code of 16.



6.2.7  Selection   Timeouts - This   8-bit   group   counter   records
occurrences  on a half-duplex or multipoint line which normally result
from

     1.  loss of communication with a remote station,

     2.  data errors on the communications channel  to  or  from  that
         station, or,

     3.  the choice of  an  inappropriate  value  for  this  station's
         Select Timer.

This counter is maintained only by point-to-point half-duplex stations
and  multipoint  control stations; it is not maintained by full-duplex
point-to-point stations or  by  multipoint  tributary  stations.   The
specific  errors associated with this counter are those counted in the
following 1-bit counters:



6.2.7.1  No  Reply  To  Select - This  1-bit  counter   is   used   by
point-to-point  half-duplex  and multipoint control stations to record
selection intervals in which no transmission  was  received  from  the
tributary  and  in  which  no  attempt  to transmit could be detected.
Specifically, it  records  expiration  of  the  select  timer  without
receipt  of  a  valid  control  message or a valid header to a data or
maintenance  message,  and   without   detection   of   an   attempted
transmission.   Detection of an attempted transmission is optional and
is implementation dependent.  Typical means include:

     1.  presence of a carrier signal,

     2.  receipt of a DDCMP synchronization sequence, and

     3.  receipt of an SOH, ENQ, or DLE.
�Error Recording                                                Page 68


6.2.7.2  Incomplete Reply To Select - This 1-bit counter  is  used  by
point-to-point  half-duplex  and multipoint control stations to record
selection intervals which were not properly terminated by receipt of a
message  header  with  SELECT flag on, during which a transmission was
received from the tributary or an attempt to  transmit  was  detected.
Specifically, it records expiration of the select timer preceded by

     1.  receipt of a valid control message,

     2.  receipt of a valid header to a data or  maintenance  message,
         or

     3.  detection of an attempted transmission.  (Refer to "No  Reply
         to Select").




6.2.8  Data  Messages  Transmitted - This   32-bit   counter   records
messages transmitted by this station.  It can be used as a statistical
base when evaluating the number of data errors outbound,  local  reply
time-outs,  and  remote  buffer  errors.   This  counter  records  new
messages sent.  Specifically, it records the  number  of  times  N  is
incremented.



6.2.9  Data Messages Received - This 32-bit counter  records  messages
received  by  this station.  It can be used as a statistical base when
evaluating the number of data errors inbound, remote reply  time-outs,
and  local buffer errors.  This counter records new messages received.
Specifically, it records the number of times R is incremented.



6.2.10  Selection  Intervals - This  16-bit   counter   is   used   by
half-duplex  and  multipoint  control  stations.   It can be used as a
statistical base when evaluating the number of selection time-outs.

This counter records the number of  times  this  station  selects  the
other  station.   Specifically,  it  records  the  number  of messages
transmitted with the SELECT flag on.



6.2.11  Data Bytes  Transmitted - This  32-bit  counter  records  data
bytes transmitted by this station.  It can be used, together with Data
Messages Transmitted, to determine the traffic load outbound.

This counter records new bytes sent.  Specifically, it is  incremented
by COUNT when N is incremented.
�Error Recording                                                Page 69


6.2.12  Data Bytes Received - This 32-bit counter records  data  bytes
received by this station.  It can be used, together with Data Messages
Received, to determine the traffic load inbound.

This  counter  records  new  bytes  received.   Specifically,  it   is
incremented by COUNT when R is incremented.



6.3  STATION COUNTERS

The following counters record unusual occurrences.  They  may  be  the
result of

     1.  a hardware or software fault at this station,

     2.  a hardware or software fault at a remote station, or,

     3.  a data error on the communications channel undetected by  the
         header  block  check  field.  (Except as otherwise noted each
         type of station maintains a single set of these counters.)

Because these errors are not related to  normal  channel  faults,  and
thus are not normal occurrences, the memory required to count these on
a per tributary basis is not justified.  Consequently a single set  of
counters is used for all tributaries on a multipoint line.



6.3.1  Remote  Station  Errors - This  8-bit  group  counter   records
occurrences  most often caused by a fault in a remote station or by an
undetected data error on the channel inbound  to  this  station.   The
specific  errors associated with this counter are those counted in the
following 1-bit counters:



6.3.1.1  NAKs Received Receive Overrun - This  1-bit  counter  records
the receipt of NAKs with a NAK reason code of 9.



6.3.1.2  NAKs Sent Message Header Format  Error - This  1-bit  counter
records the setting of the SNAK flag and associated NAK reason code of
17.



6.3.1.3  Selection Address Errors - This  1-bit  counter  records  the
receipt  of  a  message  by a multipoint control station containing an
address field which does  not  match  the  address  of  the  currently
selected tributary.  It is not used by other stations.
�Error Recording                                                Page 70


6.3.1.4  Streaming Tributaries - The 1-bit counter  is  only  used  by
point-to-point   half-duplex  and  multipoint  control  stations.   It
records the occurrence of  a  point-to-point  half-duplex  station  or
multipoint tributary station either:

     1.  exceeding an  implementation-dependent  maximum  transmission
         interval without releasing the channel or

     2.  failing to release the channel following  transmission  of  a
         message with the SELECT flag on.

Specifically, it records the occurrence of any of the following after:

     1.  the maximum transmission interval has expired, or

     2.  a message with SELECT flag on is received:

         a.  Receipt of a valid control message or message header.

         b.  Detection of attempted transmission  (see  "No  Reply  to
             Select").





6.3.2  Local  Station  Errors - This  8-bit  group   counter   records
occurrences  most  often  caused  by  a fault in this station or by an
undetected data error on the channel outbound from this station.   The
specific  errors associated with this counter are those counted in the
following 1-bit counters:



6.3.2.1  NAKs Sent Receive Overrun - This 1-bit  counter  records  the
setting of the SNAK flag and associated NAK reason code of 9.



6.3.2.2  Receive Overruns, NAK Not Sent - This 1-bit  counter  records
the occurrence of a receive overrun when a NAK could not be sent.  For
all stations this can occur  when  the  state  is  not  RUNNING.   For
multipoint  tributary  stations  this  can  occur if an overrun occurs
while receiving a header.



6.3.2.3  Transmit   Underruns - This   1-bit   counter   records   the
occurrence of transmit underrun errors.  A transmit underrun occurs if
the transmitting  hardware  and/or  software  is  unable  to  generate
outgoing bytes fast enough.
�Error Recording                                                Page 71


6.3.2.4  NAKs  Received  Message  Header  Format  Errors - This  1-bit
counter records the receipt of NAKs with a NAK reason code of 17.



6.4  THRESHOLD ERROR COUNTERS

A point-to-point station maintains a single set of threshold counters.

A multipoint  control  station  maintains  a  separate  set  for  each
tributary.   A  multipoint  tributary maintains a single set unless it
supports multiple tributary addresses; in  this  case  it  supports  a
separate set for each supported address.

Threshold error counters are used  to  determine  when  certain  error
conditions  have  occurred so many consecutive times that a persistent
fault probably exists.   Whenever  a  threshold  counter  reaches  its
maximum value, Network Management and the DDCMP user are informed.  In
the  RUNNING  state  threshold  counters  are  cleared  when   Network
Management  and  the  DDCMP  user  are  informed,  so that they can be
continually informed of a persistent fault.  In the  ISTRT  and  ASTRT
states, threshold counters are not cleared when Network Management and
the DDCMP user are informed, so that  they  will  not  be  continually
informed of an inoperative remote station.

DDCMP continues to operate across  threshold  counter  overflows.   It
clears  the threshold counters and counts again, notifying the user on
subsequent overflows.  Protocol and link shutdown is left  up  to  the
user.

The specific threshold counters are as follows:



6.4.1  Transmit Threshold Errors - This 3-bit counter is  incremented,
if less than 7, in the following circumstances:

     1.  In the ISTRT state when a STRT is sent

     2.  In the ASTRT state when a STACK is sent

     3.  In the RUNNING state

         a.  upon receipt of a NAK with  reason  code  not  =  3  (REP
             response)

         b.  upon setting the SREP flag


The counter is cleared in the following circumstances:

     1.  Upon entering the ISTRT, ASTRT, and RUNNING states

     2.  In the RUNNING state
�Error Recording                                                Page 72


         a.  upon reporting a transmit threshold error

         b.  upon receiving a NAK, ACK, or DATA message  acknowledging
             a new message (A < RESP <= N).

         c.  upon receiving an NAK,  ACK,  or  DATA  message  when  no
             messages are outstanding (A = RESP = N).





6.4.2  Receive Threshold Errors - This 3-bit counter  is  incremented,
if  less  than  7, in the RUNNING state when setting the SNAK flag and
the associated NAK reason code to one of the following values:

     1.  (header block check error)

     2.  (data field block check error)

     3.  (REP response)

     8.  (buffer temporarily unavailable)

    17.  (message header format error)

This counter is cleared in the following circumstances:

     1.  Upon entering the ISTRT, ASTRT, and RUNNING states.

     2.  Upon receipt of a DDCMP  control  message  without  a  header
         format error and having a correct header block check.

     3.  Upon receipt of a DDCMP data message without a header  format
         error and having correct header and data field block checks

     4.  In the RUNNING state,  upon  reporting  a  receive  threshold
         error.




6.4.3  Selection Threshold Errors - This 3-bit counter is only used by
multipoint  control  stations and half-duplex point-to-point stations.
It is incremented, if less than 7, upon an occurrence recorded by  the
Selection  Time-outs counter.  It is cleared upon receipt of a message
with the select bit on from the other station on point-to-point  lines
or  from  the  selected station on multipoint lines.  It is cleared in
the RUNNING state upon reporting a selection threshold error.



6.5  NETWORK MANAGEMENT INTERFACE SUPPORTING THE DDCMP COUNTERS

The following functions comprise an interface which allows  access  to
�Error Recording                                                Page 73


the  DDCMP counters by higher level software.  In DECnet this software
resides in the Network Management layer.



6.5.1  Read Data Link Counters (ADDR) - This function returns all  the
counters  defined  in subhead 6.2 for a data link.  For point-to-point
stations the ADDR argument is not used.  For  multipoint  stations  it
specifies the tributary address.



6.5.2  Read  And  Clear  Data  Link  Counters  (ADDR) - This  function
operates exactly as Read Data Link Counters, except that after reading
the data link counters it clears them.



6.5.3  Read Station Counters - This function returns all the  counters
defined in subhead 6.3.



6.5.4  Read  And  Clear  Station  Counters - This  function   operates
exactly as Read Station Counters except that after reading the station
counters it clears them.
�Error Recording                                                Page 74


6.6  SUMMARY

Table 6 summarizes the DDCMP counters.

                      Table 6   DDCMP Counters

                          Data Link Counters
                             
8-, 16- & 32 bit Counters    Associated 1-bit Counters
-------------------------    -------------------------
Data Errors Outbound         NAKs Received Header Block Check Error
                             NAKs Received Data Field Block Check Error
                             NAKs Received REP Response
Data Errors Inbound          Header Block Check Errors
                             NAKs Sent Data Field Block Check Error
                             NAKs Sent REP Response
Local Reply Time-outs
Remote Reply Time-outs
Local Buffer Errors          NAKs Sent Buffer Temporarily Unavailable
                             NAKs Sent Buffer Too Small
Remote Buffer Errors         NAKs Received Buffer Temporarily
                               Unavailable
                             NAKs Received Buffer Too Small
Selection Time-outs          No Reply to Select
                             Incomplete Reply to Select
Data Messages Transmitted
Data Messages Received
Selection Intervals
Data Bytes Transmitted
Data Bytes Received


                           Station Counters

8-bit Counters               Associated 1-bit Counters
--------------               -------------------------
Remote Station Errors        NAKs Received Receive Overrun
                             NAKs Sent Message Header Format Error
                             Selection Address Errors
                             Streaming Tributaries
                                   
Local Station Errors         NAKs Sent Receive Overrun
                             Receive Overruns, NAK not sent
                             Transmit Underruns
                             NAKs Received Message Header Format
                             Errors
Threshold Error Counters
Receive Threshold Errors
Transmit Threshold Errors
Selection Threshold Errors

�Event Logging                                                  Page 75


7  EVENT LOGGING

Certain events in the operation of DDCMP may be of immediate  interest
to  network  operations  and  maintenance personnel.  Other events, if
logged, may facilitate detecting and isolating  faults  which  prevent
correct or efficient protocol operation.  This specification defines a
complete set of events and  associated  information.   Standardization
enables  consistent  capture, transmission, storage and interpretation
of events across a network.  The implementation of  event  logging  is
optional.   Some implementations may include all, none, or a subset of
these events.

In selecting these events, two criteria were used:

     1.  An  event  was  included  if  it  had   potential   real-time
         significance to the operation of the network.

     2.  An event was included if it provided information facilitating
         the  detection  and  isolation  of faults not provided by the
         error counters.  This  is  the  case  where  the  timing  and
         sequence  of events might be significant, or where the use of
         counters to capture  details  of  infrequent  occurrences  is
         impractical.

In DECnet, the Network Management layer has facilities  for  capturing
events, selectively filtering based on operator control, time stamping
events, transmitting events, and logging events.   If  DDCMP  is  used
outside  of  DECnet,  similar  facilities  will  be required for event
logging to be a useful tool.

Events are numbered for identification.  It is assumed that the  event
logging  mechanism can filter each numbered event separately.  Several
similar events are sometimes combined into a numbered class.  In these
cases, filtering is done on a class basis.

The data captured by some events  includes  optional  fields.   It  is
recommended  that  this  information  be provided:  however, it is not
required.

The events are as follows:



7.1  LOCALLY-INITIATED STATE CHANGE

Information captured:

      o  Event number = 1.

      o  Tributary Address (1 on point-to-point links)

      o  Old State

      o  New State
�Event Logging                                                  Page 76


This event occurs when the state of the data link changes as a  result
of  a  command  issued  locally  by  the  user of DDCMP.  The possible
transitions are:

         HALT --> ISTRT,

         HALT --> MAINTENANCE,

         ISTRT --> HALT,

         RUNNING --> HALT,

         MAINTENANCE --> HALT.




7.2  REMOTELY INITIATED STATE CHANGE

Information captured:

      o  Event number = 2.

      o  Tributary address

      o  Old State

      o  New State

This event occurs when the state of the data-link changes as a  result
of  a command by the remote user of DDCMP.  The possible state changes
are:

         ISTRT --> RUNNING,

         ASTRT --> RUNNING,

         RUNNING --> HALT,

         RUNNING --> MAINTENANCE,

         MAINTENANCE --> HALT,

         ISTRT --> ASTRT (optional).




7.3  STRT RECEIVED WHILE IN MAINTENANCE

Information captured:

      o  Event number = 3.
�Event Logging                                                  Page 77


      o  Tributary address

This event occurs when a  STRT  message  is  received  in  MAINTENANCE
state.



7.4  TRANSMIT ERROR THRESHOLD REACHED

Information captured:

      o  Event number = 4.

      o  Tributary address

      o  All Data Link Counters for the Tributary

      o  All Station Counters for the Line

This event occurs when the Transmit Threshold  Error  Counter  reaches
the value 7.



7.5  RECEIVE ERROR THRESHOLD REACHED

Information captured:

      o  Event number = 5.

      o  Tributary address

      o  All Data Link Counters for the Tributary

      o  All Station Counters for the line

This event occurs when the Receive Threshold Error Counter reaches the
value 7.



7.6  SELECTION ERROR THRESHOLD REACHED

Information captured:

      o  Event number = 6.

      o  Tributary address

      o  All Data Link Counters for the Tributary

      o  All Station Counters for the line

This event occurs when the Selection Threshold Error  Counter  reaches
the value 7.
�Event Logging                                                  Page 78


7.7  MESSAGE HEADER FORMAT ERRORS

The following information is recorded:

      o  Event type = 7.

      o  Tributary address

      o  complete header, optionally

This event occurs when the SNAK flag is set with associated NAK reason
code of 17.  Recording the complete header is optional.



7.8  SELECTION ADDRESS ERRORS

The following information is recorded:

      o  Event type = 8.

      o  Tributary address in received message

      o  Tributary address selected

      o  Optionally, previously selected tributary address

This event occurs only for a multipoint control  station.   It  occurs
when  the  control station receives a message which does not match the
address of the currently selected tributary.



7.9  STREAMING TRIBUTARIES

The following information is recorded:

      o  Event type = 9.

      o  Tributary address (of last selected tributary)

      o  Address in header (if available, otherwise 0)

      o  Event sub-type:

          0  Streaming tributary

          1  Continued transmission following time-out

          2  Continued transmission after deselection

          3  End of continued transmission


This event records the potential jamming of a  multipoint  line  by  a
�Event Logging                                                  Page 79


defective   tributary  or  a  point-to-point  half-duplex  line  by  a
defective station.  It is recorded by multipoint control stations  and
point-to-point  half  duplex stations.  The specific circumstances are
indicated by an event sub-type.

A streaming tributary (sub-type 0) is a tributary which  continues  to
transmit  valid  control  messages,  or  message  headers  for data or
maintenance messages, beyond the end of  an  implementation  dependent
time-out.    It   indicates   a   fault  in  the  remote  station,  or
inappropriate choice of timer in this station or the  remote  station.
This  event  is  only  recorded for the first header which exceeds the
time limit.

Some implementations may detect continued use of the  channel  inbound
by  a  tributary  when  no good data is being received.  There are two
cases:  (sub-type 1) where the  tributary  exceeds  a  time  limit  on
maximum  transmission,  and  (sub-type 2) where the tributary fails to
release the channel after sending a message with the SELECT  flag  on.
Either  condition  usually indicates a fault in the tributary hardware
or software.

Events of sub-type 1 and 2 are reported only  once  for  a  continuous
fault.   When the fault clears, an event is generated (sub-type 3) and
subsequent occurrences will then be reported.



7.10  NAKS SENT BUFFER TOO SMALL

The following information is recorded:

      o  Event type = 10.

      o  Tributary address

      o  count in received header

      o  buffer size available

This event is optional.  It is recorded when the  corresponding  error
is counted.
�











                              APPENDIX A

                               GLOSSARY



Asynchronous Serial Data Transmission  -  A  technique  in  which  the
    information  required  to  determine when each byte (bit grouping)
    begins is sent along with the byte (the "start" and "stop"  bits).
    The time interval between successive bytes is unspecified.

Channel - The data path joining two or more  stations,  including  the
    communications control capability of the associated stations.

Control Station -  A  station  that  has  overall  responsibility  for
    orderly operation of the channel.

Duplex  Channel  -  A  channel  over  which  simultaneous  (in   time)
    communications  in  both  directions  (to and from the station) is
    possible.  Also called a full-duplex channel.

Half-Duplex Channel (Alternate  Simplex)  -  A  channel  that  permits
    two-way communications, but in only one direction at any instant.

    Master Station - A station that has control  of  a  channel  at  a
    given instant, for the purpose of sending data messages to a slave
    station (whether or not it actually does).  Also referred to as  a
    "transmitting station".

Multipoint Channel - A channel connecting more than two stations.

Parallel Data Transmission - A data communication technique  in  which
    more  than  one  code  element (i.e., bit) of each byte is sent or
    received simultaneously.

Point-to-Point Channel - A channel connecting only two stations.

Serial Data Transmission - A data communication technique in which the
    code  element  (bits)  of each encoded symbol of the data are sent
    and  received  one  after  the  other  (serially),   rather   than
    simultaneously.

Slave Station - A station to which a master station intends to or does
    send a data message.  Also referred to as a "receiving station".

Station -  An  independently  controllable  configuration  of  logical
�GLOSSARY                                                      Page A-2


    elements  (e.g.,  a  computer)  to  or  from  which  messages  are
    transmitted on a channel.

Synchronous Serial Data Transmission - A data communication  technique
    in  which  the  information  required  to determine when each byte
    begins is sent at the beginning of a group  of  bytes  (the  "sync
    bytes").   The time interval between successive bytes in the group
    is zero.  The time interval between successive groups of bytes  is
    unspecified.

Tributary Station - A station on a  channel  that  is  not  a  control
    station.
�











                              APPENDIX B

                       FORMAL SYNTAX DEFINITION



B.1  SYMBOLOGY

In the following  formal  definition  of  the  protocol  grammar,  the
symbols have the following meanings:

     1.  < > denotes a metalinguistic variable.

     2.  := means "is produced by" or "has the value of".

     3.  <a><b> means "a followed by b" or "b concatenated with a".

     4.  <a>!<b> means "a OR b" (exclusive OR).

     5.  quantities not surrounded by brackets < >  are  constants  or
         literal values.

     6.  (<a>*b) means "a repeated b times" (<a><a>---<a>).

     7.  <a>**  means  "a  occurs  from  zero  to  infinity  times  in
         succession".

     8.  null means "the empty set".




B.2  MESSAGE SYNTAX

The following definition of the protocol does not include the specific
sync  sequences and rules when they are used on each link type.  Refer
to the operation section for these specifics.

<protocol>:=<transmission><trailer>!<transmission><protocol>

<transmission>:=<msg>!<syncseq><msg>

               Note  that  the  form  <syncseq><msg>  is  required  in
               numerous cases.  See Operation, subhead 5.1.3.2.

�FORMAL SYNTAX DEFINITION                                      Page B-2


<syncseq>:=<leader><sync>*m

               Where m is  a  parameter  determined  by  hardware  and
               interchange  considerations.   (m >= 1 for asynchronous
               circuits, m >= 4 for synchronous circuits.)

               Note that <syncseq> is used for  inter-message  padding
               as well as for synchronizing.

<sync>:=<syn>                           for    synchronous    circuits
      :=10-bit idle line !  <del>       for    asynchronous   circuits
      :=null                            for parallel circuits

               Where "10-bit idle line" means that the channel is held
               continuously  in  the  state  of the stop element (i.e.
               Mark, condition Z, 1) for a period not less than 10 bit
               times.

<leader>:=(<one>*j)(<sync>*k)           for synchronous circuits

               Where j+8k >=  0  if  qsync  is  set  in  the  previous
               message.  This is a short sync sequence.

               Where j+8k >= 32 if qsync is not set  in  the  previous
               message.  This is a long sync sequence.

               Either j=0 or j>=8

      := idle line !  <del>**           for asynchronous circuits

               Where "idle  line"  means  that  the  channel  is  held
               continuously  in  the  state  of the stop element (i.e.
               Mark, condition Z, 1)

      :=null                            for parallel circuits

<trailer>:=<one>*j                      for   synchronous    circuits,
                                        where j>=8
         :=<leader>                     for   asynchronous    circuits
         :=null                         for parallel circuits

<one>:=1

<msg>:=<nummsg>!<unnummsg>!<maintmsg>

<nummsg>:=<soh><header><bcc><data><bcc>

<unnummsg>:=<enq><body><bcc>

<maintmsg>:=<dle><mhdr><bcc><data><bcc>

<header>:=<count><qsync><select><resp><num><addr>

<data>:=(<byte> * value of <count>)
�FORMAL SYNTAX DEFINITION                                      Page B-3


<bcc>:=<byte><byte>

<body>:=<ackm>!<nakm>!<repm>!<strtm>!<stackm>

<mhdr>:=<count><qsync1><select1><fill><fill><addr>

<count>:=(<bit>*14)

<select>:=<bit>

<select1>:=1

<qsync>:=<bit>

<qsync1>:=1

<resp>:=<byte>

<num>:=<byte>

<addr>:=<byte>

<ackm>:=<ack><fill6><qsync><select><resp><fill><addr>

<nakm>:=<nak><rnak><qsync><select><resp><fill><addr>

<repm>:=<rep><fill6><qsync><select><fill><num><addr>

<strtm>:=<strt><fill6><qsync1><select><fill><fill><addr>

<stackm>:=<stack><fill6><qsync1><select1><fill><fill><addr>

<rnak>:=000001!000010!000011!001000!001001!010000!010001

<byte>:=00000000!00000001!...!11111111

<bit>:=0!1

<syn>:=10010110

<soh>:=10000001

<enq>:=00000101

<del>:=11111111

<fill>:=00000000

<fill6>:=000000

<dle>:=10010000

<ack>:=00000001

<nak>:=00000010
�FORMAL SYNTAX DEFINITION                                      Page B-4


<rep>:=00000011

<strt>:=00000110

<stack>:=00000111

�











                              APPENDIX C

                        MESSAGE FORMAT SUMMARY



C.1  GENERAL MESSAGE FORMATS

Numbered              Unnumbered              Maintenance
Messages              Messages                Messages

<soh>                 <enq>                   <dle>
<count>               <type>                  <count>
                      <subtype>
<qsync>               <qsync>                 <qsync1>
<select>              <select>                <select1>
<resp>                <rcvr>                  <fill>
<num>                 <sndr>                  <fill>
<addr>                <addr>                  <addr>
<bcc1>                <bcc1>                  <bcc1>
<bcc2>                <bcc2>                  <bcc2>
<data>                                        <data>
<bcc3>                                        <bcc3>
<bcc4>                                        <bcc4>



C.2  UNNUMBERED MESSAGE SUMMARY

message        ACK       NAK       REP     STRT      STACK

<enq>         <enq>     <enq>     <enq>    <enq>     <enq>
<type>        <ack>     <nak>     <rep>    <strt>    <stack>
<subtype>     <fill6>   <rnak>    <fill6>  <fill6>   <fill6>
<qsync>       <qsync>   <qsync>   <qsync>  <qsync1>  <qsync1>
<select>      <select>  <select>  <select> <select1> <select1>
<rcvr>        <resp>    <resp>    <fill>   <fill>    <fill>
<sndr>        <fill>    <fill>    <num>    <fill>    <fill>
<addr>        <addr>    <addr>    <addr>   <addr>    <addr>
<bcc1>        <bcc1>    <bcc1>    <bcc1>   <bcc1>    <bcc1>
<bcc2>        <bcc2>    <bcc2>    <bcc2>   <bcc2>    <bcc2>
�











                              APPENDIX D

                    DDCMP BLOCK CHECK COMPUTATION



D.1  DDCMP ERROR DETECTION

Error detection is provided in this protocol by means of  block  check
bytes  after  each  of  the  message headers and message blocks.  This
block check consists of computing a  16-bit  cyclic  redundancy  check
using  a  polynomial  known as the CRC-16 polynomial and appending the
check bits computed to each block.  This polynomial  and  scheme  have
been widely used in BiSync and other protocols.



D.2  THE CRC-16 POLYNOMIAL

The   CRC-16   polynomial   [X^16 + X^15 + X^2 + 1 = (X + 1) * (X^15 +
X + 1)]  [see  section  D3,  step  3  below]  has  the following error
detection properties:

     1.  It will detect all errors that change an odd number  of  bits
         (i.e., 1, 3, 5, ...  bit errors).

     2.  It will detect all errors that change two bits provided  that
         the  block  length  is less than 32767 bits including the CRC
         bits.  Thus the maximum <count> (length of data field) should
         be 4093.

     3.  It will detect all errors that  consist  of  a  single  burst
         error  of 16 or fewer bits.  A burst error is a group of bits
         in which the first bit and the last bit are in error and  the
         intervening  bits  may or may not be in error.  Thus a 16-bit
         burst error might have as many as  16  bits  in  error.   The
         partitioning  of  bits  in  error  into  burst  errors is not
         unique.

     4.  It will detect all errors that consist of two occurrences  of
         two  adjacent bits in error provided that the block length is
         less than 32767 bits including the CRC bits.

     5.  It will detect all except the fraction 1/2^15 of errors  that
         consist of a single burst error of 17 bits.
�DDCMP BLOCK CHECK COMPUTATION                                 Page D-2


     6.  It will detect all except the fraction 1/2^16 of errors  that
         consist of a single burst error of 18 or more bits.

     7.  It will not detect some errors that change  four  bits.   For
         example,  it  will  not  detect  the  error  pattern  that is
         identical to the CRC polynomial.  Thus  the  minimum  Hamming
         distance  between two valid messages (including the CRC bits)
         is four bits.




D.3  CRC COMPUTATION

The algorithm for computing the cyclic redundancy check is as follows:

     1.  Consider the header or data portion  of  the  message  as  it
         appears on a serial line (LSB of the first byte first, MSB of
         the final byte last) and append 16 zeros after the header  or
         data.

     2.  Take the string of bits constructed in 1, and treat each  bit
         as  the coefficient of a term of a polynomial with the LSB of
         the first byte being the coefficient  of  the  highest  order
         polynomial  term.   The  highest order term is A * X^63 for a
         header block and A * X^(8 * <count> + 15) for  a  data  block
         where A is the least significant bit of the first byte of the
         header or data.  The lowest order term is  0 * X^0  for  both
         cases.

     3.  Divide  the  polynomial  constructed  in  2,  by  the  CRC-16
         polynomial X^16 + X^15 + X^2 + 1 using synthetic division and
         using modulo 2 arithmetic on the coefficients (i.e., addition
         =  subtraction  =  XOR.  All carries and borrows are ignored)
         obtaining  a  quotient  that  is  discarded  and   a   16-bit
         remainder.

         Transmit the coefficients of the remainder as the block check
         bytes  following  the original message bits, transmitting the
         coefficients of the highest order term (X^15)  first.   Thus,
         the  first  byte  represents  coefficients of the X^8 through
         X^15 terms of the remainder (from  left  to  right)  and  the
         second  byte  represents  coefficients of the X^0 through X^7
         terms of the remainder (also from left to right).

     4.  On reception, perform the  same  algorithm  and  compare  the
         received  block  check  bytes  with  the computed block check
         bytes.   If  the  bytes  are  not  identical,  an  error  has
         occurred.

     Note:

     1.  On a parallel circuit, the same algorithm  is  used  and  the
         same  block  check  bytes are computed although the bytes are
         sent in parallel instead of serially.  Notice  that  for  the
�DDCMP BLOCK CHECK COMPUTATION                                 Page D-3


         purposes  of the block check byte computation, the LSB of the
         first byte is always treated as the highest order term (i.e.,
         the   term   with   the  largest  exponent)  in  the  message
         polynomial.

     2.  On reception, the message may be handled with the block check
         bytes  included (two bytes longer) and the algorithm computed
         based on this longer message.  If the remainder is  not  zero
         an error has occurred.

�











                              APPENDIX E

                               EXAMPLES



MESSAGE EXCHANGE EXAMPLES - These examples are presented here to  show
the  operation  of the message exchange component of DDCMP in specific
cases of states and occurring events.  They do not  show  actual  link
timings,   as   these  vary  with  link  characteristics  and  station
selection.  The variables used are those presented in subhead 5.3  and
in  the message formats in subhead 4.  The variables of importance are
listed just above the message being sent or  just  below  the  message
received.   Not  all variables, user requests, and timers are shown in
the examples.  They  are  only  shown  when  needed  to  illustrate  a
specific  operational  detail  of DDCMP.  The diagram symbols have the
following meaning:

     symbol            meaning
     ------>           Send message, received with no errors
     ---/-->           Send message, received with errors
     --//-->           Send message, not received
     !                 Reply timer running




E.1  EXAMPLE 1 - START-UP SEQUENCE WITH NO ERRORS

User requests start-up
R=0,N=0,A=0,T=1,X=0
                       ------>          
                       STRT            Notify user of start-up at
                                       other station
                                       User requests start-up
                                       R=0,N=0,A=0,T=1,X=0
                       <------
                       STRT
                       ------->
                       STACK           Enter running state
                       <------
Enter running state    ACK (RESP=0)

�EXAMPLES                                                      Page E-2


E.2  EXAMPLE 2 - START-UP SEQUENCE WITH ERRORS

User requests start-up
                           --//-->
                           STRT
                           !
                           !
Time-out                   !
                           !
                           !
                           ------>
                           STRT
                                            Notify user, user requests
                                            start-up
                           <------
                           STRT  !
                                 !
                                 !
                           --//-->
                           STACK !
                                 !
                                 !          Time-out
                                 !
                           <------
                           STRT
                           ------>
                           STACK            Enter running mode
                           <--//--
                           ACK(RESP=0)
                           !
                           !
                           !
Time-out                   !
                           !
                           !
                           ------>
                           STACK
                           <------
                           ACK(RESP=0)
Enter running state                           
       
�EXAMPLES                                                      Page E-3


E.3  EXAMPLE 3 - DATA TRANSFER WITH NO ERRORS

User requests transmit
R=0,N=1,A=0,T=2,X=1
                           ------>
                           DATA(NUM=1,RESP=0)
                                         Message received and given
                                         to user 
                                         R=1,N=0,A=0,T=1,X=0
                           <------
                           ACK(RESP=1)
User requests transmit
R=0,N=2,A=1,T=3,X=2
                           ------>
                           DATA(NUM=2,RESP=0)
                                         Message received and user
                                         requests transmit
                                         R=2,N=1,A=0,T=2,X=1
                           <------
                           DATA(NUM=1,RESP=2)
Message received and user
requests transmit
R=1,N=3,A=2,T=4,X=3
                           ------>
                           DATA(NUM=3,RESP=1)
                                         Message received
                                         R=3,N=1,A=1,T=2,X=1
User requests transmit
R=1,N=4,A=2,T=5,X=4
                           ------>
                           DATA(NUM=4,RESP=1)
                                         Message received
                                         R=4,N=1,A=1,T=2,X=1
                                         User requests transmit
                                         R=4,N=2,A=1,T=3,X=2
                           <------
                           DATA(NUM=2,RESP=4)
Message received
R=2,N=4,A=4,T=5,X=4
                           ------>
                           ACK(RESP=2)
                                         ACK received
                                         R=4,N=2,A=2,T=3,X=2

�EXAMPLES                                                      Page E-4


E.4  EXAMPLE 4 - DATA TRANSFER WITH CRC ERRORS AND NAKING

User requests transmit
R=0,N=1,A=0,T=2,X=1
                           ----/-->
                           DATA(NUM=1,RESP=0)
                                         Received in error
                                         R=0,N=0,A=0,T=1,X=0
                           <------
                           NAK(RESP=0)
Nak received
R=0,N=1,A=0,T=1,X=1
Retransmit
R=0,N=1,A=0,T=2,X=1
                           ------>
                           DATA(NUM=1,RESP=0)
                                         Message received and
                                         user requests transmit
                                         R=1,N=1,A=0,T=2,X=1
                           <------
                           DATA(NUM=1,RESP=1)
                           ---/-->
                           ACK(RESP=1)
                                         Queue NAK for R=1
User requests 3 transmits
R=1,N=2,A=1,T=3,X=2
                           ------>
                           DATA(NUM=2,RESP=1)
                                         Message received
                                         R=2,N=1,A=1,T=2,X=1
R=1,N=3,A=1,T=4,X=3
                           ------>
                           DATA(NUM=3,RESP=1)
                                         Message received
                                         R=3,N=1,A=1,T=2,X=1

R=1,N=4,A=1,T=5,X=4
                           ------>
                           DATA(NUM=4,RESP=1)
                                         Message received
                                         R=4,N=1,A=1,T=2,X=1
                                         Queue ACK for R=4
                           <------
                           NAK(RESP=1)   Queued NAK returned
NAK received
R=1,N=4,A=1,T=2,X=4
Retransmit
R=1,N=4,A=1,T=3,X=2
                           ------>
                           DATA(NUM=2,RESP=1)
                                         Message ignored
                           <------
                           ACK(RESP=4)   Queued ACK returned
All messages complete
R=1,N=4,A=4,T=5,X=2

�EXAMPLES                                                      Page E-5


E.5  EXAMPLE 5 - DATA TRANSFER WITH ERRORS CAUSING REPLY TIMEOUTS

User requests transmit
R=0,N=1,A=0,T=2,X=1
                           ------>
                           DATA(NUM=1,RESP=0)
                           !
                           !             Message received
                           !             R=1,N=0,A=0,T=1,X=0
                           !
                           <--//--
                           !  ACK(RESP=1)
Time-out                   !
                           !------>
                           REP(NUM=1)
                           <------
                           ACK(RESP=1)   ACK response to REP
                                         R=1,N=0,A=0,T=1,X=0
ACK received
R=0,N=1,A=1,T=2,X=1
User requests transmit
R=0,N=2,A=1,T=3,X=2
                           !--//-->
                           !  DATA(NUM=2,RESP=0)
                           !
                           !
                           !
Time-out                   !
                           !------>
                           REP(NUM=2)
                           <------
                           NAK(RESP=1)   NAK response to REP
                                         R=1,N=0,A=0,T=1,X=0
NAK received
R=0,N=2,A=1,T=2,X=2
Retransmit
R=0,N=2,A=1,T=3,X=2
                           ------>
                           DATA<NUM=2,RESP=0)
                                         Message received
                                         R=2,N=0,A=0,T=1,X=0
                           <------
                           ACK(RESP=2)
ACK received
R=0,N=2,A=2,T=3,X=2
�EXAMPLES                                                      Page E-6


User requests transmit
R=0,N=3,A=2,T=4,X=3
                           !------>
                           ! DATA(NUM=3,RESP=0)
                           !
                           !             Message received
                           !             R=3,N=0,A=0,T=1,X=0
User requests transmit     !
R=0,N=4,A=2,T=5,X=4        !
                           !--//-->
                           ! DATA(NUM=4,RESP=0)
User requests transmit     !
R=0,N=5,A=2,T=6,X=5        !
                           !------>
                           ! DATA(NUM=5,RESP=0)
                           !
                           !             Message ignored 
                           !             R=3,N=0,A=0,T=1,X=0
                           !
                           <--//--       ACK to received message
                           ! ACK(RESP=3)
Time-out                   !
                           !------>
                             REP(NUM=5)
                           <------
                             NAK(RESP=3) NAK response to REP
                                         R=3,N=0,A=0,T=1,X=0
NAK received
R=0,N=5,A=3,T=4,X=5
Retransmit
R=0,N=5,A=3,T=5,X=4
                           ------>
                           DATA(NUM=4,RESP=0)
                                         Message received
                                         R=4,N=0,A=0,T=1,X=0
Retransmit
R=0,N=5,A=3,T=6,X=5
                           ------>
                           DATA(NUM=5,RESP=0)
                                         Message received
                                         R=5,N=0,A=0,T=1,X=0
                           <------
                           ACK(RESP=5)   ACK to received messages
All messages complete
R=0,N=5,A=5,T=6,X=5

�











                              APPENDIX F

                           REVISION HISTORY



This list of DDCMP changes from version 3.0 to the current version 4.1
is  provided  as  a  guide  for  those who have implemented and/or are
familiar with version 3.0 or version 4.0 and  are  interested  in  the
changes  from  that version to the present 4.1 level.  Revision levels
between 3.0 and 4.1 are shown for those who have  such  documentation.
The  composite  list  of  changes  are  all the technical changes from
version  3.0  to  version  4.1.   Only  technical  changes  and  major
clarifications  are listed.  Changes in wording or documentation level
are not included in this revision history.


Version 3.0

There were three printed versions of this level spec, May 1974, August
1974,  and  December  1974.   The  December 1974 document was the most
readable, correct, and widely circulated of the three.  This  document
is  taken  as the base 3.0 level and all changes are from this copy of
version 3.0.

Changes 3.0 to 3.02:

     1.  Changed FINAL flag bit to QSYNC flag bit.   The  SELECT  flag
         bit is now used for both selecting and ending selection.  The
         QSYNC flag signals non-abutting messages allowing short  sync
         sequences between messages on synchronous links.

     2.  Removed the RESET and RESAK messages.  The link is  reset  in
         both  directions  at  the  same time by use of the STRT/STACK
         start-up sequence.

     3.  Clarified the synchronous  and  asynchronous  synchronization
         and  pad sequences.  The sequences were made dependent on the
         link transmission characteristics.

     4.  Removed RESP and NUM fields from the STRT and STACK messages,
         replacing them with FILLs.  After a start-up sequence message
         numbering always starts with message number 1.

     5.  Changed ADDR field to always be tributary address in messages
         both  to  and from tributaries.  This change added a positive
�REVISION HISTORY                                              Page F-2


         identification  to  the  messages  being  returned   from   a
         tributary to the control station.

     6.  Framing requires first byte to be SOH, ENQ, or DLE.   If  not
         one of these then no message is framed and, thus, no NAKs are
         generated as in the previous version.

     7.  Start-up  sequence  revised  to  send  an  acknowledge  to  a
         received  STACK.   The new sequence adds an ACK response to a
         STACK, creating a positive three-way handshake.

     8.  Multipoint operation and sync sequences clarified.   Many  of
         the  operational  details  for  multipoint  were added to the
         specification.


Version 3.02

This version was the result of the above listed changes  made  by  the
DDCMP committee.  This and intermediate review edition 3.01 were dated
July 1975 - August 1975.  The document was also partially rewritten to
add additional clarification to the specification.

Changes 3.02 to 3.03:

     1.  Require full  duplex  tributary  to  wait  until  the  entire
         message  with  the  SELECT  flag  bit  on  is received before
         transmitting.  Previously it had to wait only for the header.
         This change provides for common operation among the different
         modes and link types.

     2.  Require that STRT, STACK, and MAINT messages have the  SELECT
         and  QSYNC  flag  bits  always  set.   These  messages always
         operate one message at a time alternately.  This change makes
         their use common in all modes and link types.

     3.  Multipoint control stations must precede  a  message  with  a
         sync  sequence if addressed to a tributary different from the
         one addressed in the previous message.  This change  improves
         receiver synchronization at the tributaries.

     4.  DATA and MAINT messages with zero length data fields are  not
         allowed.

     5.  The BOOT message  is  changed  in  name  to  the  MAINTENANCE
         message.


Version 3.03

This version resulted from the  changes  listed  above  by  the  DDCMP
committee.   Version  3.03  dated  December  1975  was  never  totally
reviewed by the DDCMP committee.

�REVISION HISTORY                                              Page F-3


Changes 3.03 to 4.0:

     1.  Divided  protocol  functions  into   three   semi-independent
         components:   framing, link management, and message exchange.
         This is not a technical change but  helps  clarify  and  more
         precisely specify the protocol.

     2.  Clarified the user and device  interfaces  to  the  protocol.
         This   is   not   a  technical  change  but  assists  in  the
         understanding of the protocol.

     3.  Allowed the  SELECT  flag  bit  to  be  set  in  full  duplex
         point-to-point  mode  with no checking by the receiver.  This
         change  makes  for  more  compatible  full  and  half  duplex
         implementations.

     4.  Modified the link idle  signal  and  optional  end-of-message
         checking  to  increase  CRC-16  error detection capability in
         cases of synchronous clock loss.

     5.  Allowed an optional increase in the sync sequence  length  to
         recover  from  framing  errors  when  responding  to  a  NAK.
         Especially useful on asynchronous links.

     6.  Made checking of ADDR field optional in  point-to-point  mode
         and checking of FILL fields optional in all modes.

     7.  Described the operation  of  the  reply  timer  in  cases  of
         retransmission.  This is not a technical change but a precise
         description of the timer operation during retransmission.

     8.  Changed error recording counters to be a recommendation not a
         requirement.   Error  recording is now a recommended optional
         part of a DDCMP implementation.

     9.  Clarified messages to be retransmitted when NAKs and ACKs are
         received   asynchronous  to  transmission.   This  is  not  a
         technical  change  but  a  more  precise  definition  of  the
         operation in these cases.

    10.  Removed the option of  multipoint  tributaries  operating  in
         sheltered  mode.   The  only  valid mode is circumspect mode,
         where the tributaries always  track  messages  on  the  link.
         This   mode   is   now  simply  called  multipoint  tributary
         operation.

    11.  Changed the operation of the select timer to be  stopped  and
         restarted   after   every   good  received  message  or  when
         resynchronizing.  This changes the timer to one that times  a
         lost  select  flag  (message with flag in error), rather than
         one that times the duration of a total selection interval.


�REVISION HISTORY                                              Page F-4


Version 4.0

This version is a total rewrite of the DDCMP  protocol  specification.
Three  versions  of  4.0  were used for review in limited circulation,
dated June 1977, October 1977, and December 1977.  It is an attempt to
more clearly and precisely define the DDCMP protocol.  It incorporates
the changes listed above from the previous version.


Version 4.1

This version is an update of version  4.0.   It  includes  many  minor
changes  in  the  document  for  clarification  only.  It includes one
change to the protocol in the maintenance  state,  and  adds  detailed
specifications  on  maintainability  functions:   error  recording and
event logging.  These changes do  not  affect  the  operation  in  the
running state and are only a minor change to the maintenance state.  A
version   4.1   implementation   will   operate   with   version   4.0
implementations.

Changes 4.0 to 4.1:

     1.  Change maintenance mode state table to notify the user when a
         STRT message is received.

     2.  Added a specification  of  standardized  error  counters  and
         event logging.  Added a specification of a network management
         interface to support  error  counters.   Error  counters  and
         event logging are optional.  However, if implemented they are
         required to conform to the specification.

     3.  Added   an   Initialization    and    Management    Interface
         specification  to  support  implementations  which operate in
         more than one mode,  to  enable  tributary  addresses  to  be
         specified, and to set parameters and timer values.