Network Working Group J.-M. Pittet INTERNET DRAFT Silicon Graphics Inc. Expires March 1999 September 1998 IP and ARP over HIPPI-6400 (GSN) 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 T11.1 task force has standardized the encapsulation of IEEE 802.2 LLC PDUs [3] and by implication, IP on GSN. Another T11.1 standard [4] describes the Operation of HIPPI-6400 physical switches. T11.1 chose to leave HIPPI-6400 networking issues largely outside the scope of their standards; this document specifies the use of HIPPI- 6400 switches as IP local area networks. This document further specifies a method for resolving IP addresses to HIPPI-6400 hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable. Pittet [Page 1] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 TABLE OF CONTENTS 1. Introduction 2. Definitions 2.1 Global concepts used 2.2 Glossary 3. IP Subnetwork Configuration 3.1 Background 3.2 HIPPI LIS Requirements 3.3 Selecting and changing primary HRAL address and HARP server 4. Internet Protocol 4.1 Packet Format 4.1.1 IEEE 802.2 LLC 4.1.2 SNAP 4.1.3 Packet diagrams 4.2 HIPPI-6400 Hardware address: Universal LAN MAC address (ULA) 4.3 MTU 5. HIPPI Address Resolution Protocol - HARP 5.1 HARP Algorithm 5.1.1 HARP registration phase 5.1.2 HARP operational phase 5.2 HARP Client Operational Requirements 5.3 Receiving Unknown HARP Messages 5.4 HARP Server Operational Requirements 5.5 HARP and Permanent ARP Table Entries 5.6 HARP Table Aging 6. HARP Message Encoding 6.1 HARP and InHARP Message Formats 6.2 Example Message encodings: 6.3 HARP_NAK message format 7. Broadcast and Multicast 7.1 Protocol for an IP Broadcast Emulation Server - PIBES 7.2 IP Broadcast Address 7.3 IP Multicast Address 7.4 A Note on Broadcast Emulation Performance 8. HARP for Scheduled Transfer [22] 9. Security 10. Open Issues 11. Bridging 11.1 Server Behaviour in the presence of a Bridge. 11.1.1 ARP Message from Bridge to Server 11.1.2 Message to Bridge 11.1.2.1 ARP Request to Bridge 11.1.2.2 ARP Reply to Bridge 11.2 Bridge Behaviour 11.2.1 Message from HIPPI to Bridge 11.2.2 Message from Ethernet/Other to Bridge 12. HARP Examples Pittet [Page 2] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 12.1 Registration Phase of Client Y on Non-broadcast Hardware 12.2 Registration Phase of Client Y on Broadcast Capable Hardware 12.3 Operational Phase (phase II) 12.2.1 Standard successful HARP_Resolve example 12.3.2 Standard non-successful HARP_Resolve example 13. References 14. Acknowledgments 15. Author's Address 1. Introduction HIPPI-6400 is a duplex data channel that can transmit and receive data simultaneously at nearly 6400 megabits per second. HIPPI-6400 data transfers are cut up into micropackets which is composed of 32 data bytes and 64 bits of control information. HIPPI-6400 uses four multiplexed virtual channels. These virtual channels are allocated to control traffic, low latency traffic, and bulk traffic. Using small packets and the virtual channels make that very large file transfers can not lock out a host or switch port for interactive traffic. Link control and look ahead flow control is done with Admin-micropackets that have the same size as data micropackets HIPPI-6400 guarantees in order delivery of data at full data speed. It also supports link-level end to end checksumming and credit based flow control. HIPPI-6400 defines a 20-bit interface for either copper or fiber- optic cables operating at 500 Mhz. It has a raw bandwidth of 10'000 Mb/s in each direction. This provides a payload bandwidth of 6400 Mb/s in each direction after subtracting the overheads of ac-encoding and control information. [Greg] Gigabit Systems Network (GSN) is the High-performance Networking Forum (HNF; http://www.hnf.org) name for the equipments complying to ANSI High Performance Parallel Interface HIPPI-6400 series of standards. 2 Definitions 2.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. Pittet [Page 3] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 2.2 Glossary Broadcast A distribution mode which transmits a message to all nodes. Particularly also the node sending the message. Classical/Conventional Both terms are used with respect to networks, including Ethernet, FDDI, and other 802 LAN types, as distinct from HIPPI-SC LANs. Destination The HIPPI-6400 node that receives data from a HIPPI-6400 Source. HARP HARP describes the whole set of HIPPI-6400 address resolution encodings and algorithms defined in this memo. HARP is a combination and adaptation of the Internet Address Resolution Protocol (ARP) RFC-826 [15] and Inverse ARP (InARP) [7] (see section 5). HARP also describes the HIPPI (800 and 6400) specific version of ARP [10] (i.e. the protocol and the HIPPI specific encoding). HRAL The HARP Request Address List (see section 3.2). HW address The hardware address consisting of an ULA (see section 4.2) Host An entity, usually a computer system, that may have one or more HIPPI nodes and which may serve as a client or a HARP 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 Pittet [Page 4] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 switch and that transmits and receives IP datagrams. A node may be an Internet host, bridge, router, or gateway. PIBES The Protocol for Internet Broadcast Emulation Server (see section 7). Source The HIPPI node 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. 3. IP Subnetwork Configuration 3.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-6400 network. HARP has LIS scope only and serves all nodes in the LIS. Communication to nodes located outside of the local LIS is usually provided via an IP router. This router is a HIPPI-6400 node attached to the HIPPI-6400 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-6400 network. Using this model, nodes of different IP subnets MUST communicate via an intermediate IP router even though it may be possible to open a direct HIPPI-6400 connection between the two IP members over the HIPPI-6400 network. This is an consequence of using IP and choosing to have multiple LIS's on the same HIPPI-6400 fabric. By default, the HARP method detailed in section 5 and the classical LIS routing model MUST be available to any IP member client in the LIS. 3.2 HIPPI LIS Requirements Pittet [Page 5] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 The requirements for IP members (hosts, routers) operating in a HIPPI-6400 LIS configuration are: o All members of the LIS SHALL have the same IP network/subnet address and address mask [6]. o All members within an LIS SHALL be directly connected to the HIPPI-6400 network. o All members of an LIS MUST implement the HARP mechanism for resolving IP addresses to HIPPI-6400 addresses as detailed in this memo in section 5, "HIPPI Address Resolution Protocol - HARP." o All members within an LIS MUST be able to communicate via HIPPI-6400 with all other members in the same LIS. The following list identifies the set of HIPPI-6400-specific parameters that MUST be implemented in each IP station connected to the HIPPI-6400 network: o HIPPI-6400 Hardware Address: The HIPPI-6400 hardware address (a ULA) of an individual IP endpoint (i.e. a network adapter within a host) MUST be unique in the whole LIS. o HARP Request Address List (HRAL): The HRAL is an ordered list of one or more addresses identifying the address resolution service(s). The HRAL MUST be the same for all nodes within a LIS. The HRAL MUST contain at least one, and MAY contain more than one HIPPI-6400 address, identifying the individual HARP service(s) that have authoritative responsibility for resolving HARP requests of all IP members located within the LIS. An LIS MUST have at least one HARP service entry configured and available to all members of the LIS. By default the first address SHOULD be the reserved address for broadcast FF:FF:FF:FF:FF:FF. It MAY be another address if there are some local requirements that do not allow the System Administrators to configure the HIPPI-6400-SC switches to map FF:FF:FF:FF:FF:FF to the local broadacst address or HARP server should broadcast not be supported in the whole HIPPI-6400 network. All HARP clients MUST be configured identically to have the same address. Which identifies the primary HARP service. Pittet [Page 6] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 It is RECOMENDED that systems ship with the FF:FF:FF:FF:FF:FF address in the HRAL. Should the particular HIPPI-6400 network NOT support broadcast then the System administrator SHOULD add the all FF address to the port in a switch which has a HARP complient host attached. 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. 3.3 Selecting and changing primary HRAL address and HARP server At each point in time there is only one primary HARP server in the LIS. If the HRAL only has one entry then the node holding that address is the primary HARP server. If the HRAL has multiple entries, then the node that has the highest address in the HRAL and which is responsive is the primary HARP server. A HARP server is considered non-responsive when it has failed to reply to any of 6 registration requests by the client (see section 5.1.1 and 5.2), any two HARP_REQUESTs in the last 120 seconds or if an external agent has detected failure of the primary HARP server. The details of such an external agent and its interaction with the HARP client are beyond the scope of this document. Should a primary HARP server turn out to be non-responsive, then the next candidate from the HRAL will become the primary HARP server. If any of the addresses in the HRAL are broadcast addresses, then that address is the primary address of the LIS. The primary HARP server is the node identified by the primary HRAL address. 4. Internet Protocol 4.1 Packet format The HIPPI-6400 packet format for Internet datagrams shall conform to the HIPPI-6400-PH standard (see section 7 "Message structure" of []). The length of a HIPPI-6400-PH packet, including headers and trailing fill, shall be a multiple of 32 octets as required by HIPPI-6400-PH. ALL IP Datagrams shall be carried on HIPPI-6400-PH Virtual Channel 1 Pittet [Page 7] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 (VC1). Since HIPPI-6400-PH has a 32-byte granularity, IP Datagrams must also provide the data payload with a 32-byte granylarity. If a user's data is not an integral multiple of 32-byte units, then the nescessary padding SHALL be added. D_ULA Destinatio ULA SHALL be the ULA of the destination node. S_ULA Source ULA SHALL be the ULA of the requesting node. M_len Set to the IEEE 802 packet (e.g. IP or HARP message) length + 8 Bytes to account for the LLC/SNAP header length. The HIPPI-6400-PH length ameter shall not include the pad. 4.1.1 IEEE 802.2 LLC The IEEE 802.2 LLC Header SHALL begin in the first byte after M_len. The LLC values SHALL be SSAP 0xAA 170 (8 bits) DSAP 0xAA 170 (8 bits) CTL 0x03 3 (8 bits) for a total length of 3 octets. The 0x03 CTL value indicates the presence of a SNAP header. 4.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 [22]: IP 0x0800 2048 (16 bits) HARP = ARP = 0x0806 2054 (16 bits) The total size of the LLC/SNAP header is fixed at 8-octets. 4.1.3 Packet diagrams The following diagram shows a generic IEEE 802 packet. "<><>" indicates the micropacket separation. A HIPPI-6400-PH micropacket is 32 octets long. |31 |23 |15 |7 0| +------------+------------+------------+------------+ -------------- Pittet [Page 8] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 0 | | | D_ULA +-------------------------+ HIPPI-6400 1 | | | +-------------------------+ S_ULA | MAC 2 | | +---------------------------------------------------+ header 3 | M_len | +------------+------------+------------+------------+ -------------- 4 | DSAP | SSAP | Ctl | Org | IEEE 802 +------------+------------+------------+------------+ LLC/SNAP 5 | Org | Org | EtherType | header +============+============+============+============+ ============== 6 | Msg byte 0 | Msg byte 1 | Msg byte 2 | . . . | +---------------------------------------------------+ | . . . | IEEE 802 +<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+ Data | . . . | byte (n-2) | byte (n-1) | FILL | +------------+------------+------------+------------+ | FILL | FILL | FILL | FILL | +------------+------------+------------+------------+ | FILL | FILL | FILL | FILL | +------------+------------+------------+------------+ | FILL | FILL | FILL | FILL | +------------+------------+------------+------------+ | FILL | FILL | FILL | FILL | +------------+------------+------------+------------+ | FILL | FILL | FILL | FILL | +------------+------------+------------+------------+ | FILL | FILL | FILL | FILL | +------------+------------+------------+------------+ M-1| FILL | FILL | FILL | FILL | +<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+ Generic 802.1 data packet diagram All IP (v4) packets will allways span two or more micropackets. The first mircopacket has a TYPE = header, The second and any further micropackets have a TYPE = Data (see [] for further information). |31 |23 |15 |7 0| +------------+------------+------------+------------+ -------------- 0 | | | D_ULA +-------------------------+ HIPPI-6400 1 | | | +-------------------------+ S_ULA | MAC 2 | | +---------------------------------------------------+ header 3 | M_len | Pittet [Page 9] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 +------------+------------+------------+------------+ -------------- 4 | AA | AA | 03 | 00 | IEEE 802 +------------+------------+------------+------------+ LLC/SNAP 5 | 00 | 00 | EtherType = 0x0800=2048 | header +============+============+============+============+ ============== 6 | VER | HLEN | TOS | Total Length | +-----+------+------------+-----+-------------------+ 7 | ID | FLG | Frag Offset | +<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+ IPv4 Header 8 | TTL | PROTO | Header Checksum | +------------+------------+-------------------------+ 9 | Source IP Address | +---------------------------------------------------+ 0 | Destination IP Address | +---------------------------------------------------+ 11| . . . | +---------------------------------------------------+ IP v4 data packet diagram As shown in above figure the first eight bytes of the IP Datagram occupy the last eight bytes of the HIPPI-6400-PH Header micropacket. 4.2 HIPPI-6400 Hardware address: Universal LAN MAC address (ULA) HIPPI-6400 uses Universal LAN MAC Addresses specified in IEEE Standard 802.1A. The globally unique part of the 48 bit space is administered by the IEEE. Each node on a HIPPI-6400-SC LAN MUST be assigned a ULA. Multiple ULAs may be used if a node contains more than one IEEE 802.2 LLC protocol entity. ULA's may be changed according to HIPPI-6400-PH. For IP and ARP to function correctly though, care must be taken to ensure that the ULAs assigned are unique at least within the scope of the HIPPI-6400 LAN. The use of ULAs is REQUIRED. The format of the address within its 48 bit HIPPI-6400-PH fields follows IEEE 802.1A canonical bit order and HIPPI-6400-PH bit and byte order: 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 | (not used for ULA) | +---------------+---------------+---------------+---------------+ Universal LAN MAC Address Format L (U/L bit) = 1 for Locally administered addresses, 0 for Universal. Pittet [Page 10] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 G (I/G bit) = 1 for Group addresses, 0 for Individual. 4.3 HIPPI-800 Hardware Address Formats and Requirements For HIPPI-800, the Hardware Address is a 9-byte unit that SHALL 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 HARP 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 | +---------------+---------------+ 4.3 MTU Maximum Transmission Unit (MTU) is defined as the length of the IP packet, including IP header, but not including any overhead below IP. Conventional LANs have MTU sizes determined by physical layer specification. MTUs may be required simply because the chosen medium won't work with larger packets, or they may serve to limit the amount of time a node must wait for an opportunity to send a packet. HIPPI-6400-PH limits packets to about 4 gigabytes (on VC 3) which imposes no practical limit for networking purposes. HIPPI-6400-PH VC 1 which was chosen for IP and ARP traffic limits messages to about 128 KBytes which is still larger than the HIPPI-800 [] MTU. The MTU for HIPPI-6400 LANs is 65280 (decimal) octets. Pittet [Page 11] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 This value was selected because it is backwards compatible with HIPPI-800. It was chosen for HIPPI-800 because it allows the IP packet to fit in one 64K octet buffer with up to 256 octets of overhead. The overhead is 24 octets for HIPPI-6400 and 40 octets for HIPPI-800; there are 232 octets for HIPPI-6400 and 216 octets for HIPPI-800 of room for expansion. HIPPI-6400-PH Header 16 octets IEEE 802.2 LLC/SNAP Headers 8 octets Maximum IP packet size (MTU) 65280 octets ------------ Total 65304 octets (64K - 232) HIPPI-800-FP Header 8 octets HIPPI-800-LE Header 24 octets IEEE 802.2 LLC/SNAP Headers 8 octets Maximum IP packet size (MTU) 65280 octets ------------ Total 65320 octets (64K - 216) 5. HIPPI Address Resolution Protocol - HARP Address resolution within the HIPPI-6400 LIS SHALL make use of the HIPPI Address Resolution Protocol (HARP) and the Inverse HIPPI Address Resolution Protocol (InHARP) . HARP provides the same functionality as the Internet Address Resolution Protocol (ARP). HARP is based on ARPwhich is defined in RFC-826 [15] except the HIPPI-6400 specific packet format. Knowing the Internet address, conventional networks use ARP to discover another node's hardware address. HARP presented in this section further specifies the combination of the original protocol definitions to form a coherent address resolution service that is independent of the hardware's broadcast capability. InHARP is the same protocol as the original Inverse ARP (InARP) protocol presented in [7] except the HIPPI-6400 specific packet format. Knowing its hardware address,InARP is used to discover the other party's Internet address. This memo further REQUIRES the PIBES (see section 7 below) extension to the HARP protocol, guaranteeing broadcast service to upper layer protocols like IP. Internet addresses are assigned independent of ULAs. Before using HARP, each node MUST know its IP and its HW addresses . The ULA is optional but is RECOMMENDED if interoperability with conventional Pittet [Page 12] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 networks is desired. If not all switches in the LIS support broadcast then there will be a HARP server providing the address resolution service and it will be the source of the replies. If on the other hand all switches support broadcast then the source address of a reply will be the target's target address. 5.1 HARP Algorithm This section defines the behavior and requirements for HARP implementations on both broadcast and non-broadcast capable HIPPI- 6400-SC networks. HARP creates a table in each node which maps remote nodes' IP addresses to ULAs, so that when an application requests a connection to a remote node by its IP address, the remote ULA can be determined, a correct HIPPI-6400-PH header can be built, and a connection to the node can be established using the correct Switch Address in the I-field. HARP is a two phase protocol. The first phase is the registration phase and the second phase is the operational phase. The registration phase uses the InHARP protocol to register and establish a table entry with the server. The operational phase works much like conventional ARP with the exception of the message format. 5.1.1 HARP registration phase HARP clients SHALL initiate the registration phase through the sending of an InHARP_REQUEST message using the primary address in the HRAL. The client SHALL terminate the registration phase and transition into the operational phase either when it receives its own InHARP_REQUEST or when it receives an InHARP_REPLY. The client SHALL retry at least once every 5 seconds until one of these two termination criterias are met. InHARP is an application of the InARP protocol for a purpose not originally intended. The purpose is to accomplish registration of node IP address mappings with a HARP server if one existsor detect hardware broadcast capability. If the HIPPI-6400-SC LAN supports broadcast, then the client will see its own InHARP_REQUEST message and SHALL complete the registration phase . The client SHOULD further note that it is connected to a broadcast capable network and use this information for aging the HARP server entry and for IP broadcast emulation as specified in sections 5.4 and 5.6 respectively. If the client doesn't see its own InHARP_REQUEST it SHALL await an Pittet [Page 13] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 InHARP_REPLY before completing the registration phase. This will also provide the client with the protocol address by which the HARP server is addressable. This will be the case when the client happens to be connected to a non-broadcast capable HIPPI-6400-SC network. 5.1.2 HARP operational phase Once a HARP client has completed its registration phase it enters the operational phase. In this phase of the protocol, the HARP client SHALL gain and refresh its own HARP table information about other IP members through the sending of HARP_REQUESTS to the primary address in the HRAL and the reception of HARP_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-6400-SC switched networks. The target of an address resolution request updates its address mapping tables with any new information it can find in the request. If it is the target node it SHALL formulate and send a reply message. 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 HARP 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 HARP server . NOTE: It is REQUIRED to have a HARP server run on a node that has a non-zero ULA. 5.2 HARP Client Operational Requirements The HARP client is responsible for contacting the HARP server(s) to have its own HARP information registered and to gain and refresh its own HARP entry/information about other IP members. This means, as noted above, that HARP clients MUST be configured with the hardware address of the HARP server(s) in the HRAL. HARP clients MUST: Pittet [Page 14] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 1. When an interface is enabled (e.g. "ifconfig up") or assignedan IP alias, the client SHALL initiate the registration phase. 2. In the operational phase the client MUST respond to HARP_REQUEST and InHARP_REQUEST messages, 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 InHARP_REPLY for each such address. In that case an InHARP_REQUEST can have multiple replies. (Refer to Section 7, "Protocol Operation" in RFC-1293 [7].) 3. React to address resolution reply messages appropriately to build/refresh its own client HARP table entries. All (solicited and unsolicited) HARP_REPLYs from the primary HARP server SHALL be used to update and refresh its own client HARP table entries. Explanation: This allows the HARP server to update the clients when one of server's mappings change, similar to what is accomplished on Ethernet with gratuitous ARP. 4. Generate and transmit InHARP_REQUEST messages as needed and process InHARP_REPLY messages appropriately (see section 5.1.1 and 5.6). All InHARP_REPLY messages SHALL be used to build/refresh its client HARP table entries. (Refer to Section 7, "Protocol Operation" in [7].) If the registration phase showed that the hardware does not support broadcast, then the client MUST refresh its own entry for the HARP server, created during the registration phase, at least once every 15 minutes. This can be accomplished either through the exchange of aHARP request/reply with the HARP server or by repeating step 1. To decrease the redundant network traffic, this timeout SHOULD be reset after each HARP_REQUEST/HARP_REPLY exchange. Explanation: The HARP_REQUEST shows the HARP server that the client is still alive. Receiving a HARP_REPLY indicates to the client that the server must have seen the HARP_REQUEST. If the registration phase showed that the underlying network supports broadcast, then the operation is NOT REQUIRED. 5.3 Receiving Unknown HARP Messages If a HARP client receives a HARP 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 HARP client is NOT Pittet [Page 15] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 REQUIRED to return any message to the sender of the undefined message. 5.4 HARP Server Operational Requirements A node is a HARP server if it's hardware address is the same as an address in the HRAL. A HARP server accepts HIPPI connections from other HIPPI node. The HARP server expects an InARP_REQUEST as first message from the client. A server examines the IP address, the hardware address, and the ULA of the InARP_REQUEST and adds or updates its HARP table entry as well as the time stamp. The following table shows all possible source address combinations on an incoming message and the actions to be taken. "linked" indicates that an existing "IP entry" is linked to a "HW entry". It is possible to have an existing "IP entry" and to have an existing "HW entry" but neither is linked to the other. +---+----------+----------+------------+------------------+ | # | IP entry | HW entry | misc | Action | +---+----------+----------+------------+------------------+ | 1 | exists | exists | linked | * | | 2 | exists | exists | not linked | *,a , b, e, f | | 3 | exists | new | not linked | *, a, b, d, e, f | | 4 | new | exists | not linked | *, c, e, f | | 5 | new | new | not linked | *, c, d, e, f | +---+----------+----------+------------+------------------+ Actions: *: update timeout value a: break the existing IP -> HW(old) link b: delete HW(old) -> IP link and decr HW(old) refcount, if refcount = 0, delete HW(old) c: create new IP entry d: create new HW entry e: add new IP -> HW link to IP entry f: add new HW -> IP link to HW entry Examples of when this could happen: 1: supplemental message Just update timer. 2: move an IP alias to an existing interface Pittet [Page 16] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 If the InHARP_REQUEST requester's IP address duplicates a table entry IP address (e. g. IPa <-> HWa) and the InHARP_REQUEST hardware address matches a hardware address entry (e. g. HWb <-> IPb), but they are not linked together, then: - HWa entry needs to have its reference to the current IPa address removed. - HWb needs to have a new reference to IPa added - IPa needs to be linked to HWb 3: move IP address to a new interfaceIf the InHARP_REQUEST requester's IP address duplicates a table entry IP address and the InHARP_REQUEST hardware address does not match the table entry hardware address, then a new HW entry SHALL be created and the IP entry SHALL be updated. 4: add IP aliasto table If the InHARP_REQUEST requester's hardware address duplicates a hardware address entry, but there is no IP entry matching the received IP address, thenIP address SHALL be added to the HW entries previous IP address(es). (E.g. adding an IP alias). .ti 3 5: fresh entry, add it Standard case, create both entries and link them. A server MUST update the HARP table entry's timeout for each HARP_REQUEST. Explanation: if the client is sending HARP requests to the server, then the server should note that the client is still "alive" by updating the timeout on the client's HARP table entry. A HARP server SHOULD use the PIBES (see sect. 7) to send out HARP_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. If there are multiple addresses in the HRAL, then a server needs to act as a client to the other servers. 5.5 HARP 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 HARP and use a table based static ARP. Permanent entries are not aged. Pittet [Page 17] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 The HARP server SHOULD use the static entries to resolve incomming HARP_REQUESTs from the clients. This feature eliminates the need for maintaining a static HARP table on the client nodes. (XXX - realy ... how about static overrides permanent! ) Dynamic information overrides static HARP information, e.g. when a HARP_REPLY from the HARP server indicates that the client's mapping needs to be updated, then the client SHALL update the entry and note that the entry is not permanent any more..ti 0 5.6 HARP Table Aging HARP 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 HARP table/cache becomes invalid and stale. o When a client's HARP table entry ages beyond 15 minutes, a HARP client MUST invalidate the table entry. o When a server's HARP table entry ages beyond 20 minutes, the HARP server MUST delete the table entry. NOTE: the client SHOULD revalidate a HARP table entry 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 is not invalidated. The client MUST revalidate the invalidated entry prior to transmitting any non address resolution traffic to the node referred to by this entry. The client revalidates the entry by querying the HARP server. If a valid reply is received (e.g. HARP_REPLY), the entry is updated. If the address resolution service cannot resolve the entry (e.g. HARP_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 InHARP_REQUEST to the hardware address of the entry in question and updating the entry on receipt of an InHARP_REPLY. If the InHARP_REQUEST attempt fails to return an InHARP_REPLY, the associated table entry is removed. 6. HARP Message Encoding The HARP message is just another type of IEEE 802 payload as described in section XX above. Pittet [Page 18] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 6.1 HARP and InHARP Message Formats The HARP protocols use the (XXX) hardware type (ar$hrd), protocol type (ar$pro), and operation code (ar$op) data formats as the ARP, and InARP protocols [15,7]. In addition, HARP makes use of an additional operation code for ARP_NAK introduced with [13]. The remainder of the HARP/InHARP message format is different than the ARP/InARP message 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]. HARP messages SHALL be transmitted with a hardware type code of 1 (XXX). Furthermore, HARP messages SHALL be accepted if received with hardware type codes of either 1 or 6 XXX(IEEE 802 networks). The HARP 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) (XXX)ar$pro - SHALL contain the IP protocol code 2048 (decimal). ar$op - SHALL contain the operational value (decimal): 1 for HARP_REQUESTs 2 for HARP_REPLYs 8 for InHARP_REQUESTs 9 for InHARP_REPLYs 10 for HARP_NAK ar$pln - SHALL contain 4. ar$rln - SHALL contain 10 IF this is a HIPPI-800 link ELSE, for HIPPI-6400, it SHALL contain 6. Pittet [Page 19] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 ar$thl - SHALL contain 10 IF this is a HIPPI-800 link ELSE, for HIPPI-6400, it SHALL contain 6. 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. 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. Payload Format for HARP/InHARP PDUs: |31 |23 |15 |7 0| +---------------+---------------+---------------+---------------+ ---------- 0 | | | D_ULA +-------------------------------+ HIPPI- 1 | | | 6400 +-------------------------------+ S_ULA | MAC 2 | | +---------------------------------------------------------------+ header 3 | M_len | +---------------+---------------+---------------+---------------+ ---------- 4 | AA | AA | 03 | 00 | IEEE 802 +---------------+---------------+---------------+---------------+ LLC/SNAP 5 | 00 | 00 | EtherType = 0x0800 = 2048 | header +------------+------------------+-------------------------------+ ========== 6 | hrd (1) | pro (2048) | +---------------+---------------+---------------+---------------+ 7 | op (ar$op) | pln (6) | shl (q) | Pittet [Page 20] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 +<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+ 8 | thl (x) | Requester's IP Address upper (24 bits) | +---------------------------------------------------------------+ 9 | Src. IP lower | Target's IP Address upper (24 bits) | +---------------+-----------------------------------------------+ 10 | Tgt. IP lower | Requester's ULA octets 0 - 2 | +---------------+-------------------------------+---------------+ 11 | Requester's ULA octets 3 - 5 | Tgt ULA oct 0 | +-----------------------------------------------+---------------+ 12 | Target ULA octets 1 - 4 | +---------------+-----------------------------------------------+ 13 | Tgt ULA oct 5 | +---------------+ HARP - InHARP Message 6.2 Example Message encodings: HARP_REQUEST message HARP ar$op = 8 (InHARP_REQUEST) HARP ar$rpa = Ipy HARP ar$tpa = 0 ** HARP ar$rha = SWy ULAy HARP ar$tha = SWa ULAs ** is what we would like to find out HARP_REPLY message format HARP ar$op = 9 (InHARP_REPLY) HARP ar$rpa = IPs * HARP ar$tpa = IPy HARP ar$rha = SWa ULAs HARP ar$tha = SWy ULAy * answer we were looking for InHARP_REQUEST message format HARP ar$op = 8 (InHARP_REQUEST) HARP ar$rpa = Ipy HARP ar$tpa = 0 ** HARP ar$rha = SWy ULAy HARP ar$tha = SWa ULAs ** is what we would like to find out InHARP_REPLY message format HARP ar$op = 9 (InHARP_REPLY) HARP ar$rpa = IPs * HARP ar$tpa = IPy HARP ar$rha = SWa ULAs HARP ar$tha = SWy ULAy * answer we were looking for 6.3 HARP_NAK message format The HARP_NAK message format is the same as the received HARP_REQUEST message format with the operation code set to HARP_NAK; i.e. the HARP_REQUEST message data is copied for transmission with the HARP_REQUEST operation code changed to the HARP_NAK value. HARP Pittet [Page 21] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 makes use of an additional operation code for HARP_NAK and MUST be implemented. 7 Broadcast and Multicast HIPPI-6400-SC requires complient systems to support broadcast. The switch part of the system MAY though not implement broadcast but defer that operation to a broadcast server. It is likely therefore that broadcast support will be absent from initial HIPPI-6400 switches. However, a centralized HARP 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 HARP server(s), discover if the underlying medium is capable of broadcast (see section 5.1.1). Should this not be the case, then the HARP server(s) MUST emulate broadcast through an IP broadcast emulation server. A HIPPI IP broadcast server (PIBES) is an extension to the HARP server and only makes sense when the LIS does not inherently support broadcast. The PIBES allows standard networking protocols to access IP LIS broadcast. 7.1 Protocol for an IP Broadcast Emulation Server - PIBES To emulate broadcast within an LIS, a HIPIBS SHALL use the currently valid HARP table of the HARP server as a list of addresses called the target list. The broadcast server SHALL validate that all incoming messages have a source address which corresponds to an address in the target list. Only messages addressed to the IP LIS broadcast address (FF.FF.FF.FF) are considered valid messages for broadcasting. Invalid messages MUST be dropped. All valid incoming messages shall be forwarded to all addresses in the target list. It is RECOMMENDED that the broadcast server run on the same node as the HARP server since this memo does not define the protocol of exchanging the valid HARP table. 7.2 IP Broadcast Address This memo only defines IP broadcast . It is independent of the underlying hardware addressing and broadcast capabilities. Any node Pittet [Page 22] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 can differentiate between IP traffic directed to itself and a broadcast message sent to it through looking at the IP address. All IP broadcast messages SHALL use the IP LIS broadcast address (FF.FF.FF.FF). It is RECOMENDED that the PIPES run on the same node as the HARP server. In that case, the PIBES SHALL use the same address ad the HARP server. 7.3 IP Multicast Address HIPPI-6400 does not directly support multicast address , 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 IP broadcast address (FF.FF.FF.FF). 7.4 A Note on Broadcast Emulation Performance It is obvious that a broadcast emulation service (as defined in section 7.1) has an inherent performance limit. In an LIS with n nodes, the upper bound on the bandwidth that such a service can broadcast is: (total bandwidth)/(n+1) since each message must first enter the broadcast server, accounting for the additional 1, and then be sent to all n nodes. The broadcast server could forward the message destined to the node on which it runs internally, thus reducing (n+1) to (n) in a first optimization. The point is that such a service is adequate for the standard networking protocols such as RIP, OSPF, NIS, etc. since they usually use a small fraction of the network bandwidthfor broadcast. For all general purposes, the broadcast emulation server as defined in this memo allows the HIPPI-6400 network to look similar to an Ethernet networkto 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, is required. 8 HARP for Scheduled Transfer [22] 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 nodes. Pittet [Page 23] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 9 Security Not all of the security issues relating to ARP over HIPPI-6400 are clearly understood at this time. There are known security issues relating to node impersonation via 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 HARP. 10 Open Issues 11 Bridging This section deals with the additional requirements for the HARP server as needed in a bridged environment. Further, section will These requirements are nescessary for interoperability with bridges. 11.1 Server Behaviour in the presence of a Bridge. The ARP Server SHALL have a mechanism to enter the presence of a Bridge statically. This memo does not define a mechanism by which the bridge could register itself as a "bridge" with the server. The Administrator will have to enter the information in the Server Tables indicating that the entry is a Bridge. 11.1.1 ARP Message from Bridge to Server The Server SHALL receive an LE Packet from the Bridge that has an Ethertype of 0x801 or HardType of 1 (Ethernet) and op of ARP. The Packet will be a HIPPI Encapsulated Ethernet message which will contain the Ethernet message for ARP. The Bridge would have stripped out the Ethernet Header and added the HIPPI-LE Header with it's Logical Address in the "Requester's Switch Addr" field of the HIPPI- LE headder. The Server will have to make an exception processing this packet since it didn't originate with in the HIPPI-800 network. It will now have to look at the LE Source Switch Address which will be the Logical address of the Bridge on this switch. The Server SHALL process the Packet and retreive the ARP information of both the Source and destination from the packet. If the requested destination is a non HIPPI NIC, the Server SHALL drop the request and not respond to the Request but mearly update its tables. The Server MAY forward this ARP message to any of its other connected Bridges on a known cofiguarion if the information was not found in Pittet [Page 24] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 its tables. The Server SHALL not send either a HIP_NAK or a HIP_PEND to the Bridge. +-------+ | HARP | |Server | +-------+ ^ | (2) | | +=======+ #------# +========+ +--------+ |HIPPI |<--(2)--|Bridge|<--(1)--|Ethernet|<--(1)--|Ethernet| |Switch | | | | Switch | | NIC | +=======+ #------# +========+ +--------+ ARP Request from Ethernet to HIPPI Step(1) ARP Message Originating from an Ethernet NIC goes to the Bridge via an Ethernet Switch Step(2) Brige will strip out the Ethernet Header from the message and add a HIPPI LE Header to the begining of the ARP Message. This message is now forwarded to the HARP Server on a HIPPI Switch. 11.1.1.1 IP Broadcast Messages from Bridge The Server SHALL transmit the Broadcast message to the PIPES to be transmittedt to all Registred HIPPI Clients. The Server will receive an Encapsulated Ethernet Broadcast message. +--------+ | B Cast | | Server | +--------+ +------+ | ^ |HIPPI | (2) | | |Node | | (1) |E +---^--+ V | |t | +========+ #------# |h +-----(2)----| HIPPI |<--(1)--|Bridge|<-(1)--|e +-----(2)----| Switch | | | |r | +========+ #------# |n +---V--+ |e |HIPPI | |t Pittet [Page 25] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 |Node | | +------+ IP Broadcast from Bridge Step(1) A Broad Cast message that arrived at the Bridge from the Ethernet is stripped off its Ethernet Header and a HIPPI LE Header is added. This is forwarded to the (HARP)Broadcast Server via the Switch. Step(2) The HARP(Broadcast) Server will forward all Broadcast messages from the Bridge to all it's registered HIPPI Nodes. 11.1.2 Message to Bridge 11.1.2.1 ARP Request to Bridge Upon receiving an HARP Request, The Server SHALL try to service the request as specified in the Document. If an entry is not found for the request, the Server SHALL form an encapsulated Ethernet ARP Request packet to be sent to all the connected Bridges. The Server SHALL also send a HAPR_PEND message back to the requesting HIPPI Node in accordance with section x.x. +-------+ | HARP | | Server| +-------+ ^ | | | (3)(2) (1) | | | V V +-------+ +=======+ #------# | HIPPI |--(1)-->| HIPPI |--(2)-->|Bridge| | Node |<--(3)--| Switch| | | +-------+ +=======+ #------# ARP Request to Bridge Step(1) A Registered HIPPI Node makes an ARP Request to the HARP Server via the Switch. Step(2) The HARP Server doesn't have the information to serivce the request, so it SHALL form an Ethernet ARP Packet and Encapsulate it in a HIPPI LE message. This message is sent to all the connected Bridges for forwarding to Ethernet. Step(3) Since the request coudn't be serviced, the HARP Server SHALL send a HARP_PENDING back to the requesting node. Pittet [Page 26] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 11.1.2.2 ARP Reply to Bridge If the Server receives a request from the Bridge which it can reply to, that is the requested destination is a HIPPI node, it will form an Ethernet ARP REPLY encapsulated with the information requested and send it to the Bridge. +--------+ | ARP | | Server | +--------+ | (1) | | |E V |t +========+ #------# |h | HIPPI |--(1)-->|Bridge|--(2)-->|e | Switch | | | |r +========+ #------# |n |e |t ARP Reply to Bridge Step(1) When the Server has the information that was requested and the requested destination information is of a HIPPI node, it SHALL form an Ethernet ARP Reply that will be encapsulated in a HIPPI-LE packet and sent to the Bridge Step(2) The Bridge SHALL strip the LE Header from the packet and attach an ethernet packet and send out to the Ethenet. 11.2 Bridge Behaviour 11.2.1 Message from HIPPI to Bridge Any message coming from the HIPPI Network to the Bride SHALL be striped of the HIPPI header and an Ethernet Header SHALL be attached to the message. If the Bridge is a learning Bridge, then every time a packet goes from the HIPPI side to the Ethernet side via the Bridge, the Bridge will need to update it's Tables with the new ULA, LA mapping. The bridge will use the HIPPI-LE Destination_ULA and HIPPI-LE Requester's ULA to form the MAC headder. The following diagram shows the HARP Message Format (HIPPI ARP) and in contrast the ARP Message Format (Ethernet ARP) 31 28 23 21 15 10 7 2 0 Pittet [Page 27] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 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 | +---------------+---------------+-------------------------------+ 17 | Target's HIPPI Hardware Address octets 2 - 5 | +-----------------------------------------------+---------------+ 18 | Target's HIPPI Hardware Address octets 6 - 8 | +-----------------------------------------------+ HIPPI-800 HARP_REQUEST, InHARP_REQUEST 31 28 23 21 15 10 7 2 0 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 0 | Ethernet Destination Address (ULA) 0 - 3 | +-------------------------------+-------------------------------+ 1 | Ethernet Destination Addr 4-5 | Ethernet Source Address 0 - 1 | +-------------------------------+-------------------------------+ Pittet [Page 28] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 2 | Ethernet Source Address (ULA) 2 - 5 | +-------------------------------+===============================+ 3 | Frame Type (16 bits) + Hard Type (16 bits) | +===============================+---------------+---------------+ 4 | Protocol Type (16 bits) | Hard Size (8) | Prot Size (8) | +-------------------------------+---------------+---------------+ 5 | op ( 16 bits) | Sender ULA 0 - 1 | +-------------------------------+-------------------------------+ 6 | Sender ULA 2 - 5 | +---------------------------------------------------------------+ 7 | Sender IP | +---------------------------------------------------------------+ 8 | Target ULA 0 - 3 | +-------------------------------+-------------------------------+ 9 | Target ULA 4 - 5 | Target IP 0 - 1 | +-------------------------------+-------------------------------+ 10 | Target IP 2 - 3 | +-------------------------------+ Ethernet ARP Request or Reply 11.2.2 Message from Ethernet/Other to Bridge If the message is of Ethertype ARP, the Bridge SHALL forward this message to the Server alone. It shall strip the Ethernet header and add a HIPPI header to the message before sending this message to the Server. If the message is an IP Broadcast from Ethernet, the Bridge, after stripping the Ethernet Header and adding a HIPPI header, SHALL forward the message to the Server. +--------+ | B Cast | | Server | +--------+ | ^ (2) | | | (1) |E V | |t +-------+ +========+ #------# |h | HIPPI |--(1)-->| HIPPI |--(2)-->|Bridge|--(3)->|e | Node | | Switch | | | |r +-------+ +========+ #------# |n |e |t IP broadcast from HIPPI Pittet [Page 29] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 Step(1) When a Node wants to send an IP Broadcast, it shall form a Broadcast message and send it to the HARP(Broadcast) Server. Step(2) The Broadcast server SHALL forward the message to all it's Registered HIPPI Nodes and it's attached Bridges. Step(3) The Bridge Shall forward this message to the Ethernet as a Broadcast Packet. 11.2.2.3 Other Messages from Ethernet The assumption is that the Bridge will keep track of ULA, LA mappings and if it receives a message that is not a Broadcast, then the Bridge will check its Tables to find a match for the destination and form a HIPPI header with the Switch Address of the destination Node. If a match is not found, depending on the configuation, the Bridge MAY drop the packet or forward it to an another Bridge. 12 HARP Examples Assume a HIPPI-6400-SC switch is installed with three connected nodes: X, Y, and a. Each node has a unique hardware address that consists unique ULA (ULAx, ULAy and ULAa, respectively). There is a HARP server connected to a switch port that is mapped to the address HWa (ULAa by default = FF.FF.FF.FF.FF.FF), this address is the primary HIPPI hardware address in the HRAL (HARP Request Address List). The HARP 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 node database) but neither knows the other's ULA. Both nodes X and Y have their interfaces configured DOWN. Note: The LLC, SNAP, Ethertype, ar$hrd, ar$pro, ar$pln fields are left out from the examples below since they are constant. As well as ar$rhl = ar$thl = 6 since these are all HIPPI-6400 examples. 12.1 Registration Phase of Client Y on Non-broadcast Hardware Node Y starts: its HARP table entry state for the server: PENDING 1. Node Y initiates its interface and sends an InHARP_REQUEST to the HWa after starting a table entry for the HWa. HIPPI-6400-PH D_ULA = ULAa HIPPI-6400-PH S_ULA = ULAy HARP ar$op = 8 (InHARP_REQUEST) Pittet [Page 30] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 HARP ar$rpa = IPy HARP ar$tpa = 0 ** HARP ar$rha = SWy ULAy HARP ar$tha = SWa ULAs ** is what we would like to find out 2. HARP server receives Y's InHARP_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 InHARP_REQUEST. The HARP server will then send a InHARP_REPLY including its IP address. HIPPI-6400-PH D_ULA = ULAy HIPPI-6400-PH S_ULA = ULAs HARP ar$op = 9 (InHARP_REPLY) HARP ar$rpa = IPs * HARP ar$tpa = IPy HARP ar$rha = SWa ULAs HARP ar$tha = SWy ULAy * answer we were looking for 3. Node Y examines the incoming InHARP_REPLY, completes its table entry for the HARP server. The client's HARP table entry for the server now passes into the VALID state and is usable for regular HARP traffic. Receiving this reply ensures that the HARP 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 HRAL would be mapped to the broadcast address, HWb = SWb, ULAb (likely 0xFE1 and FF.FF.FF.FF.FF.FF). Node Y starts: its HARP table entry state for HWa: PENDING 1. Node Y initiates its interface and sends an InHARP_REQUEST to HWa, in this example the broadcast address, after starting a table entry. HIPPI-6400-PH D_ULA = ULAb HIPPI-6400-PH S_ULA = ULAy HARP ar$op = 8 (InHARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = 0 ** HARP ar$rha = SWy ULAy HARP ar$tha = SWb ULAb ** is what we would like to find out Pittet [Page 31] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 2. Since the network is a broadcast network, client Y will see an InHARP_REQUEST, it examines the source addresses. Since they are the same as what Y filled in the InHARP_REQUEST, Y can deduce that it is connected to a broadcast medium. Node Y completes its table entry for HWa. 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 HARP protocol as specified in this memo is the same for both possibilities of a broadcast and non-broadcast capable HIPPI-6400 hardware. The primary address in the HRAL for this example section will be HWa: and IPs for simplicity reasons. 12.2.1 Standard successful HARP_Resolve example Assume the same process (steps 1-3 of section 10.1) happened for node X. Then the state of X and Y's tables is: the HARP server table entry is in the VALID state. So lets look at the message traffic when X tries to send a message to Y. Since X doesn't have an entry for Y, 1. node X connects to the primary address of the HRAL and sends a HARP_REQUEST for Y's hardware address: HIPPI-6400-PH D_ULA = ULAa HIPPI-6400-PH S_ULA = ULAx HARP ar$op = 1 (HARP_REQUEST) HARP ar$rpa = IPx HARP ar$tpa = IPy HARP ar$rha = SWx ULAx HARP ar$tha = 0 ** ** is what we would like to find out 2. The HARP server receives the HARP request and updates its entry for X if necessary. It then generates a HARP_REPLY with Y's hardware address information. HIPPI-6400-PH D_ULA = ULAx HIPPI-6400-PH S_ULA = ULAa HARP ar$op = 2 (HARP_Reply) HARP ar$rpa = IPy HARP ar$tpa = IPx HARP ar$rha = SWy ULAy * HARP ar$tha = SWx ULAx Pittet [Page 32] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 * answer we were looking for 7. Node X connects to node Y and transmits an IP message with the following information in the HIPPI-LE header: HIPPI-6400-PH D_ULA = ULAy HIPPI-6400-PH S_ULA = ULAx If there had been a broadcast capable HIPPI network, the target nodes would themselves have received the HARP_REQUEST of step 2 above and responded to them in the same way the HARP server did. 12.3.2 Standard non-successful HARP_Resolve example Like in 12.3.1, assume that X and Y are fully registered with the HARP server. Then the state of X and Y's HARP server table entry is: VALID. So lets look at the message traffic when X tries to send a message 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 HARP server switch address and sends a HARP_REQUEST for Q's hardware address: HIPPI-6400-PH D_ULA = ULAa HIPPI-6400-PH S_ULA = ULAx HARP ar$op = 1 (HARP_REQUEST) HARP ar$rpa = IPx HARP ar$tpa = IPq HARP ar$rha = SWx ULAx HARP ar$tha = 0 ** ** is what we would like to find out 2. The HARP server receives the HARP request and updates its entry for X if necessary. It then looks up IPq in its tables and doesn't find it. The HARP server then generates a HARP_NAK reply message. HIPPI-6400-PH D_ULA = ULAx HIPPI-6400-PH S_ULA = ULAa HARP ar$op = 10 (HARP_NAK) HARP ar$rpa = IPx HARP ar$tpa = IPy HARP ar$rha = SWx ULAx HARP ar$tha = 0 *** *** No Answer, and notice that the fields do not get swapped, i.e. the HARP message is the same as the HARP_REQUEST except for the operation code. Pittet [Page 33] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 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 Signaling 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 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 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 Pittet [Page 34] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 Address Resolution Protocol", RFC-903, Stanford University, June 1984. [] Chesson, Greg, "HIPPI-6400 Overview", Hot Interconnects 1996, Stanford University [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. [22] 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 HARP as presented in this memo. Further, the HARP server is based on concepts and models presented in [13], written by Mark Laubach who laid the structural groundwork for the HARP server. Pittet [Page 35] INTERNET DRAFT IP and ARP over HIPPI-6400 Expires 3/99 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 36]