Network Working Group J.-M. Pittet INTERNET DRAFT Silicon Graphics Inc. Expires September 1998 March 1998 ARP and IP Broadcast over HIPPI-800 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 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 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: 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]