Joyce,
    Here is a "rough outline" that I've put together that describes the
protocl we are implementing.  If possible, we would like a reserved system
well known port so that the broadcasts we send won't interfere with anyone
else's protocols.

    Here at Commodore we have been using this protocol for a few months
and it seems to work well on our LAN, which has a large number of machines
running Envoy, TCP/IP, Lantastic (PC Protocol) and DECNet all on the same.
Ethernet.  So far the protocl seems to be working well.

    If you have any questions about the protocol, or you would like me
to clarify some parts of the specification, please send me email or call
me at (215)-344-3014.

-Ken











                          Preliminary Specification for

                    The Amiga Envoy Network Inquiry Protocol




                                  June 1992




                                prepared for

                     Internet Assigned Numbers Authority
                     USC - Information Sciences Institute
                             4676 Admirality Way
                    Marina Del Rey, California  90292-6692





                                    by

                            Amiga Networking Group
                             Commodore-Amiga, Inc.
                               1200 Wilson Drive
                           West Chester, PA  19380



June 1992
                                          Amiga Envoy Network Inquiry Protocol



                             TABLE OF CONTENTS

    PREFACE .............................................................. iii

1.  INTRODUCTION ........................................................... 1

2.  FUNCTIONAL SPECIFICATION ............................................... 2

  2.1  Header Format ....................................................... 2
  2.2  Inquiry Data Format ................................................. 2
  2.3  Defined Inquiry Types ...............................................

3.  RELATIONSHIP TO OTHER PROTOCOLS ........................................ 3









June 1992
                                          Amiga Envoy Network Inquiry Protocol



                                  PREFACE




This document describes the Amiga Envoy Network Inquiry Protocol (NIP) as used
by the Amiga Envoy networking system.  This is the first revision of the NIP
specification and is subject to change if Commodore-Amiga feels it is necessary
to enhance or modify the protocol.  Any such changes will be documented in
later editions of this text.


                                                                  Kenneth Dyke



                   The Amiga Envoy Network Inquiry Protocol



                          1.  INTRODUCTION

The Amiga Envoy Network Inquiry Protocol (NIP) is designed to allow software
written for the Amiga Envoy networking system to gather information from hosts
on a network that are using Envoy.

This document describes the functions performed by the protocol and its
relationship to other DARPA protocols.

Currently, NIP relies on UDP and IP to provide its data transport.  UDP and
IP were chosen because they provide the necessary routing, broadcast, and
variable length packet facilities required by the NIP.



                     2. FUNCTIONAL SPECIFICATION

2.1.  Header Format

  NIP Inquiries are sent as UDP datagrams.  The UDP and IP headers carry
  serveral pieces of information, including the source and destination
  host addresses.  A NIP header follows the UDP header, supplying information
  specific to the NIP protocol.

  NIP Header Format

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Reserved = 0          |        Inquiry Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Inquiry ID           |       Inquiry Packet Type     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          inquiry data                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           NIP Header Format

            Note that one tick mark represents one bit position.

                               Figure 1.

  Reserved:  16 bits

    This field is currently unused, by will probably be used in the
    future if Commodore-Amiga requires a new Envoy protocol that uses
    UDP.  It must be set to zero for future compatibility.

  Inquiry Length:  16 bits

    This field specifies the length of the inquiry data including
    the inquiry header but not including the length of the IP or UDP
    headers.

  Inquiry ID:  16 bits

    This field specifies a unique ID assigned to the inquiry by the
    host that the inquiry originated from.

  Inquirt Packet Type: 16 bits

    This filed is used to specify the current state of this inquiry
    packet.  Currently this field may have one of three values:

      PTYPE_QUERY = 0

      This packet is currently being broadcast to all physcial networks
      within a Realm.


      PTYPE_RESPONSE = 1

      This packet is currently on it's way back to it's originator.


      PTYPE_TRANSIT = 2

      This packet is currently being transported from a host withing
      a realm to a Realm Server.


2.2.  Inquiry Data Format

  The format of the NIP inqiry data is a series of structures known
  on the Amiga as TagItem structures.  Each TagItem structure contains
  two 32 bit values.  The first 32-bit value is used to identify the
  TagItem's type.  The second longword is used in a manner specific
  to each kind of TagItem.

  TagItem Format

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           ti_Tag                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           ti_Data                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


  A TagItem with a ti_Tag value of 0 specifies that the last TagItem
  structure has been reached.

  Any other data that is required by the TagItem's in the Inquiry
  packet is attached after the last TagItem in the packet.  Usually
  the ti_Data field is used be a TagItem to specify the offset into
  the packet from the start of the Inquiry data if that TagItem
  requires more that a longword of information (such as a hostname)


2.3 Defined TagItem Tag values and data types.

  For most types of TagItems, there are two values that are used.
  One value is used to inform hosts receiving the inquiry that the
  originator would like to have the information unique to that
  TagItem value filled in.  The other value informs hosts receiving
  the inquiry that they should only respond if the data for that
  particular TagItem matches the corresponding data for that host.

  Defined TagItem Tag values

    QUERY_IPADDR = $2000
    MATCH_IPADDR = $2001

    These TagItems are used to identify a host's IP address on a network.
    For this TagItem, ti_Data will contain the responding host's
    IP address.


    QUERY_REALMS = $2002
    MATCH_REALMS = $2003

    These TagItems are used to either find hosts on a physical network
    that are within a logical named Realm, or to query a Realm Server
    for all of the names of the Reamlms it knows about.  The ti_Data
    field is used as an offset to the name of the realm on the inquiry
    data.


    QUERY_HOSTNAME = $2004
    MATCH_HOSTNAME = $2005

    These TagItems are used to identify or match a hostname.  The ti_Data
    field is an offset from the beginning of the Inquiry data to a
    null terminated string for the host's name.


    QUERY_SERVICES = $2006
    MATCH_SERVICE  = $2007


    These TagItems are used to identify or match an NIPC Service name. The
    ti_Data field is an offset from the beginning of the Inquiry data to
    a null terminated string for the Service name.


    QUERY_ENTITY = $2008
    MATCH_ENTITY = $2009

    These TagItems are used to identify or match an NIPC Entity name. The
    ti_Data field is an offset from the beginning of the Inquiry data to
    a null terminated string for the Entity name.


    QUERY_MACHDESC = $200A

    This TagItem is used to query a machine for it's textual description
    as given by the machine's owner. The ti_Data field is an offset from
    the beginning of the Inquiry data to a null terminated string for the
    host's description.


    QUERY_SYSINFO = $200E
    MATCH_SYSINFO = $200F

    This TagItem is used to identify or match system specific parameters
    sych as CPU type, available memory, etc.  The ti_Data field is an
    offset from the beginning of the Inquiry data to a SysInfo structure.
    (Not yet defined).


    QUERY_LIBVERSION = $2010
    MATCH_LIBVERSION = $2011

    This TagItem will be used for identifying or matching a specific
    Amiga shared library that has a specific version.  The ti_Data field
    is an offset from the beginning of the Inquiry data to a LibInfo
    structure (Not yet defined).



			3. NIP BROADCASTS

A NIP query is sent by sending the UDP packet as a series of IP directed
broadcasts to each network within an NIPC Realm.  As an example, if
a Realm named "Software" consisted of two IP networks, such as 137.239.1.0
and 137.239.2.0, the Realm Server would send two UDP broadcasts.  One would
be sent to 137.239.1.255, and the other to 137.239.2.255.  By using directed
broadcasts, NIP allows Realm Servers to control Realms that consist of
networks that they are not physically connected to.

