[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 rfc2834                                        
Network Working Group                                       J.-M. Pittet
INTERNET DRAFT                                     Silicon Graphics Inc.
Expires September 1998                                        March 1998




                  ARP and IP Broadcast over HIPPI-800
                     <draft-pittet-hippiarp-00.txt>



Status of this memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   The ANSI X3T11.1 task force has standardized the encapsulation of
   IEEE 802.2 LLC PDUs [3].  Another X3T11.1 standard [4] describes the
   operation of HIPPI physical switches.  X3T11.1 chose to leave HIPPI
   networking issues largely outside the scope of their standards; this
   document specifies a method for resolving IP addresses to HIPPI
   hardware addresses (HIPARP) and for emulating IP broadcast in a
   logical IP subnet (LIS) as a direct extension of HIPARP.

   Furthermore it is the goal of this memo to define a HIPARP that will
   allow interoperability for HIPPI-800 and HIPPI-6400 (a.k.a. Gigabit
   Systems Network, GSN) equipment both broadcast and non-broadcast
   capable.







Pittet                                                          [Page 1]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


TABLE OF CONTENTS

       1.  Introduction
       2.  Scope
           2.1 Changes from RFC-1374
           2.2 Terminology
       3.  Definitions
           3.1 Global Concepts
           3.2 Glossary
       4.  IP Subnetwork Configuration
           4.1 Background
           4.2 HIPPI LIS Requirements
       5.  HIPPI Address Resolution Protocol - HIPARP
           5.1 HIPARP Algorithm
               5.1.1 HIPARP registration phase
               5.1.2 HIPARP operational phase
           5.2 HIPARP Client Operational Requirements
           5.3 Receiving Unknown HIPARP Packets
           5.4 HIPARP Single Server Operational Requirements
           5.5 HIPARP and Permanent ARP Table Entries
           5.6 HIPARP Table Aging
       6.  HIPARP Message Encoding
           6.1 HIPPI-LE Header of HIPARP Messages
               6.1.1 IEEE 802.2 LLC
               6.1.2 SNAP
               6.1.3 Diagram
           6.2 HIPPI Hardware Address Formats and Requirements
               6.2.1 48-bit Universal LAN MAC Addresses
               6.2.2 I-Field requirements for HIPARP messages
           6.3 HIPARP and InHIPARP Message Formats
               6.3.1 HIPARP_NAK packet format
               6.3.2 Combined HIPPI-LE and HIPARP packet addresses
       7.  Broadcast and Multicast
           7.1 HIPPI IP Broadcast Emulation Server - HIPIBS
           7.2 IP Broadcast Address
           7.3 IP Multicast Address
           7.4 A Note on Broadcast Emulation Performance
       8.  HIPARP for Scheduled Transfer
       9.  Discovery of One's Own Switch Address
           9.1 Switch Address Discovery
       10. Security
       11. Open Issues
       12. HIPARP Examples
           12.1 Registration Phase of Client Y on Non-broadcast Hardware
           12.2 Registration Phase of Client Y on Broadcast Hardware
           12.3 Operational Phase (phase II)
                12.3.1 Standard successful HIPARP_Resolve example
                12.3.2 Standard non-successful HIPARP_Resolve example



Pittet                                                          [Page 2]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


       13. References
       14. Acknowledgments
       15. Author's Address

1. Introduction

   The ANSI High-Performance Parallel Interface (HIPPI) is a dual
   simplex data channel.   HIPPI can send and receive data
   simultaneously at nearly 800 megabits per second.  (HIPPI has an
   equally applicable 1600 megabit/second option.) Between 1987 and
   1997, the ANSI X3T11.1 HIPPI working group standardised five
   documents that bear on the use of HIPPI as a network interface.  They
   cover the physical and electrical specification (HIPPI-PH [1]), the
   framing of a stream of octets (HIPPI-FP [2]), encapsulation of IEEE
   802.2 LLC (HIPPI-LE [3]), the behavior of a standard physical layer
   switch (HIPPI-SC [4]) and the physical-level and optical
   specification (HIPPI-Serial [5]).  HIPPI-LE also implies the
   encapsulation of Internet Protocol[5].  The reader should be familiar
   with the ANSI HIPPI documents. Approved ANSI standards are available
   from ANSI (http://www.ansi.org). The working document of the T11.1
   HIPPI Standards Committee may be obtained from the T11 web page
   (http://www.t11.org/) until they become published standards.

   HIPPI switches can be used to connect a variety of computers and
   peripheral equipment for many purposes, but the working group stopped
   short of describing their use as Local Area Networks.  This memo
   takes up where the working group and RFC-2067 [18] left off and
   defines address resolution and LIS IP broadcast emulation for HIPPI-
   800 networks.

   While investigating possible solutions for HIPARP it became evident
   that IP broadcast could easily be emulated for both HIPPI-800 and
   HIPPI-6400 hardware types. This is useful since HIPPI switches are
   not required to implement broadcast but many standard networking
   protocols rely on broadcast.  This memo therefore further addresses
   the emulation of LIS IP broadcast as an extension of HIPARP.

2. Scope

2.1 Changes from RFC-1374

   RFC-2067 left ARP out of its scope because there was not enough
   implementation experience. This memo is an effort to clarify and
   expand the definition of ARP over HIPPI as found in RFC-1374 such
   that implementations will be more readily possible, especially
   considering forward interoperability with HIPPI-6400.

   The changes from RFC-1374 are:



Pittet                                                          [Page 3]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   o  A new packet format to acknowledge the HIPPI hardware address
      format and to eliminate the requirement of HIPPI-LE ARP for HIPARP
      to function.

   o  Explicit registration phase.

   o  Additional packet formats: InHIPARP requests and replies as
      well as HIPARP_NAKs.

   o  Details about the IP subnetwork configuration.

   o  Details about table aging.

   o  IP broadcast emulation.

2.2 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119.

2.3 Limitations

   This memo defines the address resolution service in the LIS and
   constrains it to consist of a single HIPARP service address.  This
   memo recognizes the possible future development of standards and
   implementations of multiple-HIPARP-server models that will extend the
   operations as defined in this memo to provide a highly reliable
   address resolution service.

3. Definitions

3.1 Global concepts used

   In the following discussion, the terms "requester" and "target" are
   used to identify the node initiating the address resolution request
   and the node whose address it wishes to discover, respectively.  If
   not all switches in the LIS support boadcast then there will be a
   HIPARP server providing the address resolution service and it will be
   the source of the reply. If on the other hand all switches support
   broadcast then the source address of a reply will be the address of
   the target.

   This document uses the terms node, host, etc. when talking about
   destinations of messages. This is not entirely correct in the sense
   that HIPPI addresses or IP addresses which are said to identify such
   an entity actually identify one host adapter within that entity.




Pittet                                                          [Page 4]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   3.2 Glossary

   Classical/Conventional

   Used with respect to networks, this refers to Ethernet, FDDI and 802
   LAN types, as distinct from HIPPI-SC LANs.


   Destination

   The HIPPI implementation that receives data from a HIPPI Source.


   HIPARP

   HIPARP describes the whole set of HIPPI address resolution encodings
   and algorithm defined in this memo. HIPARP is a combination and
   adaptation of the Internet Address Resolution Protocol (ARP) RFC-826
   [15], Inverse ARP (InARP), and Reverse ARP [10] (see section 5).
   HIPARP also describes the HIPPI specific version of ARP [10] (i.e.
   the protocol and the HIPPI specific encoding).


   HIPIBS

   HIPPI IP Broadcast Server (see section 7).


   HIPRAL

   The HIPARP Request Address List (see section 4.2).


   Host

   An entity, ususally a computer system, that may have one or more
   HIPPI nodes and which may serve as a client or a HIPARP server.

   Node

   An entity consisting of one HIPPI Source/Destination dual simplex
   pair that is connected by parallel or serial HIPPI to a HIPPI-SC
   switch and that transmits and receives IP datagrams.  A node may be
   an Internet host, bridge, router, or gateway.  This memo uses the
   term node in place of the usual term "host", to indicate that a host
   might be connected to the HIPPI LAN through an external adaptor that
   does some of the protocol processing for the host (instead of being
   connected directly).



Pittet                                                          [Page 5]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   HIPPI-Serial

   An implementation of HIPPI in serial fashion on coaxial cable or
   optical fiber. (see [5])


   Switch Address

   A value used as the address of a node on a HIPPI-SC network.  It is
   transmitted in the I-field.  HIPPI-SC switches may map Switch
   Addresses to physical port numbers. The switch address is extended
   with a mode byte to form an I-Field (see [4] and 6.2.2)


   Source

   The HIPPI implementation that generates data to send to a HIPPI
   Destination.


   Universal LAN MAC Address (ULA)

   A 48-bit globally unique address, administered by the IEEE, assigned
   to each node on an Ethernet, FDDI, 802 network, or HIPPI- SC LAN.

4.  IP Subnetwork Configuration

4.1 Background

   ARP (address resolution protocol) as defined in [13] was meant to
   work on the 'local' cable. This definition gives the ARP protocol a
   local logical IP subnet (LIS) scope. In the LIS scenario, each
   separate administrative entity configures its hosts and routers
   within the LIS. Each LIS operates and communicates independently of
   other LISs on the same HIPPI network.

   In the classical model, hosts communicate directly via HIPPI to other
   hosts within the same LIS using the HIPARP mechanism described in
   section 5 for resolving target IP addresses to target HIPPI endpoint
   addresses.  HIPARP has LIS scope only and serves all hosts in the
   LIS. Communication to hosts located outside of the local LIS is
   usually provided via an IP router. This router is a HIPPI endpoint
   attached to the HIPPI network that is configured as a member of one
   or more LISs. This configuration MAY result in a number of disjoint
   LISs operating over the same HIPPI network. Using this model, hosts
   of different IP subnets MUST communicate via an intermediate IP
   router even though it may be possible to open a direct HIPPI
   connection between the two IP members over the HIPPI network. This is



Pittet                                                          [Page 6]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   an obvious consequence of using IP and choosing to have multiple
   LIS's on the same HIPPI fabric.

   By default, the HIPARP method detailed in section 5 and the classical
   LIS routing model MUST be available to any IP member client in the
   LIS.

4.2 HIPPI LIS Requirements

   The requirements for IP members (hosts, routers) operating in a HIPPI
   LIS configuration are:

   o  All members of the LIS SHALL have the same IP network/subnet
      and address mask [6].

   o  All members within an LIS SHALL be directly connected to the
      HIPPI network.

   o  All members of an LIS MUST implement the HIPARP mechanism for
      resolving IP addresses to HIPPI addresses as detailed in this memo
      in section 5, "HIPPI Address Resolution Protocol - HIPARP."

   o  All members within an LIS MUST be able to communicate via HIPPI
      with all other members in the same LIS.


   The following list identifies the set of HIPPI-specific parameters
   that MUST be implemented in each IP station connected to the HIPPI
   network:

   o  HIPPI Hardware Address:

      The HIPPI hardware address of an individual IP endpoint (i.e. a
      network adapter within a host) MUST contain a switch address (see
      section 9). The address SHOULD also contain a non-zero ULA
      address. If there is no ULA then that field MUST be zero.

   o  HIPARP Request Address List (HIPRAL):

      The HIPRAL is an ordered list of one or more addresses identifying
      the address resolution service(s). The HIPRAL SHOULD be the same
      for all nodes within a LIS. The HIPRAL MUST contain at least one,
      and MAY contain more than one HIPPI address, identifying the
      individual HIPARP service(s) that have authoritative
      responsibility for resolving HIPARP requests of all IP members
      located within the LIS.  An LIS MUST have at least one HIPARP
      service entry configured and available to all members of the LIS.




Pittet                                                          [Page 7]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


      This memo only defined the behaviour of the address resolution
      service for one entry in the HIPRAL. This memo recognizes the
      future development of standards and implementations of multiple-
      HIPARP-server models that will extend the operations as defined in
      this memo to provide a highly reliable address resolution service.

      Depending on the hardware broadcast capabilities, the address MAY
      be the address for "IP traffic conventionally directed to the IEEE
      802.1 broadcast address: 0xFE1" [4] if every switch in the LIS
      supports this address feature or otherwise the address of a HIPARP
      server.  For example, the HIPARP server address MAY be the
      reserved address for "Messages pertaining to (the) ... address
      resolution requests: 0xFE0 " [4] or any other address identifying
      a HIPARP server.

   In the case where there is only a single HIPRAL address, all HIPARP
   clients MUST be configured identically to have one non-null entry in
   HIPRAL configured with the same address. That identifies the primary
   HIPARP service.

   Within the restrictions mentioned above and in Section 6.2.2, local
   administration MUST choose an address(es) for the HIPARP service
   which they will put into the HIPRAL.

   Manual configuration of the addresses and address lists presented in
   this section is implementation dependent and beyond the scope of this
   memo; i.e. this memo does not require any specific configuration
   method. For all implementations designed in compliance with this
   memo, these addresses MUST be configured completely on the client, as
   appropriate for the LIS, prior to use by any service or operation
   detailed in this memo.

5. HIPPI Address Resolution Protocol - HIPARP

   Address resolution within the HIPPI LIS SHALL make use of the HIPPI
   Address Resolution Protocol (HIPARP) (based on [15]) and the Inverse
   HIPPI Address resolution Protocol (InHIPARP) (based on [7]). HIPARP
   is the same protocol as the Internet Address Resolution Protocol
   (ARP) which is defined in RFC-826 [15] except the HIPPI specific
   packet format. Ethernet, FDDI, and 802 networks use ARP to discover
   another host's hardware address, knowing the Internet address.
   InHIPARP is the same protocol as the original Inverse ARP (InARP)
   protocol presented in [7] except the HIPPI specific packet format.
   InARP is used to discover the other party's Internet address, knowing
   its hardware address.  HIPRARP is the same protocol as reverse ARP
   [10] and is used by a client to discover it's own Internet address,
   from its own hardware address.




Pittet                                                          [Page 8]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   HIPARP presented in this section further specifies the combination of
   these original protocol definitions to form a coherent address
   resolution service that is independent of the harware's broadcast
   capability.

   Internet addresses are assigned independent of ULAs and switch
   addresses.  Each host implementation MUST know its own IP, ULA  and
   switch address (see section 9 "Discovery of One's Own Switch Address"
   for one implementation method) and MUST respond to address resolution
   requests appropriately (see sections 6.2 and 6.3, within "HIPARP
   Message Encodings").  IP members MUST use HIPARP to resolve IP
   addresses to hardware addresses when needed.

   This memo defines the address resolution service in the LIS and
   constrains it to consist of a single HIPARP server.  Client-server
   interaction is defined by using a single server approach as a
   reference model.

   This memo recognizes the future development of standards and
   implementations of multiple-HIPARP-server models that will extend the
   operations as defined in this memo to provide a highly reliable
   address resolution service.

5.1 HIPARP Algorithm

   This section defines the behavior and requirements for host HIPARP
   implementation on both broadcast and non-broadcast capable HIPPI-SC
   networks. HIPARP creates a table in each node that map remote  nodes'
   IP addresses to Switch Addresses and to optional ULAs, so that when
   an application requests a connection to a remote node by its IP
   address, both the Switch Address and the remote ULA can be
   determined, a correct HIPPI-LE header can be built, and a connection
   to the node can be established using the correct Switch Address in
   the I-field.

   HIPARP is a two phase protocol. The first phase is a registration
   phase and the second phase is the operational phase. The operational
   phase works much like conventional ARP with the exception of the
   packet format. The registration phase uses the InARP protocol to
   register and establish a table entry with the server.

5.1.1 HIPARP registration phase

   The HIPARP client is responsible for contacting the HIPARP server to
   have its own IP and HIPPI hardware address information registered.
   HIPARP clients SHALL initiate the registration phase through the
   sending of an InHIPARP_REQUEST message to the primary address in the
   HIPRAL.



Pittet                                                          [Page 9]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   If the HIPPI-SC LAN supports broadcast, then the client will see its
   own InHIPARP_REQUEST packet. The client SHALL complete the
   registration phase after verifying that the InHIPARP_REQUEST contains
   the address information it previously inserted. The client will
   further note that it is connected to a broadcast capable network and
   use this information for table aging and IP broadcast emulation as
   specified in sections 5.4 and 5.6 respectively.

   If on the other hand the client is connected to a non-broadcast
   capable HIPPI-SC network it SHALL await an InHIPARP_REPLY before
   completing the registration phase. This will also provide the client
   with the protocol address by which the HIPARP server is addressable.

5.1.2 HIPARP operational phase

   Once a HIPARP client has completed its registration phase it enters
   the operational phase. In this phase of the protocol, the HIPARP
   client SHALL gain and refresh its own HIPARP table information about
   other IP members through the sending of HIPARP_REQUESTS to the
   primary address in the HIPRAL and the reception of HIPARP_REPLYs. The
   client is fully operational during the operational phase.

   In this phase, the client's behavior is the same for broadcast or
   non-broadcast HIPPI-SC switched networks.

   The target of an address resolution request SHOULD first update its
   address mapping tables with any new information it can find in a
   request. If it is the target node (see table below) it SHALL
   formulate and send a reply packet.  A node is the target of an
   address resolution request if any ONE of the following statements are
   true of the request:

   1.  The node's IP address is in the target protocol address field
       (ar$tpa) of the HIPARP message.

   2.  The node's ULA (if non-zero), is in the ULA part of the Target
       Hardware Address field (ar$tha) of the message.

   3.  The node's switch address is in the Target Switch Address field
       of Target Hardware Address field (ar$tha) of the message (see
       section 6.2.2).

   4.  The node is the primary HIPARP server .

   NOTE: It is strongly RECOMMENDED to have a HIPARP server run on a
   node which has a non-zero ULA.

5.2 HIPARP Client Operational Requirements



Pittet                                                         [Page 10]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   The HIPARP client is responsible for contacting the HIPARP server to
   have its own HIPARP information registered and to gain and refresh
   its own HIPARP entry/information about other IP members. This means,
   as noted above, that HIPARP clients MUST be configured with the
   switch address and optionally the ULA of the HIPARP server in the
   HIPRAL.

   HIPARP clients MUST:

   1.  When an interface is enabled (e.g. "ifconfig <interface> up"),
       the client SHALL send an InHIPARP_REQUEST message to the primary
       address in the HIPRAL. This allows the client to detect a
       broadcast network or this message registers the client with the
       HIPARP server if. The client will either receive its
       InHIPARP_REQUEST on a broadcast capable LIS or an InHIPARP_REPLY.
       The client SHALL await one of the two messages before successfuly
       completing the registration phase and passing into the
       operational phase.

   2.  After successfully completing the registration phase, the clients
       MUST respond to HIPARP_REQUEST and InHIPARP_REQUEST packets, if
       it is the target node.  If an interface has multiple IP addresses
       (e.g., IP aliases)  then the client MUST cycle through all the IP
       addresses and generate an InHIPARP_REPLY for each such address.
       In that case an InHIPARP_REQUEST can have multiple replies.
       (Refer to Section 7, "Protocol Operation" in RFC-1293  [7].)

   3.  Generate and transmit HIPARP_REQUEST packets to the primary
       address in the HIPRAL. It must respond to address resolution
       reply packets appropriately to build/refresh its own client
       HIPARP table entries. All (solicited and unsolicited)
       HIPARP_REPLYs SHALL be used to update and refresh its own client
       HIPARP table entries.

       Explanation: This allows the HIPARP server to update the clients
       when one of its mappings change, similar to what is accomplished
       on Ethernet with gratuitous ARP.

   4.  Generate and transmit InHIPARP_REQUEST packets as needed  and
       process InHIPARP_REPLY packets appropriately (see section 5.1.1
       and 5.6). All InHIPARP_REPLY packets SHALL be used to
       build/refresh its own client HIPARP table entries.  (Refer to
       Section 7, "Protocol Operation" in [7].)

   If the registration phase showed that the underlying network doesn't
   support broadcast, then the client MUST refresh its own HIPARP
   information with the server at least once every 15 minutes through
   the repetition of step 1 or the exchange of other HIPARP traffic with



Pittet                                                         [Page 11]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   the HIPARP server. To decrease the redundant network traffic, his
   timeout SHOULD be reset after each HIPARP_REPLY from the server.
   Explanation: The HIPARP_REQUEST shows the HIPARP server that the
   client is still alive. Receiving a HIPARP_REPLY indicates to the
   client that the server must have seen the HIPARP_REQUEST.


5.3 Receiving Unknown HIPARP Packets

   If a HIPARP client receives a HIPARP message with an operation code
   (ar$op) that it is not coded to support, it MUST gracefully discard
   the message and continue normal operation.  A HIPARP client is NOT
   REQUIRED to return any message to the sender of the unsupported
   message.

5.4 HIPARP Single Server Operational Requirements

   The HIPARP server accepts HIPPI connections from other HIPPI
   endpoints. The HIPARP server expects an InARP_REQUEST from the client
   as first message from the client. The server examines the IP address,
   the switch address, and the ULA of the InARP_REQUEST and adds or
   updates its HIPARP table entry <IP address(es), switch address, ULA>
   as well as the time stamp.

   If the InHIPARP_REQUEST requester's IP address duplicates a table
   entry IP address and the InHIPARP_REQUEST hardware address does not
   match the table entry hardware address, then the table entry SHALL be
   updated to the new mapping (E.g. moving an IP alias). If the
   InHIPARP_REQUEST requester's ULA and switch address pair duplicates a
   ULA and switch address table entry, the IP address SHALL be added to
   the previous IP address(es). (E.g. adding an IP alias). If the ULA
   and switch address match only partially, the information SHALL be
   discarded and no modification to the table is made.

   The server MUST update the HIPARP table entry's timeout for each
   HIPARP_REQUEST. Explanation: if the client is sending HIPARP requests
   to the server, then the server should note that the client is still
   "alive" by updating the timeout on the client's HIPARP table entry.

   The HIPARP server SHOULD send out HIPARP_REPLYs to all HW addresses
   in its table when it undertakes a change of an existing entry in its
   tables. This feature decreases the time of stale entries in the
   clients.

   The following table shows all possible situations at the HIPARP
   server when a HIPARP_REQUEST is received. Since a HIPPI hardware
   address is one unit, it is invalid only to change part of it. Any
   actions marked with (*) indicate that the inactivity timeout SHALL be



Pittet                                                         [Page 12]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   reset.

      +---+-----------+-----------+-----------+-----------------------+
      | # | IP entry  | ULA entry |  Sw addr  |Action                 |
      +---+-----------+-----------+-----------+-----------------------+
      | 1 | duplicate | duplicate | duplicate | *                     |
      | 2 | duplicate | duplicate |    new    |    Not Valid          |
      | 3 | duplicate |    new    | duplicate |    Not Valid          |
      | 4 | duplicate |    new    |    new    | move IP alias,*       |
      | 5 |    new    | duplicate | duplicate | add IP alias to tbl,* |
      | 6 |    new    | duplicate |    new    |   Not Valid           |
      | 7 |    new    |    new    | duplicate |   Not Valid           |
      | 8 |    new    |    new    |    new    | fresh entry, add it,* |
      +---+-----------+-----------+-----------+-----------------------+


5.5 HIPARP and Permanent ARP Table Entries

   An IP station MUST have a mechanism (e.g. manual configuration) for
   determining what permanent entries it has. The details of the
   mechanism are beyond the scope of this memo.  The permanent entries
   allow interoperability with legacy HIPPI adapters which do not yet
   implement dynamic HIPARP and use a table based static ARP. Permanent
   entries are not aged.

5.6 HIPARP Table Aging

   HIPARP table aging MUST be supported since IP addresses, especially
   IP aliases and also interfaces (with their ULA), are likely to move.
   When so doing the mapping in the clients own HIPARP table/cache
   becomes invalid and stale.

   o  HIPARP table entries in client tables are valid for a maximum
      time of 15 minutes.

   o  HIPARP table entries in the server table are valid for a
      maximum time of 20 minutes.

   If a server entry ages beyond 20 minutes without being updated
   (refreshed) by the client, that entry SHALL be deleted from the
   HIPARP server's table.

   When a client HIPARP table entry ages, a HIPARP client MUST
   invalidate the table entry. The client MUST revalidate the entry
   prior to transmitting any non address resolution traffic to the node
   referred to by this entry.

   NOTE: the client is permitted to revalidate a HIPARP table entry



Pittet                                                         [Page 13]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   before it ages, thus restarting the aging time when the table entry
   is successfully revalidated.  The client MAY continue sending traffic
   to the node referred to by this entry while revalidation is in
   progress, as long as the table entry has not aged.

   The client revalidates the entry by querying the address resolution
   service.  If a valid reply is received (e.g. HIPARP_REPLY), the entry
   is updated.  If the address resolution service cannot resolve the
   entry (e.g. HIPARP_NAK, "host not found"), the associated table entry
   is removed.  If the address resolution service is not available (i.e.
   "server failure") the client MUST attempt to revalidate the entry by
   transmitting an InHIPARP_REQUEST to the hardware address of the entry
   in question and updating the  entry on receipt of an InHIPARP_REPLY.
   If the InHIPARP_REQUEST attempt fails to return an InHIPARP_REPLY,
   the associated table entry is removed.

6. HIPARP Message Encoding

   The HIPARP FP header values are to be set as defined in RFC-2067 "IP
   over HIPPI" [18].

6.1 HIPPI-LE Header of HIPARP Messages

   The HIPPI packet format for Internet datagrams shall conform to the
   HIPPI-FP [2] and HIPPI-LE [3] standards.  The length of a HIPPI
   packet, including trailing fill, shall be a multiple of eight octets
   as required by HIPPI-LE.  The HIPPI-LE header fields of HIPARP,
   HIPRARP, and InHIPARP requests and replies SHALL be set to:

   FC (3 bits) shall contain zero unless otherwise defined by local
   administration.

   Double-wide SHALL be set to 0. This memo does not address the
   implications on HIPARP when this bit is set to 1 indicating the
   possibility of a node being able to accept 64-bit HIPPI connections.

   Message_Type SHALL contain  0 to indicate data.  as defined in
   HIPPI-LE.

   There is no HIPARP message corresponding to HIPPI-LE self-address
   discovery; these packets are sent without ULP data as specified in
   HIPPI-LE [3].

   Destination_Switch_Address, in requests, SHALL be the Switch Address
   of the destination node if known, otherwise zero.  In replies, it
   SHALL be the requester's Switch Address.

   Destination_Address_Type SHALL be 2, a 12-bit address. Type 1, source



Pittet                                                         [Page 14]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   routing, is not acceptable in this specification.

   Source_Address_Type SHALL be 2, a 12-bit address. Type 1, source
   routing, is not acceptable in this specification.

   Source_Switch_Address in requests SHALL be the Switch Address of the
   requesting node.  In replies it SHALL be the replying node's Switch
   Address. That is, the switch address of either the target or the
   HIPARP server, depending on whether a LIS supports broadcast or not,
   respectively.

   Destination_IEEE_Address SHALL be the ULA of the destination node, if
   known, otherwise zero.  In replies, it SHALL be the requester's ULA.

   Source_IEEE_Address SHALL be the ULA of the requesting node.  In
   replies it SHALL be the replying node's ULA Address. That is the the
   target's ULA or HIPARP server's ULA, depending on  whether a LIS
   supports broadcast or not, respectively.

6.1.1 IEEE 802.2 LLC

   The IEEE 802.2 LLC Header SHALL begin in the first byte of the
   HIPPI-FP D2_Area.

   The LLC value for SSAP-DSAP-CTL SHALL be 0xAA-AA-03 (3 octets)
   indicates the presence of a SNAP header.

6.1.2 SNAP

   The OUI value for Organization Code SHALL be 0x00-00-00 (3 octets)
   indicating that the following two-bytes is an ethertype.

   The Ethertype value SHALL be set as defined in Assigned Numbers [21]:
   HIPARP = ARP = 2054 ('0806'h), HIPRARP = RARP = 32,821 ('8035'h).

   The total size of the LLC/SNAP header is fixed at 8-octets.

6.1.3 Diagram

             Payload Format for HIPARP/InHIPARP/HIPRARP PDUs:

      31    28        23  21          15        10     7         2   0
      +-----+---------+-+-+-----------+---------+-----+---------+-----+
    0 |      04       |1|0|         000         |      03       |  0  |
      +---------------+-+-+---------------------+---------------+-----+
    1 |                              36                               |
      +-----+-+-------+-----------------------+-----------------------+
    2 |[LA] |W|M_Type |          000          |Requester's Switch Addr|



Pittet                                                         [Page 15]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


      +-----+-+-------+-----------------------+-----------------------+
    3 | D_A_T | S_A_T |          000          | Replyer's Switch Addr |
      +-------+-------+---------------+-------+-----------------------+
    4 |             00 00             |                               |
      +-------------------------------+                               |
    5 |                        Requester's ULA                        |
      +-------------------------------+-------------------------------+
    6 |             [LA]              |                               |
      +-------------------------------+                               |
    7 |                       Destination ULA                         |
      +===============+===============+===============+===============+
    8 |       AA      |      AA       |       03      |       00      |
      +---------------+---------------+---------------+---------------+
    9 |       00      |      00       |        EtherType (2054)       |
      +---------------+---------------+-------------------------------+
   10 |Message octet 0|Message octet 1|Message octet 2| . . .         |
      +---------------+---------------+---------------+---            |
      |                            .  .  .                            |
      +   ------------+---------------+---------------+---------------+
      |         . . . |  octet (n-2)  |  octet (n-1)  |     FILL      |
      +---------------+---------------+---------------+---------------+
   N-1|      FILL     |     FILL      |     FILL      |     FILL      |
      +---------------+---------------+---------------+---------------+

                            HIPPI Packet Format

      Words 0-1:  HIPPI-FP Header
      Words 2-7:  D1 Area (HIPPI-LE Header)
      Words 8-9:  D2 Area (IEEE 802.2 LLC/SNAP)
      Words 10-(N-1):  D2 Area           (HIPARP message)
      (n) is the number of octets in the  HIPARP message.
      +====+ denotes the boundary between D1 and D2 areas.
      [LA] fields are zero unless used otherwise locally.
      Abbreviations:
       "W"      = Double_Wide field        SHALL be 0
       "M_Type" = Message_Type field       SHALL be set according to
                                                    HIPPI-LE
       "D_A_T"  = Destination_Address_Type SHALL be 2
       "S_A_T"  = Source_Address_Type      SHALL be 2
      [FILL] octets complete the HIPPI packet to an even
      number of 32 bit words.  The number of fill octets
      is not counted in the data length.



6.2 HIPPI Hardware Address Formats and Requirements

   For HIPPI-800, the Hardware Address is a 9-byte unit that SHALL



Pittet                                                         [Page 16]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   contain the Switch Address AND the ULA. Since HIPPI-800 doesn't
   require the use of a ULA, its fields MAY be zero. The address length
   is still 9 bytes. See the following diagram for an example of the
   HIPPI Hardware Address in the HIPARP Message:

   31              23              15               7              0
   +---------------+-----------------------------------------------+
   |     ...       |Requester's HIPPI Hardware Address octets 0 - 2|
   +---------------+-----------------------------------------------+
   |        Requester's HIPPI Hardware Address octets 3 - 6        |
   +-------------------------------+-------------------------------+
   | Requester's HW Addr oct 7 - 8 |
   +---------------+---------------+

   In the case of the Requester's HIPPI Hardware Address, the HIPPI
   hardware address is split into Switch address and ULA as follows:

   31              23              15               7              0
   +---------------+-----------------------------------------------+
   |     ...       |Requester's Switch Address 0-2, HW Addr 0 - 2  |
   +---------------+---------------+---------------+---------------+
   | Requester's ULA octets 0 - 3 =   Hardware Addr octets 3 - 6  |
   +---------------+---------------+---------------+---------------+
   | Req's ULA 4-6 = HW Addr 7-8   |
   +---------------+---------------+

   NOTE: In the case of HIPPI-6400, the hardware address is ONLY the 6-
   byte ULA. Therefore the length of the hardware address clearly
   defines which version of HIPPI is being used.

6.2.1 48-bit Universal LAN MAC Addresses

   IEEE Standard 802.1A specifies the Universal LAN MAC Address.  The
   globally unique part of the 48-bit space is administered by the IEEE.
   Each node on a HIPPI-SC LAN should be assigned a ULA.  Multiple ULAs
   may be used if a node contains more than one IEEE 802.2 LLC protocol
   entity.

   The format of the HIPPI hardware address within its HIPARP packet
   follows IEEE 802.1A canonical bit order and HIPPI-FP bit and byte
   order. For example the requester's ULA part of the HIPPI hardware
   address would decompose to:

   31              23              15               7              0
   +---------------+---------------+---------------+---------------+
   |ULA octet 0|L|G|  ULA octet 1  |  ULA octet 2  |  ULA octet 3  |
   +---------------+---------------+---------------+---------------+
   |  ULA octet 4  |  ULA octet 5  |



Pittet                                                         [Page 17]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   +---------------+---------------+

                     Universal LAN MAC Address Format

      L (U/L bit) = 1 for Locally administered addresses, 0 for
      Universal.
      G (I/G bit) = 1 for Group addresses, 0 for Individual.

   The use of ULAs is OPTIONAL, but RECOMMENDED. The use of ULAs is
   REQUIRED if a host wishes to interoperate with HIPPI-6400 units.
   Although ULAs are not used by HIPPI-SC switches, they are helpful for
   HIPPI Switch Address resolution, and for distinguishing between
   multiple logical entities that may exist within one node.  They may
   also be used by bridging devices that replace HIPPI hardware headers
   with the MAC headers of other LANs.  Carrying the ULAs in the HIPPI
   header may simplify these devices, and it may also help if HIPPI is
   used as an interface to some future HIPPI based LAN that uses only
   ULAs for addressing (e.g. HIPPI-6400).

6.2.2 I-Field requirements for HIPARP messages

   The first byte of the I-Field contains mode bits defined in HIPPI-SC
   [4].  For simplicity and feasibility, this byte SHALL be the same for
   all nodes in an LIS. It MAY be a configurable parameter. Consistency
   across ALL the nodes in an LIS MUST be assured through means which
   are beyond the scope of this memo.

   Unless another convention is locally defined for HIPARP requests, the
   I-field Path Selection bits SHOULD be set to binary 01 or 11 (logical
   address mode). Section 6.1, "HIPPI-LE Header of the HIPARP Messages"
   defines the values for the FC, Double-wide and Mesage-type fields.

6.3 HIPARP and InHIPARP Message Formats

   The HIPARP protocols use the same hardware type (ar$hrd), protocol
   type (ar$pro), and operation code (ar$op) data formats as the ARP,
   InARP and RARP protocols [15,7,10]. The location of these three
   fields within the HIPARP packet are in the same byte positions as
   those in conventional ARP, RARP and InARP packets.In addition, HIPARP
   makes use of an additional operation code for ARP_NAK introduced with
   [13].The remainder of the HIPARP/InHIPARP packet format is different
   than the  ARP/InARP packet format defined in [15,7,10] and it is also
   different from the format defined in the first "IP and ARP on HIPPI"
   RFC-1374 [17].


   HIPARP packets SHALL be transmitted with a hardware type code of 1
   (as for Ethernet). Furthermore, HIPARP packets SHALL  be accepted if



Pittet                                                         [Page 18]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   received with hardware type codes of either 1 or 6 (IEEE 802
    networks).

   The HIPARP message has several fields that have the following format
   and values:

   Data sizes and field meaning:
     ar$hrd  16 bits  Hardware type
     ar$pro  16 bits  Protocol type of the protocol fields below
     ar$op   16 bits  Operation code (request, reply, or NAK)
     ar$pln   8 bits  byte length of each protocol address
     ar$rhl   8 bits  requester's HIPPI hardware address length (q)
     ar$thl   8 bits  target's HIPPI hardware address length (x)
     ar$rpa  32 bits  requester's protocol address
     ar$tpa  32 bits  target's protocol address
     ar$rha  qoctets  requester's HIPPI Hardware address
     ar$tha  xoctets  target's HIPPI Hardware address

   Where :
     ar$hrd  - SHALL contain 1. (Ethernet)

     ar$pro  - SHALL contain the IP protocol code 2048 (decimal).

     ar$op   - SHALL contain the operational value (decimal):
               1  for   HIPARP_REQUESTs
               2  for   HIPARP_REPLYs
               3  for  HIPRARP_REPLYs
               4  for  HIPRARP_REPLYs
               8  for InHIPARP_REQUESTs
               9  for InHIPARP_REPLYs
               10 for   HIPARP_NAK

     ar$hln  - SHALL contain 9 IF this is a HIPPI-800 link
               ELSE, for HIPPI-6400, it SHALL contain 6.

     ar$pln  - SHALL contain 4.

     ar$rha  - in requests and NAKs it SHALL contain the requester's ULA
               In replies it SHALL contain the target node's ULA.

     ar$rpa  - in requests and NAKs it SHALL contain the requester's IP
               address if known, otherwise zero.
               In other replies it SHALL contain the target
               node's IP address.

     ar$tha  - in requests and NAKs it SHALL contain the target's ULA
               if known, otherwise zero.
               In other replies it SHALL contain the requester's ULA.



Pittet                                                         [Page 19]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


     ar$tpa  - in requests and NAKs it SHALL contain the
               target's IP address if known, otherwise zero.
               In other replies it SHALL contain the requester's
               IP address.

   The format of the six octets of the ULA SHALL be the same as required
   in the HIPPI-LE header (see section 6.2, "HIPPI Hardware Address
   Formats and Requirements" above), except for the alignment of the
   ULAs with respect to the 32-bit HIPPI word, which is different
   between ARP and HIPPI-LE.  No bit reversal is necessary as is
   required with FDDI.

      31    28        23  21          15        10     7         2   0
      +-----+---------+-+-+-----------+---------+-----+---------+-----+
    0 |      04       |1|0|         000         |      03       |  0  |
      +---------------+-+-+---------------------+---------------+-----+
    1 |                              36                               |
      +-----+-+-------+-----------------------+-----------------------+
    2 |[LA] |W|   1   |          000          |   Dest. Switch Addr   |
      +-----+-+-------+-----------------------+-----------------------+
    3 |   2   |   2   |          000          |Requester's Switch Addr|
      +---------------+---------------+-------+-----------------------+
    4 |             00 00             |                               |
      +-------------------------------+                               |
    5 |                      Destination ULA                          |
      +-------------------------------+-------------------------------+
    6 |             [LA]              |                               |
      +-------------------------------+                               |
    7 |                        Requester's ULA                        |
      +===============+===============+===============+===============+
    8 |       AA      |      AA       |       03      |       00      |
      +---------------+---------------+---------------+---------------+
    9 |       00      |      00       |        EtherType (2054)       |
      +---------------+---------------+-------------------------------+
   10 |            hrd (1)            |           pro (2048)          |
      +---------------+---------------+---------------+---------------+
   11 |             op (ar$op)        |     pln (6)   |   shl (q)     |
      +---------------+---------------+---------------+---------------+
   12 |    thl (x)    |   Requester's IP Address upper  (24 bits)     |
      +---------------------------------------------------------------+
   13 | Src. IP lower |      Target's IP Address upper  (24 bits)     |
      +---------------+-----------------------------------------------+
   14 | Tgt. IP lower |Requester's HIPPI Hardware Address octets 0 - 2|
      +---------------+-----------------------------------------------+
   15 |        Requester's HIPPI Hardware Address octets 3 - 6        |
      +-------------------------------+-------------------------------+
   16 | Requester's HW Addr oct 7 - 8 | Target's HIPPI HW Addr 0 - 2  |
      +---------------+---------------+-------------------------------+



Pittet                                                         [Page 20]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   17 |         Target's  HIPPI Hardware Address octets 2 - 5         |
      +-----------------------------------------------+---------------+
   18 | Target's  HIPPI Hardware Address octets 6 - 8 |
      +-----------------------------------------------+

                     HIPARP - HIPRARP - InHIPARP Packet
     ( using 2 HIPPI-800 addresses )

      +---------------+-----------------------------------------------+
   14 | Tgt. IP lower |     Requester's ULA octets 0 - 2              |
      +---------------+-------------------------------+---------------+
   15 |         Requester's ULA octets 3 - 5          | Tgt ULA oct 0 |
      +-----------------------------------------------+---------------+
   16 |                   Target ULA octets 1 - 4                     |
      +---------------+-----------------------------------------------+
   17 | Tgt ULA oct 5 |
      +---------------+

                     HIPARP - HIPRARP - InHIPARP Packet
     (bottom half with 2 HIPPI 6400 addresses)

6.3.1 HIPARP_NAK packet format

   The HIPARP_NAK packet format is the same as the received
   HIPARP_REQUEST packet format with the operation code set to
   HIPARP_NAK; i.e. the HIPARP_REQUEST packet data is exactly copied for
   transmission with the HIPARP_REQUEST operation code changed to the
   HIPARP_NAK value.  HIPARP makes use of an additional operation code
   for HIPARP_NAK and MUST be implemented.

6.3.2 Combined HIPPI-LE and HIPARP packet addresses

   The combined HIPPI-LE/HIPARP packet contains ten addresses, two for
   the destination and two for the source of the message, three for the
   requester and three for the target:

      Destination Switch Address  (HIPPI-LE)
      Destination ULA             (HIPPI_LE)

      Source Switch Address       (HIPPI-LE)
      Source ULA                  (HIPPI-LE)

      Requester's IP Address      (HIPARP)
      Requester's ULA             (HIPARP)
      Requester's Switch Address  (HIPARP)

      Target's IP Address         (HIPARP)
      Target's ULA                (HIPARP)



Pittet                                                         [Page 21]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


      Target's Switch Address     (HIPARP)

   Examples:

   The following relations are true for a HIPARP_REQUEST and
   InHIPARP_REQUESTs.

      LIS without broadcast -  Dest SW Addr   = HIPARP server SW Addr
      (with HIPARP server)     Dest ULA       = HIPARP server ULA
                               Source SW Addr = Requester's SW Addr
                               Source ULA     = Requester's ULA

      For InHIPARP_REPLYs and HIPARP_REPLYs for instance would be:

      LIS without broadcast  -  Dest SW Addr= Requester's SW Addr
      (with HIPARP server)      Dest ULA = Requester's ULA
                                Source SW Addr = HIPARP server SW Addr
                                Source ULA  = HIPARP server ULA

   Note that the use of ULAs with HIPPI is not required.  In both the
   HIPPI-LE header and the HIPARP message, the fields that contain ULAs
   SHOULD be set to zero if the ULA is not known.

7  Broadcast and Multicast

   HIPPI-SC does not require switches to support broadcast. Broadcast
   support has therefore been absent from many HIPPI networks. However,
   a centralized HIPARP server architecture solves two of the three
   major duties of a broadcast server.

   A central entity serving the whole LIS solves the coordination
   problem of a distributed approach. The registration requirement
   solves the second problem of determining which addresses make up the
   set loosely called "everyone". The last duty of a broadcast server is
   to replicate an incoming packet and send it to "everyone".

   During its registration phase, every node, including the node which
   has the same hardware address as the primary address in the HIPRAL
   and which is therefore the HIPARP server,  discovers if the
   underlying medium is capable of broadcast (see section 5.1.1). Should
   this not be the case, then it makes sense for the HIPARP server to
   emulate broadcast through an IP broadcast emulation server.

   A HIPPI IP broadcast server (HIPIBS) is an extension to the HIPARP
   server and only makes sense when the LIS does not inherently support
   broadcast. The HIBIS is optional and MAY be implemented.

7.1 HIPPI IP Broadcast Emulation Server - HIPIBS



Pittet                                                         [Page 22]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   To emulate broadcast within an LIS, a HIPIBS SHALL use the currently
   valid HIPARP table of the HIPARP server as a list of addresses called
   the target list. The broadcast server SHALL validate that all
   incoming packets have a source address which corresponds to an
   address in the target list. Non-valid packets SHALL be dropped and a
   warning flag MAY be raised with the system administrator. All valid
   packets shall be forwarded to all addresses in the target list.

   It is RECOMMENDED that the broadcast server run on the same node as
   the HIPARP server since this memo does not define the protocol of
   exchanging the valid HIPARP table.

7.2 IP Broadcast Address

   HIPPI-SC supports broadcast addressing, defined in section 4.2,
   "Reserved Logical Addresses". It is RECOMMENDED to pair the HIPARP
   server addresses in the HIPRAL (see section ) with a corresponding
   broadcast address. The default broadcast address SHALL be 0xFE1 as
   described in HIPPI-SC as being the address used for "All IP protocol
   traffic conventionally directed  to the IEEE 802.1 broadcast address
   as described in  RFC-1042".

   This memo defines the IP broadcast emulation service in the LIS and
   constrains it to consist of a single IP broadcast server.  Client-
   server interaction is defined by using a single server approach as a
   reference model.

   This memo recognizes the possibility of future development of
   standards and implementations of multiple-IP-broadcast-server models
   that will extend the operations defined in this memo in order to
   provide a highly reliable broadcast service.

7.3 IP Multicast Address

   HIPPI does not directly support IP multicast address services,
   therefore there are no mappings available from IP multicast addresses
   to HIPPI multicast services.  Current IP multicast implementations
   (i.e. MBONE and IP tunneling, see [9]) will continue to operate over
   HIPPI-based logical IP subnets if all IP multicast addresses are
   mapped to the address of the primary broadcast emulation server.

7.4 A Note on Broadcast Emulation Performance

   It is obvious that a broadcast emulation service (as defined in
   section 7.1) is an inherent performance bottleneck. In an LIS with n
   hosts, the upper bound on the bandwidth that such a service can
   broadcast is:
                          (total bandwidth)/(n+1)



Pittet                                                         [Page 23]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   since each packet must first enter the broadcast server, accounting
   for the additional 1, and then be sent to all n hosts. The broadcast
   server could forward the packet destined to the node on which it
   runs, thus internally reducing (n+1) to (n) in a first optimization.
   The point is that such a service works for the standard networking
   protocols such as RIP, OSPF, NIS, NFS, etc. since they usually
   represent a small fraction of the network bandwidth. For all general
   purposes, the broadcast emulation server as defined in this memo
   allows the HIPPI network to look similar to an Ethernet network to
   the higher layers.

   It is further obvious that such an emulation cannot be used to
   broadcast high bandwidth traffic. For such a solution, hardware
   support for true broadcast, implemented in a distributed fashion
   inside the individual switches, is required.

8 HIPARP for Scheduled Transfer

   This RFC also applies for resolving addresses used with Scheduled
   Transfer (ST) over  HIPPI-800 instead of IP. This RFC's message types
   and algorithms can  be used for ST (since ST uses Internet Addresses)
   as long as there is also an IP over HIPPI implementation on all the
   hosts.

9 Discovery of One's Own Switch Address

   This HIPARP specification assumes that each node has prior knowledge
   of its own switch address.  This may be manually configured, by means
   that are outside the scope of this memo.  If a broadcast capability
   exists, the node may discover its own address automatically when it
   starts up, using a protocol defined in HIPPI-LE.

   If on the other hand, one can not rely on the underlying hardware to
   support broadcast, then a node may discover its own logical address
   through the algorithm described in section 9.1.

9.1 Switch Address Discovery

   Nodes are NOT REQUIRED to implement this protocol but are encouraged
   to do so since it reduces the administrative overhead of systems
   administration.

   If a node implements this feature it SHALL form a HIPPI-LE message as
   defined in HIPPI-LE: containing an AR_S_Request Message Type, and
   where  the Source_IEEE_Address and Destination_IEEE_Address are set
   to the correct ULA for the sender, and the Source_Switch_Address and
   Destination_Switch_Address contain zero.




Pittet                                                         [Page 24]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   This self address resolution message uses the same HIPPI-LE message
   format as described in HIPPI-SC and HIPPI-LE: the AR_S_Request and
   AR_S_Response message type codes and no piggybacked ULP data.  The
   HIPPI-LE header contents for the request are:

      HIPPI-LE Message_Type is            = 3, AR_S_Request
      HIPPI-LE Destination_Address_Type   = 0 (undefined)
      HIPPI-LE Destination_Switch_Address = 0 (unknown)
      HIPPI-LE Source_Address_Type        = 0 (undefined)
      HIPPI-LE Source_Switch_Address      = 0 (unknown)
      HIPPI-LE Destination_IEEE_Address   = my ULA
      HIPPI-LE Source_IEEE_Address        = my ULA

   There is no D2 data; the packet contains only the HIPPI-FP header and
   D1_Area containing the HIPPI-LE header.

   HIPPI-LE leaves the target of such an address outside its scope. This
   memo defines that nodes SHALL start with the HIPPI broadcast address
   0xFE1 and if no reply is received, SHALL continue with the logical
   address of START ( e.g. 0x000) and increment the value by one each
   subsequent try. The node SHALL try until reaching 0xFFF or until it
   sees its own address resolution request. It is RECOMMENDED to make
   the starting address of the previous scan a configurable parameter
   for the network since some networks have equipment that does not
   gracefully drop HIPPI-LE packets that it cannot decode. HIPPI-LE
   section 7.1 HIPPI Address Resolution Overview:

   "After a host sends the[se] request[s], two positive outcomes are
   possible:

   o  the host receives its own request, and obtains its own Switch
      Address from the CCI passed up from the underlying HIPPI-FP
      layer, or
   o  the host receives an AR_S_Response with the
      Destination_Switch_Address filled in.

   In the first case the host should not respond to its own request."

   Or it receives a broadcast copy of its own message, and learns its
   own switch address from the destination address field of the
   received I-field.

10 Security

   Not all of the security issues relating to ARP over HIPPI are clearly
   understood at this time.

   There are known security issues relating to host impersonation via



Pittet                                                         [Page 25]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   the address resolution protocols used in the Internet [8].  No
   special security mechanisms have been added to the address resolution
   mechanism defined here for use with networks using HIPARP.

11 Open Issues

   o  Synchronization and coordination of multiple HIPARP servers and
      multiple broadcast servers are left for further study.

   o  HIPARP packets are not authenticated.  This is a potentially
      serious flaw in the overall system by allowing a mechanism by
      which corrupt information may be introduced into the server
      system.

12 HIPARP Examples

   Assume a HIPPI-SC switch is installed with three connected nodes: X,
   Y, and a.  Each node has a unique hardware address that consists of
   Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and
   ULAa, respectively). There is a HIPARP server connected to a switch
   port that is mapped to the address HWa (SWa, ULAa), this address is
   the primary HIPPI hardware address in the HIPRAL (HIPARP Request
   Address List).

   The HIPARP server's table is empty. Nodes X and Y each know their own
   hardware address.  Eventually they want to talk to each other; each
   knows the other's IP address (from the host database) but neither
   knows the other's ULA or Switch Address. Both nodes X and Y have
   their interfaces configured DOWN.

   Note: The LLC, SNAP, Ethertype, HIPPI-LE Message Type, ar$hrd,
   ar$pro,
         ar$pln fields are left out from the examples below since they
         are constant. As well as ar$shl = ar$thl = 9 since these are
   all
         HIPPI-800 examples.

12.1 Registration Phase of Client Y on Non-broadcast Hardware

   Node Y starts: its HIPARP table entry state for the server: PENDING

   1.  Node Y initiates its interface and sends an InHIPARP_REQUEST to
       the HIPARP server after starting a table entry for the HIPARP
       server.

          HIPPI-LE Destination_Switch_Address = SWa
          HIPPI-LE Source_Switch_Address      = SWy
          HIPPI-LE Destination_IEEE_Address   = ULAa



Pittet                                                         [Page 26]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


          HIPPI-LE Source_IEEE_Address        = ULAy
          HIPARP ar$op                        = 8 (InHIPARP_request)
          HIPARP ar$rpa                       = IPy
          HIPARP ar$tpa                       = 0 **
          HIPARP ar$rha                       = SWy ULAy
          HIPARP ar$tha                       = SWa ULAs
          ** is what we would like to find out

   2.  HIPARP server receives Y's InHIPARP_REQUEST, it examines the
       source addresses and scans its tables for a match. Since this is
       the first time Y connects to this server there is no entry and
       one will be created and time stamped with the information from
       the InHIPARP_REQUEST. The HIPARP server will then send a
       InHIPARP_REPLY including its IP address.

       HIPPI-LE Destination_Switch_Address = SWy
       HIPPI-LE Source_Switch_Address      = SWa
       HIPPI-LE Destination_IEEE_Address   = ULAy
       HIPPI-LE Source_IEEE_Address        = ULAs
       HIPARP ar$op                        = 9 (InHIPARP_REPLY)
       HIPARP ar$rpa                       = IPs *
       HIPARP ar$tpa                       = IPy
       HIPARP ar$rha                       = SWa ULAs
       HIPARP ar$tha                       = SWy ULAy
       * answer we were looking for

   3.  Node Y examines the incoming InHIPARP_REPLY, completes its table
       entry for the HIPARP server. The client's HIPARP table entry for
       the server now passes into the VALID state and is usable for
       regular HIPARP traffic. Receiving this reply ensures that the
       HIPARP server has properly registered the client.

12.2 Registration Phase of Client Y on Broadcast Capable Hardware

   If there is a broadcast capable network then the primary address in
   the HIPRAL would be the broadcast address, HWb = SWb, ULAb (likely
   0xFE1 and FF.FF.FF.FF.FF.FF).

   Node Y starts: its HIPARP table entry state for the primary address
   in the HIPRAL: PENDING

   1.  Node Y initiates its interface and sends an InHIPARP_REQUEST to
       the primary address in the HIPRAL, in this example the
       broadcast address, after starting a table entry.

       HIPPI-LE Destination_Switch_Address = SWb
       HIPPI-LE Source_Switch_Address      = SWy
       HIPPI-LE Destination_IEEE_Address   = ULAb



Pittet                                                         [Page 27]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


       HIPPI-LE Source_IEEE_Address        = ULAy
       HIPARP ar$op                        = 8 (InHIPARP_REQUEST)
       HIPARP ar$rpa                       = IPy
       HIPARP ar$tpa                       = 0 **
       HIPARP ar$rha                       = SWy ULAy
       HIPARP ar$tha                       = SWb ULAb
       ** is what we would like to find out

   2.  Since the network is a broadcast network, client Y will see an
       InHIPARP_REQUEST, it examines the source addresses. Since they
       are the same as what Y filled in the InHIPARP_REQUEST, Y can
       deduce that it is connected to a broadcast medium.  Node Y
       completes its table entry for the primary address of the
       HIPRAL. This entry will not timeout since it is considered less
       than likely for a particular underlying hardware type to loose
       its quality of being able to do broadcast and therefore this
       mapping will never change.


   12.3 Operational Phase (phase II)

   The Operational Phase of the HIPARP protocol as specified in this
   memo is the same for both possibilities of a broadcast and non-
   broadcast capable HIPPI hardware. The primary address in the HIPRAL
   for this example section will be HWa: <SWa, ULAa> amd IPs for
   simplicity reasons.

12.2.1  Standard successful HIPARP_Resolve example

   Assume the same process (steps 1-3 of section 10.1) happened for host
   X. Then the state of X and Y's tables is: the HIPARP server table
   entry is in the VALID state. So lets look at the packet traffic when
   X tries to send a packet to Y. Since X doesn't have an entry for Y,

   1.  node X connects to the primary address of the HIPRAL and sends
       a HIPARP_REQUEST for Y's hardware address:

       HIPPI-LE Destination_Switch_Address = SWa
       HIPPI-LE Source_Switch_Address      = SWx
       HIPPI-LE Destination_IEEE_Address   = ULAa
       HIPPI-LE Source_IEEE_Address        = ULAx
       HIPARP ar$op                        = 1  (HIPARP_REQUEST)
       HIPARP ar$rpa                       = IPx
       HIPARP ar$tpa                       = IPy
       HIPARP ar$rha                       = SWx ULAx
       HIPARP ar$tha                       = 0 **
       ** is what we would like to find out




Pittet                                                         [Page 28]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   2.  The HIPARP server receives the HIPARP request and updates its
       entry for X if necessary. It then generates a HIPARP_REPLY with
       Y's hardware address information.

       HIPPI-LE Destination_Switch_Address = SWx
       HIPPI-LE Source_Switch_Address      = SWa
       HIPPI-LE Destination_IEEE_Address   = ULAx
       HIPPI-LE Source_IEEE_Address        = ULAa
       HIPARP ar$op                        = 2  (HIPARP_Reply)
       HIPARP ar$rpa                       = IPy
       HIPARP ar$tpa                       = IPx
       HIPARP ar$rha                       = SWy ULAy *
       HIPARP ar$tha                       = SWx ULAx
       * answer we were looking for

   7.  Node X connects to node Y and transmits an IP packet with the
       following information in the HIPPI-LE header:

       HIPPI-LE Destination_Switch_Address = SWy
       HIPPI-LE Source_Switch_Address      = SWx
       HIPPI-LE Destination_IEEE_Address   = ULAy
       HIPPI-LE Source_IEEE_Address        = ULAx

   If there had been a broadcast capable HIPPI network, the target nodes
   would themselves have received the HIPARP_REQUEST of step 2 above
   and responded to them in the same way the HIPARP server did.

   12.3.2 Standard non-successful HIPARP_Resolve example

   Like in 12.3.1, assume that X and Y are fully registered with the
   HIPARP server. Then the state of X and Y's HIPARP server table entry
   is: VALID. So
   lets look at the packet traffic when X tries to send a packet to
   Q. Further assume that interface Q is NOT configured UP, i.e. it is
   DOWN.  Since X doesn't have an entry for Q,

   1.  node X connects to the HIPARP server switch address and sends
       a HIPARP_REQUEST for Q's hardware address:

       HIPPI-LE Destination_Switch_Address = SWa
       HIPPI-LE Source_Switch_Address      = SWx
       HIPPI-LE Destination_IEEE_Address   = ULAa
       HIPPI-LE Source_IEEE_Address        = ULAx
       HIPARP ar$op                        = 1  (HIPARP_REQUEST)
       HIPARP ar$rpa                       = IPx
       HIPARP ar$tpa                       = IPq
       HIPARP ar$rha                       = SWx ULAx
       HIPARP ar$tha                       = 0 **



Pittet                                                         [Page 29]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


   q    ** is what we would like to find out

   2.  The HIPARP server receives the HIPARP request and updates its
       entry for X if necessary. It then looks up IPq in its tables
       and doesn't find it. The HIPARP server then generates a
       HIPARP_NAK reply packet.

       HIPPI-LE Destination_Switch_Address = SWx
       HIPPI-LE Source_Switch_Address      = SWa
       HIPPI-LE Destination_IEEE_Address   = ULAx
       HIPPI-LE Source_IEEE_Address        = ULAa
       HIPARP ar$op                        = 10  (HIPARP_NAK)
       HIPARP ar$rpa                       = IPx
       HIPARP ar$tpa                       = IPy
       HIPARP ar$rha                       = SWx ULAx
       HIPARP ar$tha                       = 0 ***
       *** No Answer, and notice that the fields do not get swapped,
           i.e. the HIPARP message is the same as the HIPARP_REQUEST
           except for the operation code.

   If there had been a broadcast capable HIPPI network, then there
   would not have been any reply.


13 References

[1]  ANSI X3.183-1991, High-Performance Parallel Interface -
     Mechanical, Electrical and Signaling Protocol Specification;
     ISO/IEC 11518-1:1995, High-Performance Parallel Interface -
     Part 1: Mechanical, Electrical, and Signalling Protocol
     Specification (HIPPI-PH).

[2]  ANSI X3.210-1992, High-Performance Parallel Interface - Framing
     Protocol; ISO/IEC 11518-2:1995 High-Performance Parallel Interface
     - Part 2: Framing Protocol (HIPPI-FP).

[3]  ANSI X3.218-1993, High-Performance Parallel Interface -
     Encapsulation of of ISO 8802-2 (IEEE Std 802.2) Logical Link
     Control Protocol Data Units (802.2 Link Encapsulation);
     ISO/IEC 11518-3:1995 High-Performance Parallel Interface -
     Part 3: Encapsulation of ISO/IEC 8802-2 Logical link control
     protocol data units(HIPPI-LE).

[4]  ANSI X3.222-1997, High-Performance Parallel Interface - Physical
     Switch Control; ISO/IEC 11518-6:199x High-Performance Parallel
     Interface - Part 6: Physical Switch Control (HIPPI-SC).

[5]  ANSI X3.300-1997, High-Performance Parallel



Pittet                                                         [Page 30]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


     Interface -  Serial Specification, ISO/IEC 11518-6:199x
     High-Performance Parallel Interface -
     Part 8: Serial Specification (HIPPI-Serial)

[6]  Braden, R., "Requirements for Internet Hosts -- Communication
     Layers", RFC-1122, USC/Information Sciences Institute, October
     1989.

[7]  Bradely, T., and Brown, C., "Inverse Address Resolution
     Protocol", RFC-1293, USC/Information Sciences Institute, January
     1992.

[8]  Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
     Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp.
     32-48, 1989.

[9]  Deering, S, "Host Extensions for IP Multicasting", RFC-1112,
     USC/Information Sciences Institute, August 1989.

[10] Finlayson, R., Mann, T., Mogul, J., and  Theimer, M., "A Reverse
     Address Resolution Protocol", RFC-903, Stanford University, June
     1984.

[11] IEEE, "IEEE Standards for Local Area Networks: Logical Link
     Control", IEEE, New York, New York, 1985.

[12] IEEE, "IEEE Standards for Local Area Networks: Logical Link
     Control", IEEE, New York, New York, 1985.

[13] Laubach, Mark., "Classical IP and ARP over ATM", RFC-1577,
     Hewlett-Packard Laboratories, January 1994

[14] Mogul, J.C., and Deering, S.E., "Path MTU Discovery", RFC-1191,
     Stanford University, November, 1990.

[15] Plummer, D., "An Ethernet Address Resolution Protocol - or -
     Converting Network Addresses to 48-bit Ethernet Address for
     Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.

[16] Postel, J., "Internet Protocol", STD 5, RFC-791, USC/Information
     Sciences Institute, September 1981.

[17] Renwick, J., Nicholson, A., "IP and ARP on HIPPI", RFC-1374,
     Cray Research, Inc., October 1992.

[18] Renwick, J., "IP over HIPPI", RFC-2067, NetStar, Inc., January
     1997.




Pittet                                                         [Page 31]


INTERNET DRAFT    ARP and IP Broadcast over HIPPI 800       Expires 9/98


[20] Reynolds, J.K., and Postel, J., "Assigned Numbers", STD 2, RFC-
     1340, USC/Information Sciences Institute, July 1992.

[21] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
     RFC-1700, USC/Information Sciences Institute, October 1994.

14 Acknowledgments

   This memo could not have come into being without the critical review
   from Greg Chesson, Carlin Otto, the High performance interconnect
   group of Silicon Graphics and the expertise of the ANSI T11.1 Task
   Group responsible for the HIPPI standards work.

   This memo is based on the second part of [17], written by John
   Renwick. ARP [15] written by Dave Plummer and Inverse ARP [7] written
   by Terry Bradley and Caralyn Brown provide the fundamental algorithms
   of HIPARP as presented in this memo. Further, the HIPARP server is
   based on concepts and models presented in [13], written by Mark
   Laubach who laid the structural groundwork for the HIPARP server.

15 Author's Address

   Jean-Michel Pittet
   Silicon Graphics Inc
   2011 N. Shoreline Ave
   Mountain View, CA 94040

   Phone: 650-933-6149
   Fax:650-933-3542
   EMail: jmp@sgi.com





















Pittet                                                         [Page 32]