Ineternet Engineering Task Force Jean-Michel Pittet INTERNET-DRAFT Silicon Graphics, Inc. Standards Track Jeff Young Document: draft-murphy-rfc2835bis-00.txt Vieo, Inc. Submitted: 8 October 2001 Sean Murphy Expires: 8 April 2002 Silicon Graphics, Inc. 20 May 2001 IP and ARP over HIPPI-6400 (GSN) <draft-murphy-rfc2835bis-00.txt > Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Distribution of this memo is unlimited. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Abstract This memo specifies a standard method of encapsulating and transmitting Internet Protocol (IP) [1] datagrams, Address Resolution Protocol (ARP) [2] messages, and Inverse Address Resolution Protocol (InARP) [3] messages on HIPPI-6400 networks. The specifications outlined in this memo were chosen to allow IP intercommunication between HIPPI-800 and HIPPI-6400 media. Pittet, Young, Murphy Standards Track [Page 1]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IP Subnetwork Configuration . . . . . . . . . . . . . . . . 4 3.1 Background . . . . . . . . . . . . . . . . . . . . . . 4 3.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . . 4 4. Packet Transmission . . . . . . . . . . . . . . . . . . . . 4 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 4 5.1 HIPPI-6400 Packet Diagrams . . . . . . . . . . . . . . 5 5.2 HIPPI-6400 Hardware Address: Universal LAN MAC Addr . 6 5.3 Maximum Transmission Unit . . . . . . . . . . . . . . 7 6. HIPPI Address Resolution Protocol . . . . . . . . . . . . . 7 6.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . . 8 6.1.1 Broadcast Discovery Phase . . . . . . . . . . . 8 6.1.2 Registration Phase . . . . . . . . . . . . . . . 9 6.1.3 Operational Phase . . . . . . . . . . . . . . . 10 6.1.3.1 HARP Client Operational Requirements . . . 10 6.1.3.2 HARP Server Operational Requirements . . . 12 6.2 Primary HARP Server Selection . . . . . . . . . . . . 12 6.3 HARP Table Entry Creation and Modification . . . . . . 13 6.4 HARP and Permanent ARP Table Entries . . . . . . . . . 14 6.5 HARP Table Entry Aging . . . . . . . . . . . . . . . . 14 6.6 Receiving Unknown HARP Messages . . . . . . . . . . . 15 7. HARP Message Encoding . . . . . . . . . . . . . . . . . . . 15 7.1 Generic IEEE 802 ARP Message Format . . . . . . . . . 16 8. HIPPI-6400 Broadcast . . . . . . . . . . . . . . . . . . . 17 9. HARP for Scheduled Transfer . . . . . . . . . . . . . . . . 18 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. HARP Examples . . . . . . . . . . . . . . . . . . . . . . . 18 11.1 Discovery Phase of Client on Broadcast Medium . . . . 18 11.2 Discovery Phase of Client on Non-Broadcast Medium . . 19 11.3 Registration Phase of Client on Non-Broadcast Medium . 19 11.4 Successful HARP_RESOLVE on Broadcast Medium . . . . . 20 11.5 Unsuccessful HARP_RESOLVE on Broadcast Medium . . . . 22 11.6 Successful HARP_RESOLVE on Non-Broadcast Medium . . . 22 11.7 Unsuccessful HARP_RESOLVE on Non-Broadcast Medium . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 26 15. Full Copyright Statement . . . . . . . . . . . . . . . . . 27 1. Introduction HIPPI-6400, commonly called Gigabyte System Network (GSN), is a full- duplex data channel that can transmit and receive data simultaneously at 6400 megabits per second. HIPPI-6400 data transfers are segmented into micropackets, each composed of 32 data bytes and 8 control Pittet, Young, Murphy Standards Track [Page 2]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 bytes. HIPPI-6400 uses four multiplexed virtual channels (VCs), which are used for control traffic (VC0), low latency traffic (VC1), and bulk data traffic (VC2 and VC3); virtual channels and their use are detailed in HIPPI-6400-PH [4]. Micropackets for a particular virtual channel are guaranteed to arrive at their destination in the order in which they were sent. HIPPI-6400-PH [4] defines the encapsulation of data into IEEE 802.2 Logical Link Control (LLC) Protocol Data Units (PDUs). This memo specifies how IP datagrams and ARP/InARP packets are encapsulated within these PDUs and transmitted over HIPPI-6400. HIPPI-6400-SC [5] defines two types of HIPPI-6400 switches: bridging and non-bridging. Bridging switches are required to support hardware broadcast, while non-bridging switches do not have this requirement. Because the Address Resolution Protocol (ARP) [2] assumes an underlying broadcast medium, and because HIPPI-6400 networks can contain non-broadcast switches, standard ARP cannot be used on HIPPI-6400 for address resolution. This memo defines HARP, the HIPPI Address Resolution Protocol, which uses the standard ARP messages format but provides for address resolution on either broadcast or non-broadcast HIPPI-6400 fabric. HARP's behavior differs from ARP's only as necessary to provide an address resolution service on a non-broadcast capable medium. These differences include: o a broadcast discovery phase in which the broadcast capability of the HIPPI-6400 fabric is determined; o the definition of HARP servers, of which at least one is required on each non-broadcast HIPPI-6400 Logical IP Subnet (LIS); o periodic registration of each HIPPI-6400 node with the HARP servers on each non-broadcast HIPPI-6400 LIS; o the transmission of ARP requests to a HARP server instead of to the broadcast address for non-broadcast HIPPI-6400 LISs. In cases where the broadcast discovery phase determines that the underlying fabric is a broadcast HIPPI-6400 medium, HARP reverts to normal ARP behavior. InHARP is the same protocol as the original InARP protocol presented in [3] but applied to HIPPI-6400 networks. This memo assumes familiarity with the ARP and InARP protocols as described in RFC 826 [2] and RFC 2390 [3] respectively. Pittet, Young, Murphy Standards Track [Page 3]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 Gigabyte System Network(TM) (GSN) is a marketing name for HIPPI-6400. It is a trademark of the High Performance Networking Forum (HNF; http://www.hnf.org) for use by its member companies that supply products complying with ANSI HIPPI-6400 standards. 2. Conventions 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 [6]. 3. IP Subnetwork Configuration 3.1 Background The Address Resolution Protocol (ARP) [2] was defined to operate on a Logical IP Subnet (LIS). Because the HIPPI Address Resolution Protocol (HARP) emulates ARP's characteristics, it operates on LIS scope as well. Because nodes on a single HIPPI-6400 fabric MAY have IP addresses belonging to more than one LIS, HARP supports multiple disjoint LISs on a single fabric. Using this model, nodes of different IP subnets SHOULD communicate via an intermediate IP router even though it might be possible to open a direct HIPPI-6400 connection between the two IP members over the HIPPI-6400 fabric. 3.2 HIPPI LIS Requirements The requirements for IP members (e.g., 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 [7]; o all members of the LIS SHALL be directly connected to the HIPPI-6400 fabric; o all members of the LIS SHALL have a mechanism for mapping IP addresses to ULAs and vice versa. 4. Packet Transmission All IP datagrams and HARP messages MUST be carried on HIPPI-6400-PH Virtual Channel 1 (VC1). Pittet, Young, Murphy Standards Track [Page 4]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 5. Packet Format The packet format for IP datagrams [1] and HARP messages SHALL conform to the HIPPI-6400-PH standard [4] (see section 6). Specifically, this means that all packets: o are a multiple of 32 bytes, with shorter messages padded with zero bytes as necessary; o all packets begin with a 16-byte MAC header and an 8-byte IEEE 802.2 LLC/SNAP header [8], and the SNAP header's Ethertype field SHALL be set as mandated in the "Assigned Numbers" RFC [9]. 5.1 HIPPI-6400 Packet Diagrams The following diagram shows a HIPPI-6400 packet carrying IEEE 802 data. |31 |23 |15 |7 0| +--------------+--------------+--------------+--------------+ ---------- 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 Generic 802.1 data packet diagram Pittet, Young, Murphy Standards Track [Page 5]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 The following diagram shows an IPv4 datagram of length n followed by binary zero padding (indicated by "FILL"). "<><>" indicates the micropacket separation. (HIPPI-6400-PH [4] micropackets are 32 bytes long.) |31 |23 |15 |7 0| +--------------+--------------+--------------+--------------+ ---------- 0 | | | D_ULA +-----------------------------+ HIPPI-6400 1 | | | +-----------------------------+ 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 | VER | HLEN | TOS | Total Length | +------+-------+--------------+------+----------------------+ 7 | ID | FLG | Frag Offset | IPv4 +<><><><><><><>+<><><><><><><>+<><><>+<><><><><><><><><><><>+ 8 | TTL | PROTO | Header Checksum | header +--------------+--------------+-----------------------------+ 9 | Source IP Address | +-----------------------------------------------------------+ 10 | Destination IP Address | +-----------------------------------------------------------+ 11 | . . . | +--------------+--------------+--------------+--------------+ | . . . | byte (n-2) | byte (n-1) | FILL | +--------------+--------------+--------------+--------------+ M-2| FILL | FILL | FILL | FILL | +--------------+--------------+--------------+--------------+ M-1| FILL | FILL | FILL | FILL | +<><><><><><><>+<><><><><><><>+<><><><><><><>+<><><><><><><>+ 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]. Because IP Datagrams are always longer than eight bytes, they always need at least two HIPPI-6400-PH micropackets for their transmission. Pittet, Young, Murphy Standards Track [Page 6]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 5.2 HIPPI-6400 Hardware Address: Universal LAN MAC Address HIPPI-6400 uses 48-bit Universal LAN MAC Addresses (ULAs) as specified in IEEE Standard 802.1A [8] or a subset as defined in HIPPI-6400-SC [5]. Each addressable element, or node, on a HIPPI-6400 network MUST be assigned a unique ULA. This memo assumes the use of "Logical Addressing" as described in Annex A.2 of HIPPI-6400-SC [5]. 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 byte 0 |L|G| ULA byte 1 | ULA byte 2 | ULA byte 3 | +-----------+-+-+---------------+---------------+---------------+ | ULA byte 4 | ULA byte 5 | +---------------+---------------+ 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. 5.3 Maximum Transmission Unit The Maximum Transmission Unit (MTU) is defined as the maximum length of an IP packet, including IP header, but not including any overhead below IP (e.g., HIPPI-6400 MAC header and IEEE 802 LLC/SNAP header). The maximum MTU for HIPPI-6400 LANs SHALL be 65280 bytes. This value was chosen for backward compatibility with HIPPI-800. 6. HIPPI Address Resolution Protocol 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 Address Resolution Protocol (ARP) as defined in RFC 826 [2], with extensions needed to support address resolution in a non-broadcast environment. InHARP is the same protocol as the original Inverse ARP (InARP) protocol presented in RFC 2390 [3], but applies to HIPPI-6400 networks. When HARP is operating on a non-broadcast capable network, each LIS MUST have at least one node specified as a HARP server. As each node Pittet, Young, Murphy Standards Track [Page 7]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 is initialized, it registers its IP/ULA mappings with all defined HARP servers, so the servers always have complete knowledge of all IP/ULA mappings on the LIS. When a node wishes to determine the ULA for an IP address within that LIS, it sends an ARP_Request to one of that LIS's servers. HARP servers reply to all ARP_Request messages they can satisfy, thereby allowing the requesting node to resolve its address mapping needs. All nodes in an LIS MUST be configured with the same set of HARP servers; were this not the case, some "servers" would not contain complete mapping tables, and would not be able to resolve ARP_Requests for some LIS addresses. The list of HARP servers is called the HARP Request Address List, or HRAL. A single ULA MAY be associated with multiple IP addresses (i.e., IP aliasing), but an IP address MUST NOT be associated with more than one ULA. Before using HARP, each node MUST know its IP addresses and ULA. 6.1 HARP Algorithm This section defines the behavior and requirements for HARP implementations on both broadcast and non-broadcast capable HIPPI-6400 networks. HARP creates and maintains a table in each node which maps nodes' IP addresses to their ULAs. When a host wishes to connect to a node by its IP address, that node's ULA can be determined from this table. If a needed address mapping is not in the table, the host issues a request for this mapping to the broadcast address (for broadcast networks) or to a HARP server (for non-broadcast networks). If a reply is received, the new mapping is added to the node's mapping table so subsequent resolutions of this address can be done quickly. HARP is a three phase protocol. The first phase is the broadcast discovery phase. In this phase, the node determines whether the underlying fabric is broadcast enabled. The second phase is the registration phase, which is only used by nodes connected to non- broadcast enabled networks. In the second phase, a node registers with a HARP server. The third phase is the operational phase. In the operational phase, a node resolves addresses. This phase mimics the standard ARP protocol. 6.1.1 Broadcast Discovery Phase The ANSI HIPPI-6400-SC standard [5] specifies two types of underlying network fabrics: broadcast enabled (or bridging) and non-broadcast enabled (or non-bridging). In the broadcast discovery phase, the Pittet, Young, Murphy Standards Track [Page 8]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 node determines which type of fabric is present. To determine the fabric type, the node sends an InARP_Request message to the broadcast ULA (FF:FF:FF:FF:FF:FF). The node uses its own IP address and ULA for the source addresses and its own ULA for the target hardware address. The target IP address is set to zero. If the node receives its own broadcast packet, the node is connected to a broadcast capable network. In this case, the node SHALL skip the registration phase and proceed to the operational phase. If the node does not receive its own InARP_Request message within some implementation-defined time period, it SHOULD assume that the underlying fabric is not broadcast enabled, and the node proceeds to the registration phase. To minimize the possibility of a "lost" message causing the node to be improperly configured, a node MAY retransmit a limited number of InARP_Request messages before proceeding to the registration phase. The maximum number of retransmissions and the delay between transmissions are implementation dependent. A node MAY bypass the discovery phase if a manual configuration mechanism exists by which the node can determine the broadcast capability of the underlying network fabric. 6.1.2 Registration Phase The purpose of the registration phase is to ensure that the node can communicate with at least one HARP server so that address resolution requests can be satisfied during the operational phase. Because nodes connected to broadcast enabled fabric do not use HARP servers, the registration phase is only used by nodes connected to non- broadcast networks. Registration is accomplished by periodically sending InARP_Request messages to all the servers listed in the HRAL. The first server to respond on each LIS is designated the primary HARP server for that LIS on that node. The server's IP/ULA mapping is inserted into the node's HARP table, and the node transitions to the operational phase. The node SHALL resend the InARP_Request message on the order of once every 5 seconds to each server until the server replies. These retries continue even after the node has transitioned from the registration phase to the operational phase. As each server replies, it is deemed a viable HARP server, and retries to that server are no longer sent. Pittet, Young, Murphy Standards Track [Page 9]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 If this node is a server node (i.e., its ULA is in the HRAL), the node SHALL NOT send itself InARP_Request messages, but SHALL consider itself to be a permanently viable HARP server. Server nodes SHALL send InARP_Requests to all other HRAL nodes in the manner described above. Server nodes transition immediately to the operational phase because they do not need to register with a server to be operational. 6.1.3 Operational Phase In the operational phase, a HARP client is able to resolve IP/ULA mappings by referencing its HARP table or, when that fails, by making requests of its primary HARP server. A HARP server also resolves needed IP/ULA mappings by referencing its HARP table, but it MAY NOT make requests to other nodes (including other servers). For nodes on broadcast fabric, ARP_Request messages are sent to the broadcast ULA; for nodes on non-broadcast fabric, ARP_Request messages are sent to the primary HARP server. A node which receives an address resolution message is considered the target of the request if at least ONE of the following statements is true: o the node's IP address is in the target protocol address field of the HARP message; o the node's ULA is in the target hardware address field of the message; o the node is a HARP server. If a node is the target of an address resolution message, the node SHALL update its address mapping table with any new IP/ULA mapping it finds in the request, and it SHALL update the timestamp of the entry for the message's origin. The target node SHALL send a reply message for all requests it can satisfy, and it SHALL drop any requests it cannot satisfy. If a node is not the target for a received HARP message, the HARP message is dropped; no reply is sent back to the source. HARP clients and servers have additional operational requirements that are described in the following two sections. 6.1.3.1 HARP Client Operational Requirements Each HARP node is responsible for contacting the HARP servers specified in the HRAL in order to have its own HARP information Pittet, Young, Murphy Standards Track [Page 10]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 registered and to gain and refresh IP/ULA mappings from those servers. A HARP client MUST: o generate ARP_Request and InARP_Request messages as appropriate. If on a broadcast medium, ARP_Requests are sent either to the broadcast address or, in the case of revalidation requests, to the target's ULA. If on a non-broadcast medium, ARP_Requests are sent to the primary HARP server or, if no HARP server is responding and this is a revalidation request, directly to the target's ULA. o respond to ARP_Request and InARP_Request messages for which it is the target node. If a node has multiple IP addresses for the LIS, then the client MUST generate an InARP_Reply for each such address. Thus it is possible for a single InARP_Request to result in multiple replies. (Refer to Section 7, "Protocol Operation" in RFC 2390 [3].) o react to address resolution messages by modifying its HARP table entries appropriately. All IP/ULA mappings in address resolution messages SHOULD be added to the client's HARP table if not already present. Clients should accept ARP_Reply and InARP_Reply messages even in instances where no initiating request messages were sent. This allows a HARP server to update its clients when the server's mappings change, similar to what is accomplished on Ethernet with gratuitous ARP. o generate and transmit InARP_Request messages as needed and process InARP_Reply messages appropriately. The transmission and processing of InARP_Request and InARP_Reply messages is described in RFC 2390 [3]. o refresh all mapping entries in its HARP table at least once every 20 minutes. Clients on a broadcast medium SHOULD revalidate each entry by sending an ARP_Request directly to the node whose entry is expiring. Clients on a non-broadcast medium SHOULD revalidate each expiring entry by sending an ARP_Request message to the primary HARP server. If a client is not receiving responses from any HARP server, the client SHOULD attempt to revalidate each Pittet, Young, Murphy Standards Track [Page 11]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 entry by sending an ARP_Request message directly to the host whose entry is expiring. o if on a non-broadcast media, reregister with each HARP server at least once every 15 minutes. This can be accomplished by sending either ARP_Request or InARP_Request messages to the servers. (Initial registration with the servers must be accomplished with InARP_Request messages because the IP addresses of unregistered servers are not known.) 6.1.3.2 HARP Server Operational Requirements A HARP server MUST accept ARP_Request and InARP_Request messages from other HIPPI-6400 nodes. A server adds or updates its HARP table entries based on the source IP/ULA addresses found in each message. The server also updates the entry's timestamp to reflect each request's arrival. A HARP server replies to ARP_Requests and InARP_Requests based on the information it has in its HARP table. Table entries that have gone for more than 20 minutes without being revalidated are dropped from the HARP table; it is a requirement of HARP clients that they revalidate themselves with all servers every 15 minutes, so entries older than 20 minutes are implicitly no longer valid. If there are multiple addresses in the HRAL, then each server MUST act as a client to the other server(s). This is necessary so the servers will be registered with one another. 6.2 Primary HARP Server Selection During the operational phase, a node running on non-broadcast hardware can have multiple viable HARP servers available (i.e., more than one member of the HRAL has replied to an InARP_Request). Of these viable servers, a node MUST select one as its primary HARP server. The primary server is the target for all address resolution requests the client must send. A client MAY change its primary HARP server at any time, but it SHOULD NOT change primary servers without reason. What constitutes a reasonable circumstance for reselecting primary servers is implementation dependent, but examples of reasonable primary server reselection are: o the primary server has failed to reply to one or more Pittet, Young, Murphy Standards Track [Page 12]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 InARP_Request registration requests by the client; o the primary server has failed to reply to any two ARP_Requests in the last 120 seconds; o an external agent has detected failure of the primary HARP server. 6.3 HARP Table Entry Creation and Modification Each HARP node (whether client or server) contains a table of IP/ULA address mappings, called the HARP table. HARP messages that contain IP/ULA mappings not already in the table result in additions or changes to the table. Because a ULA can be associated with multiple IP addresses but an IP address can only be associated with a single ULA, the effect on the HARP table of an IP/ULA mapping that contains a new IP or new ULA is not symmetric. The following table lists the five possible cases that can arise from the reception of an IP/ULA mapping. The table contains two columns that indicate whether the IP and ULA for the received mapping is new or is to be found in one of two already-existing HARP table entries, called A and B; it is assumed that HARP table entries A and B have unique IPs and ULAs. The "change" column indicates what change MUST be made to the HARP table when such a mapping is received. +------+----------+-----------+----------------------------------+ | case | IP entry | ULA entry | change | +------+----------+-----------+----------------------------------+ | 1 | new | new | Create new entry | | 2 | A | A | No change (entry already exists) | | 3 | new | A | Leave entry A, create new entry | | 4 | A | new | Remove entry A, create new entry | | 5 | A | B | Remove entry A, create new entry | +------+----------+-----------+----------------------------------+ HARP table changes for received IP/ULA pair Here are examples of when each of these five cases can arise. For these examples, assume that a host receives an InARP_Request where the requester's IP and ULA are IPr and ULAr respectively. Furthermore, assume that the host's HARP table contains linked entries IPa/ULAa and IPb/ULAb. o Fresh entry (IPr not in table, ULAr not in table) This is a normal case of host discovery. A new HARP table entry is created for the IPr/ULAr mapping. Pittet, Young, Murphy Standards Track [Page 13]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 o Supplemental message (IPr is IPa and ULAr is ULAa) This is a normal revalidation: an entry already exists that associates the IP address with the ULA. All that is necessary is to update the entry's timestamp. o Add IP alias to table (IPr not in table, ULAr is ULAa) If the requester's hardware address duplicates a hardware address entry, but there is no IP entry matching the received IP address, then a new HARP table entry is created for this new IPr/ULAa mapping; the other entry or entries containing this ULA remain in the HARP table. o Move IP address to a new ULA (IPr is IPa, ULAr not in table) If the requester's IP address is found in the table but is associated with a different ULA, then the entry containing the requester's IP address is removed from the HARP table, and a new entry, containing the new IPa/ULAr mapping, is added. o Move IP alias to an existing ULA (IPr is IPa, ULAr is ULAb) If the InARP_Request requester's IP address is found in one table entry, but the requester's ULA is found in a different entry, then the entry containing the requester's IP address (IPa/ULAa) is removed from the HARP table, and a new entry, containing the new IPa/ULAb mapping, is added. Because the transmission of the ARP_Request demonstrates that the requesting client is functioning, a HARP server SHOULD update the requester's HARP table entry timestamp for each ARP_Request it receives. This reduces the frequency of revalidation requests that need to be made. (See section 6.5 for a discussion of table entry aging.) 6.4 HARP and Permanent ARP Table Entries A HARP server SHOULD have a mechanism (e.g., manual configuration) for defining permanent HARP table entries. The details of the mechanism are beyond the scope of this memo. The permanent entries allow interoperability with legacy HIPPI adapters which do not implement dynamic HARP and instead use a table-based static address resolution mechanism. Permanent entries are not aged, and their IP/ULA mappings MAY NOT be removed by conflicting information gleaned from ARP_Request messages (see section 5.4 above). (That is, a server's permanent entries have precedence over information gathered from clients.) Pittet, Young, Murphy Standards Track [Page 14]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 For the purpose of resolving ARP_Request and InARP_Request messages, the HARP server MUST treat static HARP table entries in the same manner as it does dynamic entries. This eliminates the need for maintaining static HARP table entries on client nodes. 6.5 HARP Table Entry Aging HARP table entry aging MUST be supported because IP addresses and ULAs can move or be reassigned while an LIS is active. When such changes occur, the mappings in both client and server HARP tables become invalid. To ensure that such changes are discovered and corrected within a reasonable time, HARP nodes MUST age all non-permanent entries; the aging rate is different for HARP clients and HARP servers. o When an entry in a client's HARP table ages beyond 15 minutes, the HARP client MUST delete the table entry. o When an entry in a server's HARP table ages beyond 20 minutes, the HARP server MUST delete the table entry. To ensure that a client's own address mappings do not expire on its servers, clients MUST reregister themselves with all servers every 15 minutes. The client SHOULD revalidate each HARP table entry before it expires. The client revalidates each HARP table entry by querying its primary HARP server. If a valid reply for this entry is received, the entry is updated. If there is no answer from the HARP server, then the client MUST attempt to revalidate the entry by transmitting an InARP_Request to the ULA of the entry in question and updating the entry on receipt of an InARP_Reply. If the InARP_Request attempt fails to return an InARP_Reply, the expiring table entry is removed. When a server fails to respond to a request, it can indicate that the requested address is not in the server's HARP table, or it can indicate that the server is no longer accessible. Thus when a server fails to respond to a request, the client MUST immediately initiate reregistration with that server. A server reply indicates that the server is still viable and that it can continue to be used as the primary HARP server. 6.6 Receiving Unknown HARP Messages If a HARP node receives a HARP message with an undefined operation code, it MUST discard the message and continue normal operation. A node MAY NOT respond to the originator of the undefined message. Pittet, Young, Murphy Standards Track [Page 15]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 7. HARP Message Encoding The HARP message is a type of IEEE 802 payload as shown in section 5.1 above. The HIPPI-6400 HARP SHALL support a packet format identical to the generic Ethernet ARP packet (prepended by a HIPPI-6400 MAC header instead of an Ethernet transmission layer header). All fields of the HARP packet SHALL be set to zero if not in use. 7.1 Generic IEEE 802 ARP Message Format This is the ARP message format used by conventional IEEE 802 networks (e.g., Ethernet). The message format is described in RFC 826 [2] and is given here (with a HIPPI-6400 MAC header) only for completeness. Field Size Description ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type of the protocol fields below ar$hln 8 bits Byte length of each hardware address ar$pln 8 bits Byte length of each protocol address ar$op 16 bits Opcode (ares_op$REQUEST | ares_op$REPLY) ar$sha 48 bits Hardware address of sender of this message ar$spa 32 bits Protocol address of sender of this message ar$tha 48 bits Hardware address of target ar$tpa 32 bits Protocol address of target Where: ar$hrd SHALL contain 1 (Ethernet) ar$pro SHALL contain the IP protocol code 2048 (decimal) ar$hln SHALL contain 6 ar$pln SHALL contain 4 ar$op SHALL contain the operational value (decimal): 1 -- ARP_Request 2 -- ARP_Reply 8 -- InARP_Request 9 -- InARP_Reply ar$rpa In requests, SHALL contain the requester's IP address. In replies, SHALL contain the target node's IP address. ar$sha In requests, SHALL contain the requester's ULA. In replies, SHALL contain the target node's ULA. Pittet, Young, Murphy Standards Track [Page 16]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 ar$spa In requests, SHALL contain the requester's IP address. In replies, SHALL contain the target node's IP address. ar$tha In requests, SHALL contain the target's ULA if known. In replies, SHALL contain the requester's ULA. ar$tpa In requests, SHALL contain the target's IP address if known. In replies, SHALL contain the requester's IP address. |31 |23 |15 |7 0| +--------------+--------------+--------------+--------------+ ---------- 0 | | | D_ULA +-----------------------------+ HIPPI-6400 1 | | | +-----------------------------+ S_ULA | MAC 2 | | +-----------------------------------------------------------+ header 3 | M_len | +--------------+--------------+--------------+--------------+ ---------- 4 | AA | AA | 03 | 00 | IEEE 802 +--------------+--------------+--------------+--------------+ LLC/SNAP 5 | 00 | 00 | Ethertype = 0x0806 = 2054 | header +--------------+--------------+-----------------------------+ ---------- 6 | hrd (1) | pro (2048) | +--------------+--------------+-----------------------------+ 7 | hln (6) | pln (4) | op (ar$op) | +<><><><><><><>+<><><><><><><>+<><><><><><><>+<><><><><><><>+ 8 | Source Hardware Address (ULA) bytes 0 - 3 | +-----------------------------+-----------------------------+ 9 | Source ULA bytes 4 - 5 | Source IP Addr bytes 0 - 1 | +-----------------------------+-----------------------------+ 10 | Source IP Addr bytes 2 - 3 | Target ULA bytes 0 - 1 | +-----------------------------+-----------------------------+ 11 | Target Hardware Address (ULA) bytes 2 - 5 | +-----------------------------------------------------------+ 12 | Target IP Address | +--------------+--------------+--------------+--------------+ 13 | FILL | FILL | FILL | FILL | +--------------+--------------+--------------+--------------+ 14 | FILL | FILL | FILL | FILL | +--------------+--------------+--------------+--------------+ 15 | FILL | FILL | FILL | FILL | +<><><><><><><>+<><><><><><><>+<><><><><><><>+<><><><><><><>+ Payload format for HARP/InHARP message Pittet, Young, Murphy Standards Track [Page 17]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 8. HIPPI-6400 Broadcast HIPPI-6400-SC specifies two types of switches: bridging and non- bridging. Bridging switches are defined as those that support broadcast and IEEE 802.1d. Non-bridging switches are all others. Support for broadcast on HIPPI-6400 is limited to those networks which are bridging. 9. HARP for Scheduled Transfer [10] This RFC also applies to resolving addresses used with Scheduled Transfer (ST) over HIPPI-6400 instead of IP. This RFC's message types and algorithms can be used for ST (because ST uses IP addresses) provided there is also an IP over HIPPI implementation on all nodes. 10. 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 [11]. No special security mechanisms have been added to the address resolution mechanism defined here for use with networks using HARP. 11. HARP Examples The following examples demonstrate the behavior of the HARP protocol. For all of the examples, assume a HIPPI-6400-SC switch is installed with three connected nodes: X, Y, and S. Each node has an IP address (IPx, IPy, and IPs, respectively) and a ULA (ULAx, ULAy, and ULAs, respectively). All three IP addresses are members of the same LIS. Node S is defined as the lone HARP server for this LIS, so each node's HRAL contains a single element containing ULAs. Nodes X and Y are client nodes. These examples show the broadcast discovery phase of client X on both a broadcast capable and non-broadcast capable fabric, the registration phase of client X, and the address resolution of client Y for client X. Examples of attempts to resolve addresses for a non- existent node Q are also provided. The LLC, SNAP, Ethertype, ar$hrd, ar$pro, ar$hln, and ar$pln fields are left out of the examples below because they are constant. Pittet, Young, Murphy Standards Track [Page 18]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 11.1 Discovery Phase of Client on Broadcast Capable Medium Node X initializes its interface and sends an InARP_Request to the broadcast ULA (FF:FF:FF:FF:FF:FF). HIPPI-6400-PH D_ULA FF:FF:FF:FF:FF:FF HIPPI-6400-PH S_ULA ULAx HARP ar$op 8 (InARP_Request) HARP ar$sha ULAx HARP ar$spa IPx HARP ar$tha IPx HARP ar$tpa 0 Because the fabric is broadcast capable, client X will receive a copy of this InARP_Request. X will detect that the source ULA and target IP address are both its own addresses, so X can deduce that this message is its own discovery message, and therefore that it is connected to a broadcast medium. Because it is on a broadcast medium, X does not need a HARP server, so no registration with HRAL elements is performed; node X transitions from the discovery phase to the operational phase and any IP-to-ULA mappings it needs will be satisfied by sending ARP_Request messages to the broadcast ULA. 11.2 Discovery Phase of Client on Non-Broadcast Capable Medium As in Example 11.1, node X begins by sending an InARP_Request to the broadcast address. But, because the underlying fabric does not support broadcast, the message is not received by node X. After an implementation-specified time (and possible retransmissions) has elapsed, node X concludes that it is connected to non-broadcast capable hardware and transitions to the registration phase. 11.3 Registration Phase of Client on Non-Broadcast Capable Medium When a client determines that it is on a non-broadcast medium, it will send InARP_Requests to each server listed in its HRAL in order to register its addresses with the servers, and in order to identify a server to which it will send HARP requests during the operational phase. For this example LIS there is only one server, so client X only sends a single InARP_Request. Client X will periodically resend this message until an InARP_Reply is received from the server. Pittet, Young, Murphy Standards Track [Page 19]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 HIPPI-6400-PH D_ULA ULAs HIPPI-6400-PH S_ULA ULAx HARP ar$op 8 (InARP_Request) HARP ar$sha ULAx HARP ar$spa IPx HARP ar$tha ULAs HARP ar$tpa 0 <- field we want When HARP server S receives X's InARP_Request, it examines the source addresses and scans its HARP table for a match. Because this is the first time X is connecting to the server, S's HARP table contains no IPx/ULAx mapping. One will therefore be created and timestamped with the current time. Server S will then send an InARP_Reply including its IP address back to client X. HIPPI-6400-PH D_ULA ULAx HIPPI-6400-PH S_ULA ULAs HARP ar$op 9 (InARP_Reply) HARP ar$sha ULAs HARP ar$spa IPs <- our answer HARP ar$tha ULAx HARP ar$tpa IPx When node X receives the InARP_Reply, it examines the source addresses and scans its HARP table for a match. Because this is the first time S has responded to the client, X's HARP table contains no IPs/ULAs mapping. One will therefore be created and timestamped with the current time. Upon receipt of this reply, client X is ensured that it is registered with the HARP server, thereby making the IPx/ULAx address mapping available to any other hosts that query server S for it. Client X designates node S as its primary HARP server, and transitions from the registrations phase to the operational phase. 11.4 Successful HARP_RESOLVE on Broadcast Capable Medium When in the operational phase, a node is capable of resolving IP-to- ULA mappings for hosts in its LIS. If the node is connected to a broadcast medium, it sends APR_Request messages to the broadcast ULA (FF:FF:FF:FF:FF:FF). For this example, we will assume that nodes X, Y, and S have all discovered that they are on a broadcast medium, as described in Example 11.1. Because broadcast media do not have HARP servers, nodes X, Y, and S are all clients, and at this point none of them contain any mappings in their HARP tables. Pittet, Young, Murphy Standards Track [Page 20]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 Let us assume that node X wants to send data to node Y. Because node X does not have an IP/ULA mapping for Y in its HARP table, node X will send an ARP_Request to the broadcast ULA. HIPPI-6400-PH D_ULA FF:FF:FF:FF:FF:FF HIPPI-6400-PH S_ULA ULAx HARP ar$op 1 (ARP_Request) HARP ar$sha ULAx HARP ar$spa IPx HARP ar$tha 0 <- field we want HARP ar$tpa IPy Nodes X, Y, and S all receive this request. Nodes X and S recognize that they are not the target for this request (because neither ar$tha nor ar$tpa match their own addresses), so they silently disregard the message. Node Y recognizes that it is the target for the request. But before responding to the request, it checks its HARP table to see if it contains an IPx/ULAx mapping. Because its HARP table does not contain this mapping, node Y adds the IPx/ULAx mapping to its table and timestamps it with the current time. Node Y then builds an ARP_Reply message complete with its ULA and sends it to the source. HIPPI-6400-PH D_ULA ULAx HIPPI-6400-PH S_ULA ULAy HARP ar$op 2 (ARP_Reply) HARP ar$sha ULAy <- our answer HARP ar$spa IPy HARP ar$tha ULAx HARP ar$tpa IPx Node X receives this ARP_Reply message, and adds the IPy/ULAy mapping to its HARP table and timestamps it with the current time. Node X can then send IP data to node Y by transmitting IP packets with the following information in the HIPPI-LE header: HIPPI-6400-PH D_ULA ULAy HIPPI-6400-PH S_ULA ULAx <data> Node Y receives these IP packets, which contain node X's IP address. Because node Y already has an entry in its HARP table for IPx/ULAx, it can immediately send IP packets to node X in reply; these IP packets will have the following information in the HIPPI-LE header: Pittet, Young, Murphy Standards Track [Page 21]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 HIPPI-6400-PH D_ULA ULAx HIPPI-6400-PH S_ULA ULAy <data> 11.5 Unsuccessful HARP_RESOLVE on Broadcast Capable Medium As in 11.4, assume that X is fully registered with the HARP server. Node X wants to send data to an unregistered node Q. Because X does not have an entry for Q in its HARP table, it sends an ARP_Request containing Q's IP address to the broadcast address. HIPPI-6400-PH D_ULA FF:FF:FF:FF:FF:FF HIPPI-6400-PH S_ULA ULAx HARP ar$op 1 (ARP_Request) HARP ar$sha ULAx HARP ar$spa IPx HARP ar$tha 0 <- field we want HARP ar$tpa IPq Nodes X, Y, and S all receive this message, but because none of them are the target, they all ignore it. Node X eventually times out waiting for a reply, and retransmits the request if it wishes. As long as there is no node Q on the fabric, X will never receive a reply message; node X can at some point decide that node Q is not available, but such decisions are beyond the scope of address resolution. 11.6 Successful HARP_RESOLVE on Non-Broadcast Capable Medium When in the operational phase, a node is capable of resolving IP-to- ULA mappings for hosts in its LIS. If the node is connected to a non-broadcast medium, it sends ARP_Request messages to its primary HARP server. For this example, we will assume that client X has registered with HARP server S as described in Example 11.2, and that client Y has registered with server S in the same manner, but that neither client X nor client Y have mappings for the other in their HARP tables. Let us assume that X wants to send data to Y. Because X does not have an IP/ULA mapping for Y in its HARP table, X sends an ARP_Request to its HARP server. Pittet, Young, Murphy Standards Track [Page 22]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 HIPPI-6400-PH D_ULA ULAs HIPPI-6400-PH S_ULA ULAx HARP ar$op 1 (ARP_Request) HARP ar$sha ULAx HARP ar$spa IPx HARP ar$tha 0 <- field we want HARP ar$tpa IPy Server S receives this request. Before responding to the request, it checks its HARP table to see if it contains a mapping between the request's source addresses, IPx and ULAx. Because this mapping is in place, the server does not have to update its HARP table, but it does update the timestamp associated with the IPx/ULAx mapping. The server then searches for IPy in its HARP table, and finds a matching entry. The server builds and sends an ARP_Reply message based on this mapping. HIPPI-6400-PH D_ULA ULAx HIPPI-6400-PH S_ULA ULAs HARP ar$op 2 (ARP_Reply) HARP ar$sha ULAy <- our answer HARP ar$spa IPy HARP ar$tha ULAx HARP ar$tpa IPx Node X receives this ARP_Reply message, and adds the IPy/ULAy mapping to its HARP table and timestamps it with the current time. Node X can then send IP data to node Y by transmitting IP messages with the following information in the HIPPI-LE header: HIPPI-6400-PH D_ULA ULAy HIPPI-6400-PH S_ULA ULAx <data> Node Y receives these IP packets, which contain node X's IP address. But node Y cannot respond to node X at this point, because node Y's HARP table does not contain a mapping for node X. To acquire this mapping, node Y sends an ARP_Request to its HARP server, node S. HIPPI-6400-PH D_ULA ULAs HIPPI-6400-PH S_ULA ULAy HARP ar$op 1 (ARP_Request) HARP ar$sha ULAy HARP ar$spa IPy HARP ar$tha 0 <- field we want HARP ar$tpa IPx Server S receives this request. Before responding to the request, it Pittet, Young, Murphy Standards Track [Page 23]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 checks its HARP table to see if it contains a mapping between the request's source addresses, IPy and ULAy. Because this mapping is in place, the server does not have to update its HARP table, but it does update the timestamp associated with the IPy/ULAy mapping. The server then searches for IPx in its HARP table, and finds a matching entry. The server builds and sends an ARP_Reply message based on this mapping. HIPPI-6400-PH D_ULA ULAy HIPPI-6400-PH S_ULA ULAs HARP ar$op 2 (ARP_Reply) HARP ar$sha ULAx <- our answer HARP ar$spa IPx HARP ar$tha ULAy HARP ar$tpa IPy Node Y receives this ARP_Reply message and adds the IPx/ULAx mapping to its HARP table and timestamps it with the current time. It can then respond to the IP data it received from node X; these IP packets will have the following information in the HIPPI-LE header: HIPPI-6400-PH D_ULA ULAx HIPPI-6400-PH S_ULA ULAy <data> 11.7 Unsuccessful HARP_RESOLVE on Non-Broadcast Capable Medium As in 11.4, assume that X is fully registered with the HARP server. Node X wants to send data to an unregistered node Q. Because X does not have an entry for Q in its HARP table, it sends an ARP_Request containing Q's IP address to its primary HARP server: HIPPI-6400-PH D_ULA ULAs (HARP service) HIPPI-6400-PH S_ULA ULAx HARP ar$op 1 (ARP_Request) HARP ar$sha ULAx HARP ar$spa IPx HARP ar$tha 0 <- field we want HARP ar$tpa IPq Server S receives this request. Before responding to the request, it checks its HARP table to see if it contains a mapping between the request's source addresses, IPx and ULAx. Because this mapping is in place, the server does not have to update its HARP table, but it does update the timestamp associated with the IPx/ULAx mapping. The server then searches for IPq in its HARP table, but does not find a match; the HARP server therefore does not reply to the request. Pittet, Young, Murphy Standards Track [Page 24]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 Node X eventually times out waiting for a reply, and retransmits the request if it wishes. As long as there is no node Q on the fabric, X will never receive a reply message; node X can at some point decide that node Q is not available, but such decisions are beyond the scope of address resolution. 12. References [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [2] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. [3] Bradely, T., Brown, C., Malis, A., "Inverse Address Resolution Protocol", RFC 2390, September 1998. [4] ANSI NCITS 323-1998, Information Technology - High-Performance Parallel Interface - 6400 Mbit/s Physical Layer (HIPPI-6400-PH). [5] ANSI NCITS 324-1999, Information Technology - High-Performance Parallel Interface - 6400 Mbit/s Physical Switch Control (HIPPI-6400-SC). [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989. [8] ANSI/IEEE Standard 802.2-1989, Information Processing Systems - Local Area Networks - Logical Link Control IEEE, IEEE, New York, New York, 1989. [9] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [10] ANSI NCITS Project Number 1245-D, Information Technology - Scheduled Transfer Protocol (ST) [11] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989. [12] Renwick, J., "IP over HIPPI", RFC 2067, January 1997. [13] Pittet, J.-M., "ARP and IP Broadcast over HIPPI-800", RFC 2834, Pittet, Young, Murphy Standards Track [Page 25]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 December 1998. 13. Acknowledgments This memo could not have come into being without the critical review of Greg Chesson, Carlin Otto, the High Performance Interconnect Group of Silicon Graphics, Inc. (specifically Jim Pinkerton and Brad Strand) 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 [12], written by John Renwick. ARP [2] written by Dave Plummer and Inverse ARP [3] written by Terry Bradley and Caralyn Brown provide the fundamental algorithms of HARP as presented in this memo. The HARP server is based on concepts and models presented in [13], written by Mark Laubach. 14. Authors' Addresses Jean-Michel Pittet Silicon Graphics, Inc. 2011 N. Shoreline Ave Mountain View, CA 94040 Phone: 408-585-5617 EMail: jmp@acm.com Jeff Young Vieo, Inc. 2145 Ford Parkway St. Paul, MN 55116 Phone: 651-698-9350 x100 EMail: jsy@vieo.com Sean Murphy Silicon Graphics, Inc. 12200-G Plum Orchard Drive Silver Spring, MD 20804 Phone: 301-595-2648 EMail: smurphy@sgi.com Please send all comments regarding this Internet-Draft to Sean Murphy at smurphy@sgi.com . Pittet, Young, Murphy Standards Track [Page 26]
INTERNET-DRAFT IP and ARP over HIPPI-6400 8 October 2001 This Internet-Draft was submitted on 8 October 2001 and expires on 8 April 2002. 15. Full Copyright Statement Copyright (C) The Internet Society (2000, 2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Pittet, Young, Murphy Standards Track [Page 27]