





                                     DECnet

                          DIGITAL Network Architecture

                               Ethernet Data Link
                          Architectural Specification

                                 Version 1.0.0
                                 September 1983



                                              .-------.                     
                                              `======='                     
         .------.        .---.        .-------.  | |  .-------.
         `======'        `==='        `======='  | |  `=======' 
             \\ ..|        |\             \\ \   | |   / /
              \...|      .-----.          .-------------.
            ......|      |      \         \              \
          .-------.      .-------.        o\.--------------. o
          `--/ /--'      `---|\--'      o   `-----\\ \-----'     o
            / /              | \      o            \\ \              o
           / /               |  \   O               \\ \                  O
       ------------.   .----------------.       .-----------------.
                  /|   |                 \       \                 \
                 /     |                  \    \  \                  \      
                /.-----|                   \------.\                   \
               / `-----|                    \-----' \                    \
      --------. /      .---------------------.    \ .----------------------.
        /     |        |                     |     \|         \   \        |
       / /----'        `---------------------'      `--------\ \   \-------'
      / /                                                     \ \   \
     / /                                                       \ \   \
      /                                              .------------------------
     /                                              |\                      

                                                    \  \
                                                     \
                                                      \  \
                                                       \
                                                        \  \
                                                         \
                                                          \  \
                                                           \  .----------------
                                                            \ |          \     
                                                             \|        \  \   
                                                              `---------\  \   


                                                                     Page 2


                                    ________

             This  document  describes  the  structure,  functions,
             interfaces,  and  protocols  of  the DNA Ethernet Data
             Link not defined in the  Ethernet  Specification  that
             make it compatible with DNA.

                         _______ _________ ___________

                          MAYNARD, MASSACHUSETTS 01754



              Copyright (c) 1983 by 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.
     Table of Contents


                                        CONTENTS

             1       INTRODUCTION . . . . . . . . . . . . . . . . . . . . 5

             2       FUNCTIONAL DESCRIPTION . . . . . . . . . . . . . . . 6
             2.1       Design Scope . . . . . . . . . . . . . . . . . . . 6
             2.1.1       Requirements . . . . . . . . . . . . . . . . . . 7
             2.1.2       Goals  . . . . . . . . . . . . . . . . . . . . . 7
             2.1.3       Non-Goals  . . . . . . . . . . . . . . . . . . . 7

             3       MODELS . . . . . . . . . . . . . . . . . . . . . . . 8
             3.1       Relationship to DIGITAL Network Architecture . . . 8
             3.2       DNA Ethernet Data Link Model . . . . . . . . . .  10
             3.2.1       Resource Naming  . . . . . . . . . . . . . . .  11
             3.2.2       Data Link States . . . . . . . . . . . . . . .  11

             4       INTERFACES . . . . . . . . . . . . . . . . . . . .  13
             4.1       User Interface . . . . . . . . . . . . . . . . .  13
             4.1.1       Open . . . . . . . . . . . . . . . . . . . . .  15
             4.1.2       Enable-promiscuous . . . . . . . . . . . . . .  16
             4.1.3       Disable-promiscuous  . . . . . . . . . . . . .  16
             4.1.4       Enable-protocol  . . . . . . . . . . . . . . .  17
             4.1.5       Disable-protocol . . . . . . . . . . . . . . .  18
             4.1.6       Enable-multicast . . . . . . . . . . . . . . .  18
             4.1.7       Disable-multicast  . . . . . . . . . . . . . .  19
             4.1.8       Close  . . . . . . . . . . . . . . . . . . . .  20
             4.1.9       Transmit . . . . . . . . . . . . . . . . . . .  20
             4.1.10      Transmit-poll  . . . . . . . . . . . . . . . .  21
             4.1.11      Receive  . . . . . . . . . . . . . . . . . . .  22
             4.1.12      Receive-poll . . . . . . . . . . . . . . . . .  23
             4.1.13      Receive-abort  . . . . . . . . . . . . . . . .  25
             4.2       Network Management Interface . . . . . . . . . .  25
             4.2.1       Read-channel . . . . . . . . . . . . . . . . .  26
             4.2.2       Read-portal-list . . . . . . . . . . . . . . .  27
             4.2.3       Read-portal  . . . . . . . . . . . . . . . . .  27
             4.2.4       Reset  . . . . . . . . . . . . . . . . . . . .  28
             4.2.5       Set-address  . . . . . . . . . . . . . . . . .  28
             4.2.6       Enable-channel . . . . . . . . . . . . . . . .  29
             4.2.7       Disable-channel  . . . . . . . . . . . . . . .  30
             4.2.8       Read-counters  . . . . . . . . . . . . . . . .  30
             4.2.9       Read-event . . . . . . . . . . . . . . . . . .  31
             4.3       Ethernet Interfaces  . . . . . . . . . . . . . .  32
             4.3.1       Client to Data Link Interface  . . . . . . . .  33
             4.3.2       Network Management to Data Link Interface  . .  34
             4.3.3       Network Management to Physical Link Interface   34

             5       NETWORK MANAGEMENT INFORMATION . . . . . . . . . .  35
             5.1       Counters . . . . . . . . . . . . . . . . . . . .  35
             5.2       Events . . . . . . . . . . . . . . . . . . . . .  39

             6       INTERFACE USAGE EXAMPLES . . . . . . . . . . . . .  43
             6.1       Portal Filter Setup  . . . . . . . . . . . . . .  43
             6.2       Data Error Diagnostic  . . . . . . . . . . . . .  43
     Table of Contents


             7       OPERATION  . . . . . . . . . . . . . . . . . . . .  44
             7.1       Portal Handler . . . . . . . . . . . . . . . . .  46
             7.1.1       Open . . . . . . . . . . . . . . . . . . . . .  46
             7.1.2       Enable-promiscuous . . . . . . . . . . . . . .  47
             7.1.3       Disable-promiscuous  . . . . . . . . . . . . .  47
             7.1.4       Enable-protocol  . . . . . . . . . . . . . . .  48
             7.1.5       Disable-protocol . . . . . . . . . . . . . . .  48
             7.1.6       Enable-multicast . . . . . . . . . . . . . . .  48
             7.1.7       Disable-multicast  . . . . . . . . . . . . . .  49
             7.1.8       Close  . . . . . . . . . . . . . . . . . . . .  49
             7.1.9       Transmit . . . . . . . . . . . . . . . . . . .  49
             7.1.10      Transmit-poll  . . . . . . . . . . . . . . . .  49
             7.1.11      Receive  . . . . . . . . . . . . . . . . . . .  50
             7.1.12      Receive-abort  . . . . . . . . . . . . . . . .  50
             7.1.13      Receive-poll . . . . . . . . . . . . . . . . .  51
             7.2       Transmitter and Receiver . . . . . . . . . . . .  51
             7.2.1       Transmitter  . . . . . . . . . . . . . . . . .  51
             7.2.2       Receiver . . . . . . . . . . . . . . . . . . .  51
             7.2.3       Counters . . . . . . . . . . . . . . . . . . .  52
             7.2.4       Events . . . . . . . . . . . . . . . . . . . .  55


     APPENDIX A      PROTOCOL TYPES AND MULTICAST ADDRESSES

             A.1     CROSS-COMPANY ASSIGNMENTS  . . . . . . . . . . . . A-1
             A.2     DIGITAL ASSIGNMENTS  . . . . . . . . . . . . . . . A-1
     Introduction


        INTRODUCTION

     The Digital, Intel, Xerox intercompany Ethernet specification  is  the
     basis  for  defining  the  DNA (DIGITAL Network Architecture) Ethernet
     Data Link.  The DNA Ethernet Data Link incorporates the functions  and
     operations  defined  in  the  Ethernet  Specification Version 2.0.  To
     these, the DNA Ethernet Data Link adds further features needed by  the
     upper  layers of DNA.  This specification assumes understanding of the
     Ethernet specification.

     This document describes  the  structure,  functions,  interfaces,  and
     protocols  of  the  DNA Ethernet Data Link not defined in the Ethernet
     specification that make it compatible with DNA.  DNA is the  model  on
     which  DECnet implementations are based.  A DECnet network is a family
     of software modules, data bases, and hardware components used  to  tie
     DIGITAL systems together for resource sharing, distributed computation
     or remote system communication.

     DNA is a layered structure.  Modules in each  layer  perform  distinct
     functions.   Modules  within  a  single  DNA  layer  (but typically in
     different computer  systems)  communicate  using  specific  protocols.
     Modules  in  different  layers  (but  typically  in  the same computer
     system) interface using subroutine calls or a system-dependent method.
     In  this  document  interfaces  are  described  in  terms  of calls to
     subroutines.

     This document assumes  that  the  reader  is  familiar  with  computer
     communications and DECnet.  The primary audience consists of those who
     implement DECnet systems.  However, the  document  may  be  useful  to
     anyone  interested  in  the  details  of  DECnet structure.  The other
     current DNA functional specifications are:

         ___ ____ ______ ________ _____ __________  _____________
             5.6.0, Order No. AA-K177A-TK

         ___  _______  ____   ______________   _______   ________   _______
             __________ _____________

         ___ ________  ____  _______  ____________  _____________
             1.0.0, Order No. AA-X440A-TK

         ___  ___________  __________  __________  _____________
             3.0.0, Order No. AA-X436A-TK

         ___ _______ __________ __________  _____________
             Order No. AA-X437A-TK

         ___ _______ ________ ________  __________  _____________
             4.0.0, Order No. AA-X439A-TK

         ___ _______ _____ __________ _____________
             No. AA-X435A-TK

         ___ _______ _______ __________ _____________
             No. AA-K182A-TK
     Introduction


         ___ _________ _ _____ ____ ________ ____ ____ _____  ___  ________
             _____   ______________
             Xerox), Order No. AA-K759B-TK

         ______ _______ _______ ____________ ______ ___ _______ ___________
     (Order   No.   AA-N149A-TC)   provides  an  overview  of  the  network
     architecture and  an  introduction  to  each  of  the  DNA  functional
     specifications.



        FUNCTIONAL DESCRIPTION

     The Ethernet functions are a subset  of  those  included  by  the  DNA
     Ethernet  Data  Link.   The  DNA Ethernet Data Link has two classes of
     functions:

             User
             Link  provides  for  higher  layers.   In  the context of this
             specification, the user is the next layer up  in  the  network
             architecture, rather than the end user at the top layer.

             Network Management
             needed to maintain the Data Link.


     The DNA Ethernet Data Link gives its users a communication service for
     transmitting  and  receiving  frames, but does not guarantee delivery.
     The data link filters incoming frames by system address  and  protocol
     type based on filter values established by the user.

     A specific system (physical address),  a  function-oriented  group  of
     systems (multicast address), or all systems (broadcast address) can be
     addressed using the  data  link.   Each  frame  has  a  protocol  type
     assigned  to it that is used by the data link to identify the protocol
     handling module that is to receive it.

     The use of protocol types  allows  concurrent  operation  of  multiple
     protocols  in  the layer above the data link.  For example, in DNA the
     Routing layer and the DNA Ethernet Data Link Loop Testing Service  can
     both  use  the DNA Ethernet Data Link at the same time.  Neither needs
     to be aware of the other.  This is in contrast to the DDCMP Data  Link
     where  maintenance  traffic  and normal traffic use mutually exclusive
     modes of protocol operation.

     The DNA Ethernet Data Link provides control and  observation  services
     needed to maintain the data link.  These are functions that enable and
     disable physical channels and monitor the status of specific channels.



          Design Scope

     The DNA Ethernet Data Link  requires  certain  characteristics  to  be
     present,  attempts to meet certain goals, and lacks some features that
     Functional Description


     are not within the scope of the design.



            Requirements

     The  DNA  Ethernet  Data  Link  design   must   have   the   following
     characteristics:

          .  All capabilities included in the  Ethernet  Specification  are
             available from the DNA Ethernet Data Link.

          .  The network manager can control and observe the data  link  as
             it functions.

          .  It complies with the Ethernet Specification.




            Goals

     The DNA Ethernet Data Link  design  attempts  to  have  the  following
     characteristics:

          .  Uses both processor and memory efficiently.

          .  Common functions needed by higher layers are included  in  the
             data link.

          .  Inputs and outputs are simple, predictable, and consistent.




            Non-Goals

     DNA Ethernet Data Link design does not attempt to have  the  following
     characteristics:

          .  Addition  of  functions   not   included   in   the   Ethernet
             specification   that  higher  layers  may  want  to  implement
             differently (such as reliable delivery).

          .  Self-diagnosis of all data link problems.  Diagnosis  of  some
             problems requires information from higher layers.

     Models


        MODELS

     This section describes the relationship of the DNA Ethernet Data  Link
     to  other  network  layers  and  modules.  Although this specification
     primarily relates  the  DNA  Ethernet  Data  Link  to  DNA,  the  same
     relationships can also be applied within other network architectures.



          Relationship to DIGITAL Network Architecture

     Figure 1 shows the relationship of the DNA Ethernet Data Link  to  the
     DNA hierarchy.


                .----------------------------.
                |    User Modules            |
                `----------------------------'
                   |         |         |
                   |         |         V
                .- | ------- | ------------------------------------.
         .------|  | Network |  Management  Modules                |
         |      `- | ------- | ------------------------------------'
         |         |         |         |              |          |
         |         |         V         V              |          |
         |      .- | -------------------------------- | ------.  |
         |----> |  | Network Application Modules      |       |  |
         |      `- | -------------------------------- | ------'  |
         |         |                   |              |   |      |
         |         V                   V              V   |      |
         |      .---------------------------------------. |      |
         |----> |    Session Control Modules            | |      |
         |      `---------------------------------------' |      |
         |                             |                  |      |
         |                             V                  |      |
         |              .---------------------------.     |      |
         |------------> | End Communication Modules |     |      |
         |              `---------------------------'     |      |
         |                             |                  |      |
         |                             V                  |      |
         |              .---------------------------.     |      |
         |------------> | Routing Modules           |     |      |
         |              `---------------------------'     |      |
         |                             |                  |      |
         |                             V                  V      V
         |              .-------------------------------------------.
         |------------> | Data Link Modules                         |
         |              `-------------------------------------------'
         |                             |
         |                             V
         |              .--------------------------.
         `------------> | Physical Link Modules    |
                        `--------------------------'
                                       |
                                       `--------------------------------
     Models


     The DNA Ethernet Data Link resides within the DNA Data Link layer.  It
     can  be  co-resident with other DNA Data Link modules such as DDCMP or
     X.25.

     In figure 1, horizontal arrows show  direct  access  for  control  and
     observation  of  parameters,  counters,  etc.   Vertical  arrows  show
     interfaces between layers for normal  user  operations  such  as  file
     access, down-line load, and logical link usage.

     Each layer in  DNA  consists  of  functional  modules  and  protocols.
     Generally,  modules use the services of the next lower layer.  In this
     document the service relationship  is  demonstrated  in  the  way  the
     interfaces  are  modeled,  as  calls  to  subroutines.   Note that the
     Network Management layer interfaces directly with each  of  the  lower
     layers.   Also,  the  layers  above Session Control interface directly
     with it.  For  this  reason  the  upper  three  layers  are  sometimes
     referred to as the "end user."

     Modules of the same type in the same layer communicate with each other
     to provide their services.  The rules governing this communication and
     the messages required  constitute  the  protocol  for  those  modules.
     Messages   are  typically  exchanged  between  equivalent  modules  in
     different nodes.  However, equivalent modules within a single node can
     also exchange messages.

     A brief description of each layer follows in order from the highest to
     the lowest layer:


             User layer.
             services  and  programs.  Programs such as the Network Control
             Program, which interfaces with the Network  Management  layer,
             and  file  transfer programs, which interface with the Network
             Application layer, reside in the user layer.

             Network Management layer.
             only  one  that  has  direct  access  to  each lower layer for
             control purposes.  Modules in this layer provide user  control
             over  and  access  to  network parameters and counters.  These
             modules also perform up-line dumping, down-line  loading,  and
             testing functions.

             Network Application layer.
             layer  support  network  functions, such as remote file access
             and file transfer, used by the  User  and  Network  Management
             layers.

             Session  Control  layer.
             system-dependent  aspects of logical link communication, which
             allows messages to be sent from  one  node  to  another  in  a
             network.   Session  Control  functions include name to address
             translation, process addressing, and, in some systems, process
             activation and access control.
     Models


             End Communication layer.
             the system-independent aspects of logical link communication.

             Routing layer.
             called packets, between source and destination nodes.

             Data Link layer.
             concerning data integrity and physical channel management.

             Physical Link layer.
             part  of the device driver for each communications device plus
             the communications hardware  itself.   The  hardware  includes
             interface devices, modems, and the communication lines.




          DNA Ethernet Data Link Model

     The  DNA  Ethernet  Data  Link  provides  communication  services  for
     multiple   concurrent  users.   It  also  supports  multiple  Ethernet
     channels.  A channel is defined as a single hardware connection to  an
     Ethernet  cable.   Each  channel implements the cross-company Ethernet
     standard.

     The following diagram shows the relationship of these users to the DNA
     Ethernet  Data Link and its relationship to the standard Ethernet Data
     Link.  In Ethernet terminology, the DNA  Ethernet  Data  Link  is  the
     lowest level module in the Client Layer.

           .---------.     .---------.       .---------.
           | User #1 |     | User #2 | . . . | User #n |          DNA
           `---------'     `---------'       `---------'          Ethernet
                \               |                 /               Users
                 \              |                /
     . . . . . . .\. . . . . . .|. . . . . . . ./. . . . . . . . . . . . .
                   \            |              /
            .----------------------------------------.
            |    DNA Ethernet Data Link Interfaces   |
            `----------------------------------------'
                    /           |             \
              Channel 1    Channel 2  ...  Channel m              DNA
                  /             |               \                 Ethernet
           .---------.     .---------.       .---------.          Data
           |    E T H E R N E T   D a t a   L i n k    |          Link
           `---------'     `---------'       `---------'
                |               |                |
          .----------.     .---------.      .-----------.
          |  E T H E R N E T  P h y s i c a l  L i n k  |
          `----------'     `---------'      `-----------'
     Models


            Resource Naming

     The user of the DNA Ethernet Data Link is concerned with two different
     levels  of  identification.   Users  identify  either  a  channel or a
     portal.


               channel
             channel has one name and each name identifies one channel.

               portal
             the  data  link  to service that user's requests.  A portal is
             assigned by the data link in  response  to  a  user's  initial
             call.   The  user  then uses that portal in subsequent related
             calls.  Many users can simultaneously have  their  own  portal
             associated by the data link with the same channel.

             A portal data base contains the lists of  protocol  types  and
             multicast  addresses  that the user has enabled for receipt of
             incoming frames.   The  user  will  receive  frames  only  for
             enabled  protocol  types  and  multicast  addresses.   It also
             contains the lists of outstanding transmits and  receives  for
             the user.




            Data Link States

     In observing the operation of the data link, the  user  can  see  four
     channel  states.   Some  of  these  states  are reached due to network
     management commands, others due to data link  operation.   The  states
     are:


             Off

             Init
             data   link.    This   test  is  an  implementation  dependent
             self-test.

             On

             Broken
             failed  the initialization test, or the channel was on but the
             data link determined that  the  channel  would  now  fail  the
             initialization test.


     Changes between these states do not affect counters or parameters such
     as the node's physical address.
     Models


     The following diagram shows the data  link  state  transitions  for  a
     channel:

            .---------------------.
            |         ++++        |
            V         V  +        |
         .-----.    .------.    .----.       Key:
      .--|     |<---|      |    |    |+++
      |  | off |    | init |***>| on |  +      ---  Management Disable
      `->|     |+++>|      |    |    |<++
         `-----'    `------'    `----'         +++  Management Enable
            A         A  *        *
            |         +  *        *            ***  Data Link Operation
            |         +  V        *
            |      .--------.     *
            `------| broken |<*****
                   `--------'

     Network management can enable the channel.  From the "off" or "broken"
     states,  this  enable  causes  a  transition to "init".  From the "on"
     state, enable has no effect.

     In the "init" state, the data link performs initialization and test of
     the  channel.   If  this  succeeds, the data link changes the state to
     "on".  If initialization and test fail,  the  data  link  changes  the
     state to "broken".

     From  the  "broken"  state,  network   management   can   either   try
     initialization  again  with  an  enable  command or go to "off" with a
     disable command.

     The data link can change the state from "on" to "broken" at  any  time
     if it determines that the channel would fail initialization and test.

     The channel can be forced  to  "off"  from  any  state  by  a  network
     management disable command.
     Interfaces


        INTERFACES

     The  following  sections  describe  the  interfaces  provided  by  DNA
     Ethernet Data Link.  They are the following:

          User Interface
          data between data links.

          Network  Management  Interface
          observation functions for the local data link.

     The function descriptions are in terms of subroutines with  input  and
     output arguments.  These subroutines are to be understood as abstract,
     functional descriptions.  Actual implementations may vary, for example
     in  synchronization  techniques,  as  long  as  they  provide the same
     functions.  Furthermore, these are  models  for  privileged,  internal
     system  interfaces.  They are not necessarily to be used as high level
     user interfaces.

     The interfaces use the two levels of  identification  defined  in  the
     Model  section.   Callers  identify  the  object of a call in terms of
     either channel-id or portal-id.

     In many of the interface functions, the caller can specify an Ethernet
     address.   In some cases this address can be either a physical address
     or a multicast address.  In other cases it is restricted to one or the
     other.   In  implementations that allow expression of one of the forms
     of address in a case where it  is  invalid,  the  implementation  must
     reject the function request with an appropriate error return code.

     The interface descriptions assume that buffers are passed in the  form
     of  a  descriptor that contains buffer address, maximum buffer length,
     and, if applicable, length of information in buffer.

     This section also contains  an  overview  of  the  required  interface
     functions from the intercompany Ethernet specification.



          User Interface

     This section describes the User Interface to  the  DNA  Ethernet  Data
     Link.   The  User  Interface  maintains  portals  for transmission and
     reception of frames through the data link on behalf of the user.   The
     user  can  enable  or  disable  broadcast  and multicast addresses and
     appropriate protocol types on specific portals for flexible  filtering
     of incoming frames.  The User Interface provides functions for queuing
     frames and monitoring the status of those queued requests.
     Interfaces


     The interface contains the following functions:

       .  Open -- open a portal.

       .  Enable-promiscuous -- enable all  protocol  types  and  multicast
          addresses for a portal.

       .  Disable-promiscuous -- disable  the  blanket  protocol  type  and
          multicast address enable for a portal.

       .  Enable-protocol -- enable a protocol type for a portal.

       .  Disable-protocol -- disable a protocol type for a portal.

       .  Enable-multicast -- enable a multicast address for a portal.

       .  Disable-multicast -- disable a multicast address for a portal.

       .  Close -- close a portal.

       .  Transmit -- send a frame.

       .  Transmit-poll -- checks for completion of a Transmit.

       .  Receive -- receive a frame.

       .  Receive-abort -- Aborts a Receive.

       .  Receive-poll -- checks for completion of a Receive.

     Some features in the interface descriptions  are  optional.   Features
     can  be  optional  for caller or implementor or both.  Caller-optional
     features can be invoked at the  user's  option.   Implementor-optional
     features  may  or  may  not  be included in particular implementations
     based on product requirements.

     A portal will receive only  those  frames  that  match  the  filtering
     criteria  set  up  with  the  enable  and  disable  functions.   These
     functions can be invoked multiple times for the same portal,  allowing
     a   single  portal  to  receive  many  protocol  types  and  multicast
     addresses.  Alternatively, a portal can  enable  promiscuous  receipt.
     This  is  exclusive  of individual enables or disables, and allows the
     portal to receive all protocol types and multicast addresses.

     Enabling of a protocol type automatically implies  receipt  of  frames
     addressed  to  the  channel's  physical  address.   A  portal receives
     multicast frames only for those multicast  addresses  it  specifically
     enables.   In  this  context,  broadcast  is treated the same as other
     multicast addresses.  Multicast addresses enabled or disabled  on  one
     portal have no effect on other portals.

     Conceptually, receive filtering is done first by protocol  type,  then
     by  multicast  address.   A  frame  that  does  not  pass filtering is
     discarded.  In actual practice, an implementation may first filter  in
     hardware the union of the multicast addresses for all portals and then
     Interfaces


     do the filtering again on a reduced number of frames.



            Open

     The open function opens a portal so that the  user  can  transmit  and
     receive frames.


     OPEN(Channel-id,Pad,Return-code,Portal-id)

     Inputs:

         Channel-id
                    which the portal is to be opened.

         Pad
                    frames  that  are  under  minimum  length.   Padding is
                    accomplished via data link generated additions to  user
                    data.   It is the responsibility of the user's protocol
                    conventions to define  that  its  protocol  modules  in
                    other  systems  will  either request the same option or
                    will understand the padding conventions.  The data link
                    will  apply padding conventions to both transmitted and
                    received messages for the portal.

     Outputs:

         Return-code

                        Success - a portal was opened.

                        No resources - the DNA Ethernet Data Link does  not
                        have sufficient resources to open a portal.

                        Unrecognized channel - there is no channel with the
                        specified identification.

                        Channel not on - a portal cannot be opened  because
                        the channel state is not "on".

                        Promiscuous receiver active - a  portal  cannot  be
                        opened   because  some  other  portal  has  enabled
                        promiscuous receive.   This  error  return  applies
                        only  in  implementations  that  limit  promiscuous
                        receive   to   a    single    portal    (see    the
                        Enable-promiscuous function).

         Portal-id
                    interface functions.
     Interfaces


            Enable-promiscuous

     The Enable-promiscuous  function  indicates  that  the  portal  is  to
     receive  all  frames regardless of protocol type or multicast address.
     If a portal has this enable function in effect, it  cannot  explicitly
     enable individual protocol types or multicast addresses.

     Three possible implementations of this function are allowed:

          Not implemented.

          Exclusive use only.
          open  or  if  this  portal  has  any  protocol types or multicast
          addresses enabled.

          Non-exclusive use.
          that  would  have been delivered to another portal are duplicated
          and delivered to this one also.  This is in addition to all other
          frames.


     ENABLE-PROMISCUOUS(Portal-id,Return-code)

     Inputs:

         Portal-id

     Outputs:

         Return-code

                        Success - promiscuous receive enabled.

                        Not  implemented  -  the  implementation  does  not
                        support the requested function.

                        Non-exclusive  -  the  implementation  allows  only
                        exclusive  promiscuous  receipt  and this portal or
                        some other portal has a protocol type or  multicast
                        address enabled.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.

                        Channel not on - the function  failed  because  the
                        channel state is not "on".



            Disable-promiscuous

     The Disable-promiscuous function  indicates  that  the  portal  is  no
     longer  to  receive  frames  for  all  protocol  types  and  multicast
     addresses.
     Interfaces


     DISABLE-PROMISCUOUS(Portal-id,Protocol-type,Return-code)

     Inputs:

         Portal-id

         Protocol-type
                    portal.

     Outputs:

         Return-code

                        Success - promiscuous receive is  not  enabled  for
                        the portal.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.



            Enable-protocol

     The Enable-protocol function adds a protocol type to the list of those
     that the portal wishes to receive.  The function fails if the protocol
     type is enabled by some other portal.


     ENABLE-PROTOCOL(Portal-id,Protocol-type,Return-code)

     Inputs:

         Portal-id

         Protocol-type
                    portal.

     Outputs:

         Return-code

                        Success - the protocol type is enabled.

                        Protocol type in use - this  portal  cannot  enable
                        the protocol type because some other portal already
                        has it enabled.

                        No resources - the DNA Ethernet Data Link does  not
                        have   sufficient   resources   to  enable  another
                        protocol type.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.
     Interfaces


                        Promiscuous receive active -  the  function  failed
                        because   this   portal   has  enabled  promiscuous
                        receive.   This  error  return  applies   only   in
                        implementations that limit promiscuous receive to a
                        single   portal   (see    the    Enable-promiscuous
                        function).

                        Channel not on - the function  failed  because  the
                        channel state is not "on".



            Disable-protocol

     The Disable-protocol function indicates that the portal is  no  longer
     to receive frames for a protocol type.


     DISABLE-PROTOCOL(Portal-id,Protocol-type,Return-code)

     Inputs:

         Portal-id

         Protocol-type
                    for this portal.

     Outputs:

         Return-code

                        Success - the protocol type is not enabled for  the
                        portal.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.



            Enable-multicast

     The Enable-multicast function adds a multicast address to the list  of
     those that the portal wishes to receive.


     ENABLE-MULTICAST(Portal-id,Multicast-address,Return-code)

     Inputs:

         Portal-id

         Multicast-address
                    for this portal.
     Interfaces


     Outputs:

         Return-code

                        Success - the multicast address is enabled.

                        No resources - the DNA Ethernet Data Link does  not
                        have   sufficient   resources   to  enable  another
                        multicast address for this portal.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.

                        Promiscuous receive active -  the  function  failed
                        because   this   portal   has  enabled  promiscuous
                        receive.   This  error  return  applies   only   in
                        implementations that limit promiscuous receive to a
                        single   portal   (see    the    Enable-promiscuous
                        function).

                        Channel not on - the function  failed  because  the
                        channel state is not "on".



            Disable-multicast

     The Disable-multicast indicates  that  the  portal  is  no  longer  to
     receive frames for a multicast address.


     DISABLE-MULTICAST(Portal-id,Multicast-address,Return-code)

     Inputs:

         Portal-id

         Multicast-address
                    recognized for this portal.

     Outputs:

         Return-code

                        Success - the multicast address is not enabled  for
                        the portal.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.
     Interfaces


            Close

     The Close  function  closes  an  open  portal  and  releases  all  its
     resources.   A portal cannot be closed unless all outstanding transmit
     or receive requests are completed.


     CLOSE(Portal-id,Return-code)

     Inputs:

         Portal-id

     Outputs:

         Return-code

                        Success - the portal is closed.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.

                        Calls outstanding - there are uncompleted  transmit
                        or receive requests outstanding on the portal.



            Transmit

     The Transmit function queues a frame  to  be  transmitted.   The  user
     tests  for completion by using Transmit-poll.  Transmission of a frame
     always succeeds or fails within such a small amount of  time  that  an
     abort function is not necessary.

     The user can have multiple outstanding  Transmits,  up  to  the  limit
     allowed by the implementation.

                                      NOTE

             Ethernet does  not  guarantee  attempted  delivery  of
             fewer  than  46  bytes or more than 1500 bytes of user
             data.   The  DNA  Ethernet  Data  Link   may   attempt
             transmission, but the result is unspecified.


     TRANSMIT(Portal-id,Destination-address,Protocol-type,Input-buffer,
              CRC-32,Return-code)

     Inputs:

         Portal-id

         Destination-address
                    can  be  either  a  physical  address  or  a  multicast
                    address.  As a matter of good citizenship, users should
     Interfaces


                    not  transmit  to  the  broadcast  address  unless  the
                    message is intended  for  all  systems,  regardless  of
                    their function or manufacturer.

         Protocol-type

         Input-buffer
                    data  is shorter than the minimum Ethernet message size
                    and padding is not enabled, or the data is longer  than
                    the  maximum  Ethernet message size, then the frame may
                    not arrive at the destination.  If padding  is  enabled
                    there  is  no minimum size, and the maximum size is the
                    Ethernet limit minus two bytes.  Until the  request  is
                    completed  (as sensed via Transmit-poll), the user must
                    not disturb the contents of the buffer.

         CRC-32
                    redundancy  code  that  is  to  be used for this frame.
                    This overrides the one normally supplied  by  the  data
                    link.

     Outputs:

         Return-code

                        Request accepted -  DNA  Ethernet  Data  Link  will
                        attempt  to  transmit  the  frame.  Notification of
                        completion is via the Transmit-poll function.

                        CRC control not available - the user  attempted  to
                        supply  a  CRC and the implemention either does not
                        support or allow the function.

                        No resources - the DNA Ethernet Data Link does  not
                        have sufficient resources to queue another transmit
                        for this portal.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.

                        Channel not on - the function  failed  because  the
                        channel state is not "on".



             Transmit-poll

     The Transmit-poll function checks for the  completion  of  a  transmit
     request.   The  data  link  transmits frames in the order in which the
     user submits them.

     Successful completion of this function implies  only  that  the  local
     transmitter  believes  that  it sent the frame.  It has no implication
     relative to reception by the destination.
     Interfaces


     TRANSMIT-POLL(Portal-id,Return-code,Input-buffer,Error-detail,
                   Fault-distance)

     Inputs:

         Portal-id

     Outputs:

         Return-code

                        Not complete - no  outstanding  transmit  for  this
                        portal is done.

                        None  outstanding  -  there  are   no   outstanding
                        transmits for this portal.

                        Transmit successful - a frame successfully left the
                        local transmitter.

                        Transmit failed - the local transmitter  could  not
                        transmit the frame.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.

                        Channel left  "on"  state  -  the  function  failed
                        because the channel is no longer in the "on" state.

         Input-buffer
                    function.

         Error-detail
                    "transmit   failed".   Detailed  explanation  of  these
                    reasons is in the section on events.  One of:

                        Excessive collisions
                        Carrier check failed
                        Short circuit
                        Open circuit
                        Frame too long
                        Remote failure to defer

         Fault-distance
                    short  or  open  circuit.  This is meaningful only when
                    error-detail is "short circuit" or "open circuit".



             Receive

     The Receive function queues a buffer to receive a frame.


     RECEIVE(Portal-id,Receive-bad,Output-buffer,Return-code,Frames-lost)
     Interfaces


     Inputs:

         Portal-id

         Receive-bad
                    that frames are to be returned even though they contain
                    invalid data.  This includes frames with CRC or framing
                    errors.

         Output-buffer
                    frame.

     Outputs:

         Return-code

                        Request accepted - If a message is received for the
                        specified  portal,  the DNA Ethernet Data Link will
                        put it into the buffer.  Notification of completion
                        is via the Receive-poll function.

                        Receive-bad not implemented -  the  call  requested
                        receipt  of  bad frames but the implementation does
                        not support the function.

                        No resources - the DNA Ethernet Data Link does  not
                        have  sufficient resources to queue another receive
                        for this portal.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.

                        Channel not on - the function  failed  because  the
                        channel state is not "on".

         Frames-lost
                    for  this  portal that were discarded because no buffer
                    was available.  Note that this count can  be  incorrect
                    if  frames  were lost at a low enough level that portal
                    filtering could not be  done.   This  argument  is  not
                    required  in  implementations  where  the  buffering is
                    always available.



             Receive-poll

     The Receive-poll function checks  for  the  completion  of  a  receive
     request.  The data link gives received frames to the user in the order
     in which they arrived.


     RECEIVE-POLL(Portal-id,Return-code,Error-detail,Destination-address,
                  Source-address,Protocol-type,Output-buffer,
                  Bytes-lost,CRC-32)
     Interfaces


     Inputs:

         Portal-id

     Outputs:

         Return-code

                        Not complete -  no  outstanding  receive  for  this
                        portal is done.

                        None  outstanding  -  there  are   no   outstanding
                        receives for this portal.

                        Receive  successful  -  a  frame  was  successfully
                        received into the buffer.

                        Receive with overrun -  a  frame  was  successfully
                        received,  but  had to be truncated to fit into the
                        buffer.

                        Length  error  -  the  received  frame  length  was
                        inconsistent   with  the  length  recorded  by  the
                        padding conventions.  The buffer contains the  data
                        received,  including  the  padding  information and
                        truncated if it was too long  to  all  fit  in  the
                        buffer.

                        Invalid data - a frame was received with bad  data.
                        This  return-code  value  is  only  seen  if on the
                        Receive function the caller requested  delivery  of
                        bad frames.

                        Receive aborted - the user  cancelled  the  receive
                        request with the Receive-abort function.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.

                        Channel left .bb "on" state - the  function  failed
                        because the channel is no longer in the "on" state.

         Error-detail
                    "invalid  data".  Detailed explanation of these reasons
                    is in the section on events.  One of:

                        Block check error
                        Framing error
                        Frame too long

         Destination-address
                    addressed.

         Source-address
                    received frame.
     Interfaces


         Protocol-type

         Output-buffer

         Bytes-lost
                    "receive with overrun".  This argument is optional both
                    for user and implementor.  If it is applicable but  not
                    implemented, it returns a value of "not implemented".

         CRC-32
                    came into the data link with the frame.



             Receive-abort

     The Receive-abort function aborts all incomplete receive requests  for
     the  portal.   The buffers are returned via the Receive-poll function.
     They may be returned as aborted or as normally completed.


     RECEIVE-ABORT(Portal-id,Return-code)

     Inputs:

         Portal-id

     Outputs:

         Return-code

                        Success - the request is now complete.

                        Unrecognized portal - there is no open portal  with
                        the specified identification.

                        None  outstanding  -  there  are   no   outstanding
                        receives for this portal.



          Network Management Interface

     This section describes the  interface  used  to  control  and  observe
     operation  of  the  DNA  Ethernet  Data  Link.  The Network Management
     Interface enables and disables channels and monitors  the  events  and
     counters that provide information on network operation.

     The Network Management Interface contains the following functions:

       .  Read-channel -- read channel status.

       .  Read-portal-list -- read list of open portals.
     Interfaces


       .  Read-portal -- read information for a portal.

       .  Reset -- reset the channel to initial state.

       .  Set-address -- set channel physical address.

       .  Enable-channel -- enable channel operation.

       .  Disable-channel -- disable channel operation.

       .  Read-counters -- read channel or portal counters.

       .  Read-event -- read channel event.



            Read-channel

     The Read-channel function  reads  status  information  relative  to  a
     specified channel.


     READ-CHANNEL(Channel-id,Return-code,Physical-address,
                  Hardware-address,State,Broken-code)

     Inputs:

         Channel-id
                    status is to be read.

     Outputs:

         Return-code

                        Success - status successfully read.

                        Unrecognized channel - there is no channel with the
                        specified identification.

         Physical-address
                    set".    This  is  the  address  that  the  channel  is
                    currently using.

         Hardware-address
                    available".   This  is  the address associated with the
                    channel hardware.

         State

                        On
                        Off
                        Init
                        Broken

         Broken-code
     Interfaces


                    reason the state is "broken".



            Read-portal-list

     The  Read-portal-list  function  reads  the  list   of   open   portal
     identifications.


     READ-PORTAL-LIST(Channel-id,Buffer,Return-code)

     Inputs:

         Channel-id
                    open portal list is to be read.

         Buffer

     Outputs:

         Return-code

                        Success - list successfully read.

                        Buffer too small - the buffer could  not  hold  the
                        entire list.  Portal identifications that would not
                        fit in the buffer are not returned.

                        Unrecognized channel - there is no channel with the
                        specified identification.

         Buffer
                    identifications.



            Read-portal

     The Read-portal function reads portal  data  base  information  for  a
     portal.


     READ-PORTAL(Portal-id,Buffer,Return-code)

     Inputs:

         Portal-id
                    the data base is to be read.

         Buffer
                    information.
     Interfaces


     Outputs:

         Return-code

                        Success - portal data base successfully read.

                        Buffer too small - the buffer could  not  hold  all
                        the information.  Information that would not fit in
                        the buffer is not returned.

                        Unrecognized channel - there is no channel with the
                        specified identification.

         Buffer
                    information.    Each   parameter   entry  contains  the
                    following information:

                        Parameter-type  -   the   identification   of   the
                        particular   portal   data   base  parameter.   The
                        parameters are  listed  in  the  Portal  Data  Base
                        operation section.

                        Value - the parameter value.



            Reset

     The Reset function returns the specified  channel  to  initial  state.
     The  physical address is unset.  The counters are zeroed.  All portals
     are closed.  The channel state is "off".


     RESET(Channel-id,Return-code)

     Inputs:

         Channel-id
                    be reset.

     Outputs:

         Return-code

                        Success - channel reset.

                        Unrecognized channel - there is no channel with the
                        specified identification.



            Set-address

     The Set-address function sets the physical address  of  the  specified
     channel.   This  is  the address recognized as specific destination in
     Interfaces


     received frames and sent as source address in transmitted frames.

     This function is necessary for a system that wants  to  use  the  same
     physical  address  on  multiple  different  cables  or  has a physical
     address that is obtained completely independently of the data link.


     SET-ADDRESS(Channel-id,Address,Return-code)

     Inputs:

         Channel-id
                    the  address  is  to  be  set.  This must be a physical
                    address.  Furthermore, it  must  be  unique  among  all
                    channels attached to the same cable.

         Address

     Outputs:

         Return-code

                        Success - the address was successfully set.

                        Unrecognized channel - there is no channel with the
                        specified identification.

                        Channel not off - the function failed  because  the
                        channel state is not "off".



            Enable-channel

     The Enable-channel function attempts to put the channel into  a  state
     where it can be used.

     Enabling  the  channel  does  not  disturb  the  contents  of  counter
     variables.


     ENABLE-CHANNEL(Channel-id,Return-code)

     Inputs:

         Channel-id
                    enabled.

     Outputs:

         Return-code

                        Success - Channel is enabled.  A  channel  that  is
                        enabled  is  not  necessarily usable.  The user can
                        determine the actual state of the channel with  the
     Interfaces


                        Read-channel function.

                        Address not set -  the  physical  address  for  the
                        channel has not been set.

                        Unrecognized channel - there is no channel with the
                        specified identification.



            Disable-channel

     The Disable-channel function puts the channel into the "off" state  so
     that  it  cannot  be  used.   The  purpose of this function is to halt
     operation.  The channel can still be observed.  In particular counters
     and  other  data base information not directly related to state change
     operation is not disturbed.

     All outstanding transmit and receive operations for  the  channel  are
     completed  with  a  return  code  of  "channel  left  on state" on the
     Receive-poll or Transmit-poll.


     DISABLE-CHANNEL(Channel-id,Return-code)

     Inputs:

         Channel-id
                    disabled.

     Outputs:

         Return-code

                        Success - channel is disabled.

                        Unrecognized channel - there is no channel with the
                        specified identification.



            Read-counters

     The Read-counters function reads  and  optionally  sets  all  counters
     associated with the specified channel or portal to zero.


     READ-COUNTERS(Entity-id,Operation,Buffer,Return-code)

     Inputs:

         Entity-id
                    portal for which counters are to be read.

         Operation
     Interfaces


                    operations:

                        Read - only read the counters.

                        Read-and-zero - read the counters and set  them  to
                        zero.

         Buffer

     Outputs:

         Return-code

                        Success  -  counters  read  (and  set  to  zero  if
                        requested).

                        Unrecognized entity - there is no channel or portal
                        with the specified identification.

                        Buffer too small - the buffer was too small to hold
                        all  the  counter  information.  The information is
                        truncated.  Information that would not fit is lost.
                        If  read-and-zero  was  requested, all the counters
                        are set to zero  even  if  their  values  were  not
                        returned.

         Buffer
                    entry contains the following information:

                        Counter-type - the identification of the particular
                        counter.   The  counters  are listed in the Network
                        Management Information section.

                        Value - the counter value.

                        Causes  -  specific   reasons   the   counter   was
                        incremented.   Some counters may be incremented for
                        one or more reasons.  For example, the data  errors
                        inbound counter can be incremented because of block
                        check errors or framing errors.



            Read-event

     The Read-event function reads the next event  from  the  event  buffer
     associated  with the specified channel and removes that event from the
     queue.

     Only one event at a time need be buffered.  The higher level must poll
     the  event  buffer  often  enough to avoid an excessive number of lost
     events.


     READ-EVENT(Channel-id,Buffer,Return-code,Events-lost)
     Interfaces


     Inputs:

         Channel-id
                    event is to be read.

         Buffer

     Outputs:

         Return-code

                        Success - event read with no problems.

                        Buffer too small - the buffer was not big enough to
                        contain  the  entire  event.   The  information  is
                        truncated.  Information that would not fit is lost.

                        No events - the queue is empty.

                        Unrecognized channel - there is no channel with the
                        specified identification.

         Events-lost
                    Read-event.

         Buffer
                    includes the following information:

                        Event-type - the identification of the event.   The
                        events  and  their  parameters  are  listed  in the
                        Network Management Information section.

                        Event-parameters - the parameters  associated  with
                        the event.  Each event parameter entry includes the
                        following information:

                            Parameter-type  -  the  identification  of  the
                            parameter.

                            Value - the value of the parameter.



          Ethernet Interfaces

     This section summarizes the Ethernet interfaces on which DNA  Ethernet
     Data  Link  depends.   For  a  complete  description  of  the Ethernet
     interfaces, refer to the Digital, Intel, Xerox Ethernet Specification,
     Version  2.0.   This section only contains those functions that relate
     directly to the operation of the DNA Ethernet Data Link.

     The Ethernet specification uses Pascal as its representation language.
     That  notation  is  reproduced here to the minimum extent necessary to
     recognize functions between the specifications.  This is not  intended
     to be a complete description of the Ethernet interfaces.
     Interfaces


     Most of the Ethernet interface functions return a status as the  value
     of the function.



            Client to Data Link Interface

     The Client to Data Link Interface is the one used by the DNA  Ethernet
     Data  Link  to transmit and receive frames.  It contains the following
     functions:

       .  TransmitFrame - send a frame.

       .  ReceiveFrame - receive a frame.



              TransmitFrame

     TransmitFrame sends a frame.  It does not return  until  the  transmit
     either succeeds or fails.


     TransmitFrame (destinationParam,sourceParam,typeParam,dataParam)

     Inputs:

         destinationParam

         sourceParam

         typeParam

         dataParam

     Outputs:

         TransmitFrame

                    transmitOK - frame successfully transmitted.

                    excessiveCollisionError - transmission failed.



              ReceiveFrame

     ReceiveFrame receives a frame.  It does not return until  a  frame  is
     received.


     ReceiveFrame (destinationParam,sourceParam,typeParam,dataParam)
     Interfaces


     Inputs:  none.

     Outputs:

         ReceiveFrame

                        receiveOK - frame successfully received.

                        frameCheckError - frame block check failed.

                        alignmentError - frame did not contain an  integral
                        number of bytes.

         destinationParam

         sourceParam

         typeParam

         dataParam



            Network Management to Data Link Interface

     The Network Management to Data Link Interface is the one used  by  DNA
     Ethernet  Data  Link  for  network  management information and control
     access to the DNA Ethernet  Data  Link.   It  contains  the  following
     functions:

       .  ReadEthernetAddress - read the physical address.

       .  ReadNumberCollisions - read the number of collisions for the last
          TransmitFrame.

       .  DataLinkOn - start data link operation.

       .  DataLinkOff - stop data link operation.

       .  SetAddressMode -  changes  addressing  mode  between  normal  and
          promiscuous.

       .  MulticastOn - enable reception of multicast addresses.

       .  MulticastOff - disable reception of multicast addresses.



            Network Management to Physical Link Interface

     The Network Management to Physical Link Interface is the one  used  by
     the  DNA  Ethernet  Data  Link  for network management information and
     control access  to  the  Ethernet  Physical  Link.   It  contains  the
     following function:
     Interfaces


       .  CheckTransmit - checks status of last TransmitFrame.




        NETWORK MANAGEMENT INFORMATION

     This section describes the counters and events that the  DNA  Ethernet
     Data Link provides for the Network Management layer.  Each description
     contains a conceptual definition of the information and a statement of
     its  use.   Precise  operational  definitions  are  in  the  Operation
     section.



          Counters

     The following counters are kept for each Ethernet  channel.   Some  of
     them  are also kept for portals.  Counters are unsigned integers.  All
     counters remain at their maximum value to indicate overflow.

     Unless  otherwise  stated,  all  counters  include  both  normal   and
     multicast  traffic.   Furthermore,  they  include  information for all
     protocol types.  Frames received and bytes received  counters  do  not
     include frames received with errors.

     The following table contains the names and  bit  lengths  of  all  the
     counters:

             Length   Name
               16     Seconds since last zeroed
               32     Bytes received
               32     Bytes sent
               32     Frames received
               32     Frames sent
               32     Multicast bytes received
               32     Multicast frames received
               32     Frames sent, initially deferred
               32     Frames sent, single collision
               32     Frames sent, multiple collisions
               16     Send failure *
               16     Collision detect check failure
               16     Receive failure *
               16     Unrecognized frame destination
               16     Data overrun
               16     System buffer unavailable
               16     User buffer unavailable
                   * Counter has multiple causes

     The following counters are kept for each portal:

             Seconds since last zeroed
             Bytes received
             Bytes sent
             Frames received
     Network Management Infromation


             Frames sent
             User buffer unavailable

          Seconds since last zeroed

          The number of seconds since the counters were last  zeroed.   The
          length is 16 bits.

          Provides  a  frame  of  reference  for  the  other  counters   by
          indicating the amount of time they cover.

          Bytes received

          The total number of user data bytes successfully received.   This
          does  not include Ethernet data link headers.  This number is the
          number of bytes in the Ethernet data field,  which  includes  any
          padding or length fields when they are enabled.  The length is 32
          bits.   These  are  bytes  from  frames  that   passed   hardware
          filtering.

          When the number of frames received is used to calculate  protocol
          overhead, the overhead plus bytes received provides a measurement
          of the amount of  Ethernet  bandwidth  (over  time)  consumed  by
          frames addressed to the local system.

          Bytes sent

          The total number of user  data  bytes  successfully  transmitted.
          This  does  not  include  Ethernet data link headers or data link
          generated retransmissions.  This number is the number of bytes in
          the  Ethernet  data  field,  which includes any padding or length
          fields when they are enabled.  The length is 32 bits.

          When the number of frames sent  is  used  to  calculate  protocol
          overhead,  the overhead plus bytes sent provides a measurement of
          the amount of Ethernet bandwidth (over time) consumed  by  frames
          sent by the local system.

          Frames received

          The total number of frames successfully received.  The length  is
          32 bits.  These are frames that passed hardware filtering.

          Provides a gross measurement of incoming Ethernet  usage  by  the
          local  system.   Provides information used to determine the ratio
          of the error counters to successful transmits.

          Frames sent

          The total number of frames successfully transmitted.   This  does
          not  include  data link generated retransmissions.  The length is
          32 bits.
     Network Management Infromation


          Provides a gross measurement of outgoing Ethernet  usage  by  the
          local  system.   Provides information used to determine the ratio
          of the error counters to successful transmits.

          Multicast bytes received

          The total number of multicast data bytes  successfully  received.
          This does not include Ethernet data link headers.  This number is
          the number of bytes in the Ethernet data field.  The length is 32
          bits.

          In conjunction with total bytes received, provides a  measurement
          of  the percentage of this system's receive bandwidth (over time)
          that was consumed by multicast  frames  addressed  to  the  local
          system.

          Multicast frames received

          The total number of multicast frames successfully received.   The
          length is 32 bits.

          In conjunction with  total  frames  received,  provides  a  gross
          percentage  of  the Ethernet usage for multicast frames addressed
          to this system.

          Frames sent, initially deferred

          The total number of times that a frame transmission was  deferred
          on its first transmission attempt.  The length is 32 bits.

          In  conjunction  with  total  frames  sent,   measures   Ethernet
          contention with no collisions.

          Frames sent, single collision

          The  total  number  of  times  that  a  frame  was   successfully
          transmitted on the second attempt after a normal collision on the
          first attempt.  The length is 32 bits.

          In  conjunction  with  total  frames  sent,   measures   Ethernet
          contention  at a level where there are collisions but the backoff
          algorithm still operates efficiently.

          Frames sent, multiple collisions

          The  total  number  of  times  that  a  frame  was   successfully
          transmitted on the third or later attempt after normal collisions
          on previous attempts.  The length is 32 bits.

          In  conjunction  with  total  frames  sent,   measures   Ethernet
          contention  at a level where there are collisions and the backoff
          algorithm no longer operates efficiently.
     Network Management Infromation


                                        NOTE

                  No single frame is counted in more  than  one  of
                  the above three counters.

          Send failures

          The total number of times a transmit attempt failed.  The  length
          is  16  bits.   Each  time  the counter is incremented, a type of
          failure  is  recorded.   When  Read-counter  function  reads  the
          counter,  the list of failures is also read.  When the counter is
          set to zero, the list of failures is cleared.

          In conjunction with total frames  sent,  provides  a  measure  of
          significant  transmit problems.  All of the problems reflected in
          this counter are also captured as events.

          Following are the possible failures.  More information  on  their
          meanings and use can be found in the section on events.

              Excessive collisions
              Carrier check failed
              Short circuit
              Open circuit
              Frame too long
              Remote failure to defer

          Collision detect check failure

          The approximate number of times that  collision  detect  was  not
          sensed after a transmission.  The length is 16 bits.

          If this counter contains a number roughly equal to the number  of
          frames sent, either the collision detect circuitry is not working
          correctly or the test signal is not implemented.

          Receive failures

          The total  number  of  frames  received  with  some  data  error.
          Includes   only  data  frames  that  passed  either  physical  or
          multicast address comparison.   The  length  is  16  bits.   This
          counter  includes  failure  reasons  in  the same way as the send
          failure counter.

          In conjunction with total frames received, provides a measure  of
          data  related receive problems.  All of the problems reflected in
          this counter are also captured as events.

          Following are the possible reasons.  More  information  on  their
          meaning and use can be found in the section on events.

              Block check error
              Framing error
              Frame too long
     Network Management Infromation


          Unrecognized frame destination

          The number of times a frame was discarded because  there  was  no
          portal with the protocol type or multicast address enabled.  This
          includes frames received for the physical address, the  broadcast
          address, or a multicast address.  The length is 16 bits.

          Data overrun

          The total number of times the hardware  lost  an  incoming  frame
          because it was unable to keep up with the data rate.

          In conjunction with total frames received, provides a measure  of
          hardware  resource  failures.   The  problem  reflected  in  this
          counter is also captured as an event.

          System buffer unavailable

          The total number of times no system buffer was available  for  an
          incoming frame.  The length is 16 bits.

          In conjunction with total frames received, provides a measure  of
          system buffer related receive problems.  The problem reflected in
          this counter is also captured as an event.

          This can be any buffer between the hardware and the user  buffers
          (those  supplied on Receive requests).  Further information as to
          potential different buffer pools is implementation specific.

          User buffer unavailable

          The total number of times no user buffer  was  available  for  an
          incoming  frame that passed all filtering.  These are the buffers
          supplied by users on Receive requests.  The length is 16 bits.

          In conjunction with total frames received, provides a measure  of
          user  buffer  related receive problems.  The problem reflected in
          this counter is also captured as an event.



          Events

     The following events are recorded for each channel.  Such  information
     as  channel  identification, date, and time are assumed to be added as
     needed by higher layers.

     The event descriptions include a conceptual definition  of  the  event
     and  an explanation of its use.  Precise operational event definitions
     are in the Operation section.

     Events are recorded regardless of protocol type.
     Network Management Infromation


                                      NOTE

             Since   some   events   can   occur   very    rapidly,
             implementations   must   take   care  that  main  line
             processing is not pre-empted by event processing.

          Initialization failed

          This event is logged when the self test at initialization  fails.
          The procedures in the self test are implementation dependent, but
          include such things as  internal  hardware  loop  testing.   This
          event is optional on channels that cannot fail in initialization.

          When this event is logged, it includes an implementation specific
          value that indicates the reason for the failure.

          Provides notification that the channel is incapable of operating.

          Send failed

          This event is logged for any error in transmitting a frame.   The
          reason for the error is included, followed by any other pertinent
          data.  The possible reasons are:

              Excessive collisions

                  Exceeded the maximum number  of  retransmissions  due  to
                  collisions.

                  Indicates an overload condition  on  the  Ethernet.   Too
                  many systems are trying to transmit at the same time.

              Carrier check failed

                  The data link did not sense the receive  signal  that  is
                  required to accompany the transmission of a frame.

                  Indicates a failure in either transmitting  or  receiving
                  hardware.   Could  be  either  transceiver or transceiver
                  cable related.  Could be caused by a babbling  controller
                  that has been cut off.

              Short circuit

                  There is a short somewhere  in  the  local  area  network
                  coaxial      cable,     or     the     transceiver     or
                  controller/transceiver cable failed.  When this reason is
                  logged,  an  estimated  distance  to  the failure, in bit
                  times, is included.

                  This indicates a problem either in the local hardware  or
                  a  global  network problem.  The two can be distinguished
                  by checking to see if other  systems  are  reporting  the
                  same problem.
     Network Management Infromation


              Open circuit

                  There is a break somewhere  in  the  local  area  network
                  coaxial  cable.  When this reason is logged, an estimated
                  distance to the failure, in bit times, is included.

                  This indicates a problem either in the local hardware  or
                  a  global  network problem.  The two can be distinguished
                  by checking to see if other  systems  are  reporting  the
                  same problem.

              Frame too long

                  The controller or transceiver cut off transmission at the
                  maximum size.

                  This indicates a problem with the local  system:   either
                  it  tried  to  send  a  frame  that  was too long, or the
                  hardware cut off transmission too soon.

              Remote failure to defer

                  A remote system  began  transmitting  after  the  allowed
                  window for collisions.

                  This indicates either a problem with some other  system's
                  carrier sense or a weak transmitter locally.

          Collision detect check failed

              This event is logged when the data link  did  not  sense  the
              collision  signal that is supposed to follow the transmission
              of a frame.

              Indicates a failure either in the transceiver or  transceiver
              cable collision circuitry.

          Receive failed

          This event is logged for any error in  receiving  a  frame.   The
          reason  for  the  error  is  included, followed by the source and
          destination physical addresses, the protocol type, and any  other
          pertinent data as defined for the specific event, if available.

          The possible reasons are:

              Block check error

                  The frame failed the CRC check.

                  This indicates several  possible  failures.   It  can  be
                  caused  by  such  things as electromagnetic interference,
                  late collisions, or improperly  set  hardware  parameters
                  (such as receiver squelch).
     Network Management Infromation


              Framing error

                  The frame did not contain an integral  number  of  8  bit
                  bytes.

                  This indicates several  possible  failures.   It  can  be
                  caused  by  such  things as electromagnetic interference,
                  late collisions, or improperly  set  hardware  parameters
                  (such as receiver squelch).

              Data overrun

                  The frame was lost due to a hardware resource failure.

                  This  indicates,  for  example,   insufficient   hardware
                  buffers or CPU time.

              System buffer unavailable

                  The frame was  discarded  because  there  was  no  system
                  buffer available to receive it.

                  This indicates a lack of buffers  in  the  local  system.
                  This  can  be  any  buffer between the cable and the user
                  buffers (those  supplied  by  the  user  in  the  Receive
                  function).  Further information as to potential different
                  buffer pools is implementation specific.

              User buffer unavailable

                  The frame was discarded because there was no user  buffer
                  available to receive it.

                  This indicates a lack of buffers  in  the  user  process.
                  These are the buffers supplied by the user in the Receive
                  function.

              Unrecognized frame destination

                  The frame was discarded because there was no portal  with
                  either   the  protocol  type  or  the  multicast  address
                  enabled.  This includes frames received for the  physical
                  address, the broadcast address, or a multicast address.

                  This indicates either  that  the  local  system  has  not
                  enabled  a  protocol  type  or  multicast address that it
                  should or that a remote system is  attempting  to  use  a
                  protocol that is locally unsupported.

              Frame too long

                  The frame  was  discarded  because  it  was  outside  the
                  Ethernet maximum length and could not be received.
     Network Management Infromation


                  This indicates that a remote system  is  sending  invalid
                  length frames.



         INTERFACE USAGE EXAMPLES

      This section contains examples of how the  user  interface  might  be
      used.   The  intent is to motivate the functions and to show how they
      might interrelate.  This section does not specify how the  interfaces
      must be used.



           Portal Filter Setup

      This example opens a portal and sets up its receive filter  criteria.
      The  portal wishes to receive frames of protocol types P1 and P2 that
      are addressed to the physical address and multicast address M1.

          Open(Channel-id,Return-code,Portal-id)
          IF Return-code = "success"
             Enable-protocol(Portal-id,P1,Return-code)
             IF Return-code = "success"
                Enable-protocol(Portal-id,P2,Return-code)
                IF Return-code = "success"
                   Enable-multicast(Portal-id,M1,Return-code)
                ENDIF
             ENDIF
          ENDIF
          IF Return-code = "success"
             {Use the data link}
             Close(Portal-id,Return-code)
          ELSE
             {Handle error}
          ENDIF



           Data Error Diagnostic

      In this case, the data link is to be used  by  a  diagnostic  program
      that  has  a  direct  interest  in the characteristics of incorrectly
      received messages.  It wishes to supply  its  own  cyclic  redundancy
      code,  find what code was received from the other end, and be able to
      analyze the bit patterns in damaged frames.  Using these features  it
      can  test  some  of  the  data handling within both the local and the
      remote sides of the data link.

      It accomplishes this by using the options on the  Transmit,  Receive,
      and  Receive-poll  functions  that allow it to meet its task specific
      needs.
     Operation


         OPERATION

      The bulk of the detailed  operation  of  Ethernet  is  found  in  the
      Ethernet  Specification, Version 2.0, and is not repeated here.  This
      section specifies the operation of those functions that are additions
      to  the  Ethernet  base.   The  operations  specified here are portal
      handling and transmit/receive handling, which includes  recording  of
      counters and events.

      This section uses a model implementation  to  describe  DNA  Ethernet
      Data  Link  operation.  Implementations are not required to implement
      this model, but must be  functionally  equivalent.   For  example,  a
      counter  kept  by one implementation must be incremented according to
      exactly the same criteria as the same counter in any other.

      The model implementation is modularized according  to  the  following
      diagram:

                   .---------.     .---------.       .---------.
                   | User #1 |     | User #2 | . . . | User #n |
                   `---------'     `---------'       `---------'
                        |               |                 |
                        `--------.      |      .----------'
                                 |      |      |
                              .--------------------.
                              |   Portal Handler   |
                              `--------------------'
                                         |
                .-------------.    .------------.    .------------.
                | Transmitter |----|   Portal   |----|  Receiver  |
                |             |-.  | Data Base  |  .-|            |
                `-------------' |  `------------'  | `------------'
                       |        |                  |       |
                       |        |  .------------.  |       |
                       |        `--| Management |--'       |
                       |           | Data Base  |          |
                       |           `------------'          |
                       |                                   |
                     .---------------------------------------.
                     | Ethernet Data Link and Physical Link  |
                     `---------------------------------------'

      The Portal Handler maintains the Portal Data Base according  to  user
      requests through the User Interface.  The Portal Handler communicates
      with the Transmitter and Receiver through the Portal Data Base.   The
      Transmitter  and  Receiver  send  and  receive frames through the DNA
      Ethernet Data Link User Interface  and  maintain  counter  and  event
      information in the Management Data Base.

      This specification assumes the mutual  exclusion  necessary  to  keep
      shared data bases correct.

      The Portal Data Base contains an entry for each  open  portal.   Each
      entry contains:
     Operation


           .  Channel identification.

           .  Count of lost frames.

           .  Pad flag.

           .  List of enabled protocol types.

           .  List of enabled multicast addresses.

           .  List of outstanding Transmits, each list entry includes:


               -  Request state, set to "pending" by the Portal Handler and
                  "complete" by the Transmitter.

               -  Destination address supplied by the user for the frame.

               -  Protocol type supplied by the user for the frame.

               -  Input buffer with the user's data to send in the frame.

               -  Return code returned by the Transmitter.

               -  CRC-32 optionally supplied by the user for the frame.  If
                  not user-supplied, the DNA Ethernet Data Link will supply
                  it.

               -  Error detail returned by the  Transmitter  if  applicable
                  and desired by the user.

               -  Fault distance returned by the Transmitter if  applicable
                  and desired by the user.


           .  List of outstanding Receives, each list entry includes:


               -  Request state, set to "pending" by the Portal Handler and
                  "complete" by the Receiver.

               -  Output buffer supplied by the user for a received frame.

               -  Indicator whether user wants frames with invalid data.

               -  Return code returned by the Receiver.

               -  Error detail returned by the Receiver if  applicable  and
                  desired by the user.

               -  Destination address returned from the received  frame  by
                  the Receiver.
     Operation


               -  Source address returned from the received  frame  by  the
                  Receiver.

               -  Protocol type returned from the  received  frame  by  the
                  Receiver.

               -  Bytes lost returned by the  Receiver  if  applicable  and
                  desired by the user.

               -  CRC-32 returned from the received frame by  the  Receiver
                  if desired by the user.





           Portal Handler

      This section describes Portal Handler operation relative to the  User
      Interface functions.  The Portal Handler functions are:

          Open
          Enable-promiscuous
          Disable-promiscuous
          Enable-protocol
          Disable-protocol
          Enable-multicast
          Disable-multicast
          Close
          Transmit
          Transmit-poll
          Receive
          Receive-abort
          Receive-poll



             Open

      When the user calls Open,  if  the  implementation  allows  only  one
      promiscuous  receiver,  the  Portal  Handler  checks to see if one is
      active.  If so, it returns "promiscuous receiver active".

      If there is no  promiscuous  receiver  problem,  the  Portal  Handler
      checks  that it has the necessary resources to open a new portal.  If
      not, it returns "no resources".

      If resources are available, the Portal Handler checks to see  if  the
      requested channel exists.  If not, it returns "unrecognized channel".

      If the channel exists, the Portal Handler checks to see if it is  on.
      If not, it returns "channel not on".
     Operation


      If the channel is on, the Portal Handler initializes the portal  data
      base  with  the pad flag, empty lists, and the channel identification
      and returns "success" and the portal identification.



             Enable-promiscuous

      When the user calls Enable-promiscuous, the Portal Handler checks  to
      see  if the supplied portal identification identifies an open portal.
      If not, it returns "unrecognized portal".

      If the portal is open, the Portal Handler does one of the following:


           .  Returns "not implemented".

           .  Or checks to see if any other portal is open or this one  has
              any  protocol  types or multicast addresses enabled and if so
              it returns "non-exclusive".

           .  Or accepts the fact that for this  portal  it  will  have  to
              duplicate messages that other portals receive.


      If the Portal Handler  can  allow  promiscuous  receive,  it  enables
      promiscuous  addressing  through the DNA Ethernet Data Link.  If this
      fails, it returns  "channel  in  wrong  state".   Otherwise  it  puts
      "promiscuous"  in  the  portal's  list  of enabled protocol types and
      returns "success".



             Disable-promiscuous

      When the user calls Disable-promiscuous, the Portal Handler checks to
      see  if the supplied portal identification identifies an open portal.
      If not, it returns "unrecognized portal".

      If the portal is open, the Portal Handler checks the portal's list of
      protocol   types   for  "promiscuous".   If  not  found,  it  returns
      "success".

      If the portal is receiving promiscuously, the  Portal  Handler  scans
      all  other  portals  to see if any others are receiving promiscuously
      (if the implementation allows multiple  promiscuous  receivers).   If
      none  are  found,  the Portal Handler disables promiscuous addressing
      through the DNA Ethernet Data Link.  The Portal Handler then  returns
      "success".
     Operation


             Enable-protocol

      When the user calls Enable-protocol, the Portal Handler checks to see
      if  the supplied portal identification identifies an open portal.  If
      not, it returns "unrecognized portal".

      If the portal is open, the Portal Handler checks to  see  if  it  has
      resources  to  record another protocol type for this portal.  If not,
      it returns "no resources".

      If the Portal Handler has resources, it scans all portals to  see  if
      any  of  them  have  the  protocol  type  enabled.  If so, it returns
      "protocol type in use".

      If the protocol type is available, the Portal Handler checks  to  see
      if the portal's channel is on.  If not, it returns "channel not on".

      If the channel is on, the Portal Handler puts the  protocol  type  in
      the portal's list and returns "success".



             Disable-protocol

      When the user calls Disable-protocol, the Portal  Handler  checks  to
      see  if the supplied portal identification identifies an open portal.
      If not, it returns "unrecognized portal".

      If the portal is open, the  Portal  Handler  checks  to  see  if  the
      protocol  type is in the portal's list.  If it is, the Portal Handler
      removes it.  The Portal Handler then returns "success".



             Enable-multicast

      When the user calls Enable-multicast, the Portal  Handler  checks  to
      see  if the supplied portal identification identifies an open portal.
      If not, it returns "unrecognized portal".

      If the portal is open, the Portal Handler checks to  see  if  it  has
      resources  to  record  another multicast address for this portal.  If
      not, it returns "no resources".

      If the Portal Handler has resources, it checks to see if the portal's
      channel is on.  If not, it returns "channel not on".

      If the channel is on, the Portal Handler puts the  multicast  address
      in  the  portal's  list.   If  this  is  the  first multicast address
      enabled, the Portal Handler calls  the  DNA  Ethernet  Data  Link  to
      enable multicast.  The Portal Handler then returns "success".
     Operation


             Disable-multicast

      When the user calls Disable-multicast, the Portal Handler  checks  to
      see  if the supplied portal identification identifies an open portal.
      If not, it returns "unrecognized portal".

      If the portal is open, the  Portal  Handler  checks  to  see  if  the
      multicast  address  is  in  the  portal's list.  If it is, the Portal
      Handler removes it.  If this was the only multicast address  enabled,
      the  Portal  Handler  calls  the  DNA  Ethernet  Data Link to disable
      multicast.  The Portal Handler then returns "success".



             Close

      When the user calls Close, the Portal Handler checks to  see  if  the
      supplied portal identification identifies an open portal.  If not, it
      returns "unrecognized portal".

      If the portal is open, the  Portal  Handler  checks  to  see  if  the
      portal's  transmit  and receive lists are empty.  If they are not, it
      returns "Calls outstanding".

      If the portal's transmit and receive  lists  are  empty,  the  Portal
      Handler releases all resources for the portal and returns "success".



             Transmit

      When the user calls Transmit, the Portal Handler checks to see if the
      supplied portal identification identifies an open portal.  If not, it
      returns "unrecognized portal".

      If the portal is open, the Portal Handler checks to  see  if  it  has
      resources  to  queue  a  transmit for the portal.  If it does not, it
      returns "no resources".

      If the Portal Handler has resources, it checks to see if the portal's
      channel is on.  If it is not, it returns "channel not on".

      If the portal's channel is  on,  the  Portal  Handler  transfers  the
      information  from  the  call  into the portal's transmit list, marked
      "pending", for action by the Transmitter.  The  Portal  Handler  then
      returns "request accepted".



              Transmit-poll

      When the user calls Transmit-poll, the Portal Handler checks  to  see
      if  the supplied portal identification identifies an open portal.  If
      not, it returns "unrecognized portal".
     Operation


      If the portal is open, the Portal Handler checks the transmit list to
      see if it is empty.  If so, it returns "none outstanding".

      If the transmit list is not empty, the Portal Handler checks  to  see
      if  the  first  request state is "complete".  If not, it returns "not
      complete".

      If the first request is complete, the Portal Handler gets the  output
      parameters  from  the  list  for  return.   The  Portal  handler then
      deallocates  the  transmit  list  entry  and   returns   the   output
      parameters.



              Receive

      When the user calls Receive, the Portal Handler checks to see if  the
      supplied portal identification identifies an open portal.  If not, it
      returns "unrecognized portal".

      If the portal is open, the Portal Handler gets the portal's count  of
      frames  lost  and  zeros  its  own  record  of the count.  The Portal
      Handler then checks to see if it has resources to queue a receive for
      the portal.  If it does not, it returns "no resources" and the frames
      lost count.

      If the Portal Handler has resources, it checks to see if the portal's
      channel  is  on.   If  it is not, it returns "channel not on" and the
      frames lost count.

      If the portal's channel is  on,  the  Portal  Handler  transfers  the
      information  from  the  call  into  the portal's receive list, marked
      "pending", for action by  the  Receiver.   The  Portal  Handler  then
      returns "request accepted" and the frames lost count.



              Receive-abort

      When the user calls Receive-abort, the Portal Handler checks  to  see
      if  the supplied portal identification identifies an open portal.  If
      not, it returns "unrecognized portal".

      If the portal is open, the Portal Handler checks the receive list  to
      see if it is empty.  If so, it returns "none outstanding".

      If the receive list is not empty, for each entry, the Portal  Handler
      checks to see if the entry state is "complete".  If not, it marks the
      request "complete", and sets the return code  to  "receive  aborted".
      The Portal Handler then returns "success".
     Operation


              Receive-poll

      When the user calls Receive-poll, the Portal Handler checks to see if
      the  supplied  portal  identification  identifies an open portal.  If
      not, it returns "unrecognized portal".

      If the portal is open, the Portal Handler checks the receive list  to
      see if it is empty.  If so, it returns "none outstanding".

      If the receive list is not empty, the Portal Handler checks to see if
      the  first  request  state  is  "complete".   If not, it returns "not
      complete".

      If the first request is complete, the Portal Handler gets the  output
      parameters  from  the  list  for  return.   The  Portal  handler then
      deallocates the receive list entry and returns the output parameters.



           Transmitter and Receiver

             Transmitter

      The Transmitter constantly scans the the transmit lists for all  open
      portals  for the first pending request.  Whenever it finds one marked
      "pending" it uses the information from that entry to send the frame.

      If the pad flag for the portal indicates that padding is enabled, the
      Transmitter  prefixes  the  user's data with two bytes containing the
      length of the data as indicated by the user, low  order  byte  first.
      If  the  resulting  data  is  less  than  the  Ethernet  minimum, the
      Transmitter adds bytes of zeroes at the end of the user data  to  pad
      out to minimum length.

      The Transmitter then uses the DNA Ethernet  Data  Link  to  send  the
      frame.   When  this  request  completes,  the transmitter records the
      necessary completion information in the portal's transmit list  entry
      and  marks  it  "complete".   The Transmitter then continues its scan
      with the next portal.



             Receiver

      This operational description assumes that Receiver operation is  fast
      enough  to receive all frames received by the DNA Ethernet Data Link.
      Implementations that are not fast enough will  have  to  be  able  to
      record frames lost due to no buffer.

      This description also assumes the most complex form of protocol  type
      matching.   This  is  the form in which multiple users are allowed to
      receive promiscuously regardless of protocol types enabled  by  other
      users.  The simpler cases are direct subsets of this case.
     Operation


      The Receiver has at least one Ethernet maximum size receive buffer of
      its  own.   The  Receiver  always  tries  to keep an Ethernet receive
      outstanding.

      When a frame is received, the Receiver scans the open portals  for  a
      matching  receiver.   It  checks the protocol type list first.  If it
      finds a match here it may then check the multicast address list.   If
      no match in the protocol type list, it goes on to the next portal.  A
      receiver matches if one of the following is true:


       .  The protocol type  matches  and  the  frame  destination  is  the
          physical address or the broadcast address.

       .  The protocol type matches and the multicast destination is in the
          portal's multicast address list.

       .  The portal protocol type list indicates promiscuous.


      If the Receiver finds a match it checks the portal's receive list for
      the first pending request.  If it does not find one it increments the
      portal's frames lost count and  the  total  user  buffer  unavailable
      count,  then  proceeds as if it had completed giving the frame to the
      portal.

      If the Receiver finds a pending  receive,  it  copies  the  pertinent
      information  into  the  portal's receive list according to the user's
      desires.  For example it copies in a frame with  invalid  data  (e.g.
      bad CRC) if the user requested this type of receive.

      If the pad flag is set, the Receiver uses the first two bytes of  the
      data  as  the  received length and copies that amount into the user's
      buffer, not including the first two bytes.  If the actual  length  of
      the  data in the frame is less than the amount indicated by the first
      two bytes, the Receiver gives the user all of the data, including the
      first two bytes, and sets a "length error" return code.

      The Receiver then marks the receive "complete".

      The Receiver repeats this procedure until it  has  checked  all  open
      portals.



             Counters

      This section defines exactly when the data link increments  counters.
      All  counters  operate the same with respect to overflow.  Whenever a
      counter reaches maximum value for its length it remains at that value
      until the counters are set to zero.  This operation is assumed in all
      of the following descriptions of when counters are incremented.   All
      counters are cleared simultaneously.
     Operation


                                      NOTE

              The  names  used  in   the   Ethernet   Version   2.0
              specification  are  indicated in parentheses.  A more
              formal description of their operation can be found in
              the   Pascal   procedural   model   found   in   that
              specification.


       .  Seconds since last zeroed (not specified in Ethernet V2.0)

          This counter is incremented once every  second.   It  allows  the
          counters to be maintained for about 18 hours without being read.

       .  Bytes received (not specified in Ethernet V2.0)

          This counter is updated every time a frame is  received  with  no
          errors (framesReceivedNoErrors).  It is incremented by the number
          of bytes in  the  Ethernet  data  field  of  the  received  frame
          (dataSize).

       .  Bytes sent (not specified in Ethernet V2.0)

          This counter is updated every time a frame is transmitted with no
          errors  (frameSentNoErrors).   It is incremented by the number of
          bytes in  the  Ethernet  data  field  of  the  transmitted  frame
          (dataSize).

       .  Frames received (framesReceivedNoErrors)

          This counter is incremented by one every time a frame is received
          with no errors.

       .  Frames sent (framesSentNoErrors)

          This counter  is  incremented  by  one  every  time  a  frame  is
          transmitted with no errors.

       .  Multicast bytes received (not specified in Ethernet V2.0)

          This counter is updated every time a  frame  is  received  for  a
                                                                        and
          address[1] = 1).  It is incremented by the number of bytes in the
          Ethernet data field of the received frame (dataSize).

       .  Multicast frames received (not specified in Ethernet V2.0)

          This counter is incremented by one every time a frame is received
                                                                        and
          address[1] = 1).

       .  Frames sent, initially deferred (not specified in Ethernet V2.0)
     Operation


          This counter  is  incremented  by  one  every  time  a  frame  is
          transmitted  with  no  errors after being initially deferred.  It
          does  not  get  incremented  if  a  deferral  takes  place  on  a
          subsequent  attempt  to  transmit  after a collision if the first
          attempt was not deferred.

       .  Frames sent, single collision (transmitOkOneCollision)

          This counter  is  incremented  by  one  every  time  a  frame  is
          transmitted  with  no errors after a single collision and backoff
          sequence; i.e., successful on the second attempt.

       .  Frames sent, multiple collisions (transmitOkMultipleCollisions)

          This counter  is  incremented  by  one  every  time  a  frame  is
          transmitted  with  no  errors  after  more than one collision and
          backoff sequence; i.e., successful on  the  third  or  subsequent
          attempt.

       .  Send failures (not specified in Ethernet V2.0)

          This counter is incremented by one every time an error causes the
          termination  of  the transmission of a frame.  This may be due to
          one or more of the following faults  occurring  during  a  single
          Data  Link  TransmitFrame  operation.   A flag is set to indicate
          which type of fault(s) has occurred.   (Ethernet  V2.0  specifies
          two  separate  16-bit counters for framesAbortedLateCollision and
          framesAbortedExcessCollisions.)

             Excessive collisions (excessiveCollisionError)
             Carrier check failed (carrierSenseFailed)
             Short circuit
             Open circuit
             Frame too long
             Remote failure to defer (lateCollision)

       .  Collision detect check failures (collisionDetectFailed)

          This counter is incremented by one every time no  collisionDetect
          signal  is  seen from the Physical Layer during a transmission or
          within 2 microseconds following the deassertion  of  carrierSense
          after the end of transmission.

       .  Receive failures (not specified in Ethernet V2.0)

          This counter is incremented by one every time an error causes  an
          incoming frame to be lost.  This may be due to one or more of the
          following faults occurring during a single Data Link ReceiveFrame
          operation.   A flag is set to indicate which type of fault(s) has
          occurred.  (Ethernet V2.0 specifies two separate 16-bit  counters
          for framesReceivedCRCErrors and framesReceivedAlignErrors)

             Block check error (frameCheckError)
             Framing error (alignmentError)
             Frame too long
     Operation


       .  Unrecognized frame destinations (not specified in Ethernet V2.0)

          This counter is incremented by one every time a frame is received
          but  discarded because there was no portal with the protocol type
          or multicast address enabled.

       .  Data overruns (not specified in Ethernet V2.0)

          This counter is incremented by one every time an  incoming  frame
          is  lost because the hardware was unable to keep up with the data
          rate.

       .  System buffers unavailable (not specified in Ethernet V2.0)

          This counter is incremented by one every time a frame is received
          but discarded because there is no system buffer available.

       .  User buffers unavailable (not specified in Ethernet V2.0)

          This counter is incremented by one every time a frame is received
          but discarded because there is no user buffer available.




             Events

      This section defines exactly when the data link records events.

                                      NOTE

              The  names  used  in   the   Ethernet   Version   2.0
              specification  are  indicated in parentheses.  A more
              formal description of their operation can be found in
              the   Pascal   procedural   model   found   in   that
              specification.


       .  Initialization failed (not specified in Ethernet V2.0)

          This event is logged whenever the  self  test  at  initialization
          fails.    The  operation  of  the  self  test  is  implementation
          specific.

       .  Send failed (not specified in Ethernet V2.0)

          This event is logged every time an error causes  the  termination
          of  the  transmission of a frame.  This may be due to one or more
          of the following faults  occurring  during  a  single  Data  Link
          TransmitFrame operation.

             Excessive collisions (excessiveCollisionError)
             Carrier check failed (carrierSenseFailed)
             Short circuit
             Open circuit
     Operation


             Frame too long
             Remote failure to defer (lateCollision)

       .  Collision detect check failed (collisionDetectFailed)

          This event is logged every time no collisionDetect signal is seen
          from  the  Physical  Layer  during  a  transmission  or  within 2
          microseconds following the deassertion of carrierSense after  the
          end of transmission.

       .  Receive failed

          This event is logged every time an incoming frame is lost.   This
          may  be  due  to  one  or  more of the following faults occurring
          during or immediately after a Data Link ReceiveFrame operation.

             Block check error (frameCheckError)
             Framing error (alignmentError)
             Data Overrun
             System buffer unavailable
             User buffer unavailable
             Unrecognized frame destination













                                   APPENDIX A

                     PROTOCOL TYPES AND MULTICAST ADDRESSES



     This appendix lists all the protocol  types  and  multicast  addresses
     defined   for  Digital  Equipment  Corporation  or  across  companies.
     DIGITAL protocol types are in the range 60-00 through 60-09.   DIGITAL
     physical  and  multicast  addresses are in the range AA-00-00-00-00-00
     through    AA-00-04-FF-FF-FF     and     AB-00-00-00-00-00     through
     AB-00-04-FF-FF-FF, respectively.



          CROSS-COMPANY ASSIGNMENTS

     The cross-company protocol type is:

         Value      Meaning
         90-00      Loopback

     The cross-company multicast addresses are:

         Value                  Meaning
         FF-FF-FF-FF-FF-FF      Broadcast
         CF-00-00-00-00-00      Loopback Assistance



          DIGITAL ASSIGNMENTS

     The DIGITAL protocol types are:

         Value      Meaning
         60-00
         60-01      DNA Dump/Load (MOP)
         60-02      DNA Remote Console (MOP)
         60-03      DNA Routing 
         60-04      Local Area Transport (LAT)
         60-05      Diagnostics
         60-06      Customer use
         60-07      System Communication Architecture (SCA)
     PROTOCOL TYPES AND MULTICAST ADDRESSES


     DNA Phase IV nodes  have  addresses  in  the  range  AA-00-04-00-00-00
     through   AA-00-04-00-FF-FF   (see   DNA   Routing   Layer  Functional
     Specification).

     The DIGITAL multicast addresses are:

         Value                  Meaning
         AB-00-00-01-00-00      DNA Dump/Load Assistance (MOP)
         AB-00-00-02-00-00      DNA Remote Console (MOP)
         AB-00-00-03-00-00      DNA Routing Layer routers
         AB-00-00-04-00-00      DNA Routing Layer end nodes
         AB-00-03-00-00-00      Local Area Transport (LAT)
         AB-00-04-00-00-00 thru
           AB-00-04-00-FF-FF    Customer use
         AB-00-04-01-00-00 thru
           AB-00-04-01-FF-FF    System Communication Architecture (SCA)
